Engine question

countbasiecountbasie Join Date: 2008-12-27 Member: 65884Members
Hello,

I have a question.

In Quake- and Source-based games the netcode and graphics-engine code seem to be separated. When the network connection times out I still have the same framerates and everything is still playing the last animations as a loop, completely smooth.

In NS2, so you forum-guys tell me, my bad framerate may be caused by low tickrates of the server. And when the connection times out, everything seems to hang/crash.


Could someone explain me as simple and right as possible, what is different in Spark compared to, let's say Quake? Or is the point completely wrong?

Comments

  • BJHBnade_spammerBJHBnade_spammer Join Date: 2005-02-25 Member: 42431Members
    edited December 2011
    the point is those engines are optimized and this game is still in more of an alpha state you cannot compare apples to oranges as they say.

    the net code is getting better as they go on that is why they are still in testing as of right now and what we have is considered a work in progress
  • countbasiecountbasie Join Date: 2008-12-27 Member: 65884Members
    I know that, and there's no problem for me.

    The question was: How is the netcode related to the graphics code?
  • BJHBnade_spammerBJHBnade_spammer Join Date: 2005-02-25 Member: 42431Members
    lol bugs like i said the game is still a work in progress. and also all code is related some how.
  • DghelneshiDghelneshi Aims to surpass Fana in post edits. Join Date: 2011-11-01 Member: 130634Members, Squad Five Blue, Reinforced - Shadow
    edited December 2011
    <-- Ignore this post. Everything relevant below.
  • NurEinMenschNurEinMensch Join Date: 2003-02-26 Member: 14056Members, Constellation
    Well I kind of share the same question as the OP. I used to think the rendering should happen independently from updated from the server. Meaning when the server doesn't send the updated you need to render don't wait for them but render whatever you have instead.

    I <i>think</i> the problem we see is caused be unoptimized extrapolation. When the server is slow the client gets fewer updates than it needs. So it extrapolates whenever it needs to render a frame and doesn't have all the data. And right now it's simply not so good at that.

    But this is just my understanding and it may not be true at all.
  • DghelneshiDghelneshi Aims to surpass Fana in post edits. Join Date: 2011-11-01 Member: 130634Members, Squad Five Blue, Reinforced - Shadow
    <!--quoteo(post=1891372:date=Dec 22 2011, 11:49 PM:name=NurEinMensch)--><div class='quotetop'>QUOTE (NurEinMensch @ Dec 22 2011, 11:49 PM) <a href="index.php?act=findpost&pid=1891372"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Meaning when the server doesn't send the updated you need to render don't wait for them but render whatever you have instead.<!--QuoteEnd--></div><!--QuoteEEnd-->
    "what you have" is the stuff from the last frame so it would cause really annoying hitching, even more annoying than having temporarily low framerates from extrapolating. Low FPS > Drawing the same frame over and over again, effectively having "zero FPS".
  • VarXXVarXX Join Date: 2011-01-24 Member: 78824Members, NS2 Playtester
    edited December 2011
    As I currently understand it, it's the collision detection going nuts when the server tick rate goes down causing your framerate and client rate to nose dive. The big difference between spark and quake engine right now really is optimization.
  • MaxMax Technical Director, Unknown Worlds Entertainment Join Date: 2002-03-15 Member: 318Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer
    Spark uses interpolation and extrapolation, pretty much the same as Source. There's nothing fundamentally different between Source and Spark in terms of networking. Making the client stop moving when the server is not responding is just a "design" decision, I could make it work the other way by changing one line of code.
  • countbasiecountbasie Join Date: 2008-12-27 Member: 65884Members
    edited December 2011
    Wow, people really answered, thank you ;) and actually Max himself.

    Sorry, I'm not a programmer, but I wanna learn something. I think a few people here could be interested in this part of developing.
    From what I understand, neither in Spark nor in Source or Quake the client is completely independent from the network, because the client needs to wait for the confirmed information about what it should draw, for example a skulk moving 100 pixels left. And this information is computed and transmitted via inter- and extrapolation.
    Having the client drawing before a confirmation would cause artifacts / hitching, because your client doesn't know what the skulk will do.

    Is that about right?

    @Max:
    Thanks for your answer. I think for my understanding, changing this one line would make the experience a lot 'smoother'. Because like it is right now it makes me think the whole game crashed. Allowing me to move the mouse etc. with a warning that the connection is failing would make me feel more secure. What are the reasons for your decision?

    @BJHBnade_spammer
    I know that, and there's no problem for me.

    The question was: How is the netcode related to the graphics code?
  • playerplayer Join Date: 2010-09-12 Member: 73982Members
    <!--quoteo(post=1891393:date=Dec 23 2011, 01:09 AM:name=Max)--><div class='quotetop'>QUOTE (Max @ Dec 23 2011, 01:09 AM) <a href="index.php?act=findpost&pid=1891393"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Making the client stop moving when the server is not responding is just a "design" decision, I could make it work the other way by changing one line of code.<!--QuoteEnd--></div><!--QuoteEEnd-->
    That's not a bad idea, at least when the server has not sent a single update-packet the past second.
  • IronsoulIronsoul Join Date: 2011-03-12 Member: 86048Members
    From what I interpreted from previous interviews done by ns2hd(going from memory, can't be bothered rewatching them). And what Max has just said:

    When the network is having a .... problem, then the client can no longer walk around. That's pretty simple.

    But it still doesn't answer the original poster's question: why does client side fps suffer when the network is having troubles? I think I know why, so here goes.

    With the current public beta build(189), the game updates it's 2d rasterised frames(frame rendering... fps, frames per second) at the same time it updates the game world state. This means, that if the game world state is not updating(i.e. the server is not sending the client world updates), then the client framerate will go down due to what i said earlier. The game updates the graphics frame at the same rate the world itself updates.

    What this means is: if the world is running at 10 updates per second, the client will experience 10 frames per second.

    But I also remember in an interview, that the graphics updating is being separated from the world updaterate(and if this is not true, get to work and make it true). Which means that regardless of the world updaterate, your framerate will be the maximum your computer can handle, which will also greatly help with mouse lag issues.

    well that's all for my incorrect information posting.
  • sheena_yanaisheena_yanai Join Date: 2002-12-23 Member: 11426Members
    <!--quoteo(post=1891398:date=Dec 23 2011, 12:03 PM:name=player)--><div class='quotetop'>QUOTE (player @ Dec 23 2011, 12:03 PM) <a href="index.php?act=findpost&pid=1891398"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->That's not a bad idea, at least when the server has not sent a single update-packet the past second.<!--QuoteEnd--></div><!--QuoteEEnd-->


    it would just introduce mad rubberbanding

    packet lost, player keeps on moving, updated packets arrive, server is like.. dood, but you should be over there after all i know, bam, client is resetting your position to the spot the server thinks you were just when the packets got lost
  • playerplayer Join Date: 2010-09-12 Member: 73982Members
    Actually I ment just that, not allowing the client to move, which I think isn't the case at the moment (last time I checked anyway, you could just walk around for a while when the server had just died).
  • MaxMax Technical Director, Unknown Worlds Entertainment Join Date: 2002-03-15 Member: 318Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer
    <!--quoteo(post=1891396:date=Dec 22 2011, 06:56 PM:name=countbasie)--><div class='quotetop'>QUOTE (countbasie @ Dec 22 2011, 06:56 PM) <a href="index.php?act=findpost&pid=1891396"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Thanks for your answer. I think for my understanding, changing this one line would make the experience a lot 'smoother'. Because like it is right now it makes me think the whole game crashed. Allowing me to move the mouse etc. with a warning that the connection is failing would make me feel more secure. What are the reasons for your decision?<!--QuoteEnd--></div><!--QuoteEEnd-->
    When the client gets into this state (it has buffered the maximum amount of frames without getting any confirmation from the server) it's supposed to display a message on the screen saying there are connection problems. If that's not happening it's a bug.
  • croncron Join Date: 2010-06-21 Member: 72122Members
    edited December 2011
    <!--quoteo(post=1891430:date=Dec 23 2011, 11:13 AM:name=player)--><div class='quotetop'>QUOTE (player @ Dec 23 2011, 11:13 AM) <a href="index.php?act=findpost&pid=1891430"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Actually I ment just that, not allowing the client to move, which I think isn't the case at the moment (last time I checked anyway, you could just walk around for a while when the server had just died).<!--QuoteEnd--></div><!--QuoteEEnd-->

    By the time a server can deliver a constant tick rate of 25 this will not be important at all, but at the current state where the tick rate fluctuates a lot you will get massive rubber banding with every slowdown if you let the players move. Once the tick rate is stable it would be a good idea to let the player move freely and independent of tick rate, but with the fluctuation now this would just make the entire experience a lot less smooth.

    The graphics are rendered independently from the network as it is, movement is not a part of the graphics. If the graphics were dependent on the network and your FPS were directly connected to your tick rate then you wouldn't even be able to look around every time the tick rate goes haywire.
  • KalabalanaKalabalana Join Date: 2003-11-14 Member: 22859Members
    <!--quoteo(post=1891393:date=Dec 22 2011, 08:09 PM:name=Max)--><div class='quotetop'>QUOTE (Max @ Dec 22 2011, 08:09 PM) <a href="index.php?act=findpost&pid=1891393"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Spark uses interpolation and extrapolation, pretty much the same as Source. There's nothing fundamentally different between Source and Spark in terms of networking. Making the client stop moving when the server is not responding is just a "design" decision, I could make it work the other way by changing one line of code.<!--QuoteEnd--></div><!--QuoteEEnd-->
    Having the "client stop moving" is fine, but don't bottleneck a player's FPS, which is what has been happening for some time now. I play with 40+ FPS drops because the server is slowing down, this obviously is a mistake.
  • playerplayer Join Date: 2010-09-12 Member: 73982Members
    <!--quoteo(post=1891457:date=Dec 23 2011, 04:16 PM:name=cron)--><div class='quotetop'>QUOTE (cron @ Dec 23 2011, 04:16 PM) <a href="index.php?act=findpost&pid=1891457"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->By the time a server can deliver a constant tick rate of 25 this will not be important at all, but at the current state where the tick rate fluctuates a lot you will get massive rubber banding with every slowdown if you let the players move. Once the tick rate is stable it would be a good idea to let the player move freely and independent of tick rate, but with the fluctuation now this would just make the entire experience a lot less smooth.

    The graphics are rendered independently from the network as it is, movement is not a part of the graphics. If the graphics were dependent on the network and your FPS were directly connected to your tick rate then you wouldn't even be able to look around every time the tick rate goes haywire.<!--QuoteEnd--></div><!--QuoteEEnd-->
    No no, I said when no update-packet of any kind has been recieved for the past second (or even 2). You can have a tickrate as low as 5 and packet-loss on top of that without issues, but not recieving anything of any kind for a whole second (or 2) is indicative of a serious problem, and warrants freezing the game to notify the user that it is not functioning normally. It may be so that some servers out there will have this problem (not sending anything for seconds), in which case I would love for my client to freeze up so I'll immediately know something is very wrong, and I should either check my connection or part to another server. I don't want it to try to interpolate its arse out of this resulting in a crappy game, call it quality-control. I guess this would also be the right time to mention that a net_graph-diagram (ala Gldsource\Source) would be very much appreciated.

    <!--quoteo(post=0:date=:name=Kalabalana)--><div class='quotetop'>QUOTE (Kalabalana)</div><div class='quotemain'><!--quotec-->Having the "client stop moving" is fine, but don't bottleneck a player's FPS, which is what has been happening for some time now. I play with 40+ FPS drops because the server is slowing down, this obviously is a mistake.<!--QuoteEnd--></div><!--QuoteEEnd-->
    Didn't this have something to do with the fact that the client needs to do more work (in ways of interpolating\extrapolating) when the server is sending less information. Given that Lua is having a hard time as it is, adding additional prediction work on top of that will kill your framerate. So yeah this is pretty much exactly like Gldsource, except that we do not have the CPU-time to spare for interpolation\extrapolation-work, resulting in bad performance.
  • KalabalanaKalabalana Join Date: 2003-11-14 Member: 22859Members
    edited December 2011
    <!--quoteo(post=1891483:date=Dec 23 2011, 09:52 PM:name=player)--><div class='quotetop'>QUOTE (player @ Dec 23 2011, 09:52 PM) <a href="index.php?act=findpost&pid=1891483"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Didn't this have something to do with the fact that the client needs to do more work (in ways of interpolating\extrapolating) when the server is sending less information. Given that Lua is having a hard time as it is, adding additional prediction work on top of that will kill your framerate. So yeah this is pretty much exactly like Gldsource, except that we do not have the CPU-time to spare for interpolation\extrapolation-work, resulting in bad performance.<!--QuoteEnd--></div><!--QuoteEEnd-->
    No, this is incorrect, or is correct, and this game was somehow coded in this manner (highly unlikely).

    Prediction algorithms like this do not increase the workload this much. 100+% increases in workload are not caused this way.
  • NurEinMenschNurEinMensch Join Date: 2003-02-26 Member: 14056Members, Constellation
    What is causing it then? Why is there such a noticeable correlation between server tick rate and client fps?
  • playerplayer Join Date: 2010-09-12 Member: 73982Members
    <!--quoteo(post=1891543:date=Dec 24 2011, 06:12 PM:name=Kalabalana)--><div class='quotetop'>QUOTE (Kalabalana @ Dec 24 2011, 06:12 PM) <a href="index.php?act=findpost&pid=1891543"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->No, this is incorrect, or is correct, and this game was somehow coded in this manner (highly unlikely).

    Prediction algorithms like this do not increase the workload this much. 100+% increases in workload are not caused this way.<!--QuoteEnd--></div><!--QuoteEEnd-->
    Game-logic shouldn't bog down 4-5GHz CPUs, yet at the moment it does, so I wouldn't put it past NS2 that prediction\interpolation really does weigh this heavily on the game.
  • MaxMax Technical Director, Unknown Worlds Entertainment Join Date: 2002-03-15 Member: 318Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer
    <!--quoteo(post=1891573:date=Dec 24 2011, 08:31 PM:name=player)--><div class='quotetop'>QUOTE (player @ Dec 24 2011, 08:31 PM) <a href="index.php?act=findpost&pid=1891573"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Game-logic shouldn't bog down 4-5GHz CPUs, yet at the moment it does, so I wouldn't put it past NS2 that prediction\interpolation really does weigh this heavily on the game.<!--QuoteEnd--></div><!--QuoteEEnd-->
    Exactly.
  • KalabalanaKalabalana Join Date: 2003-11-14 Member: 22859Members
    Well then, I believe we've found priority one for the dev team.
  • TechercizerTechercizer 7th Player Join Date: 2011-06-11 Member: 103832Members
    <!--quoteo(post=1891704:date=Dec 26 2011, 10:19 AM:name=Kalabalana)--><div class='quotetop'>QUOTE (Kalabalana @ Dec 26 2011, 10:19 AM) <a href="index.php?act=findpost&pid=1891704"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Well then, I believe we've found priority one for the dev team.<!--QuoteEnd--></div><!--QuoteEEnd-->
    Making the game feature/mechanic-complete so they can start optimizing it as a whole?
  • cmc5788cmc5788 Join Date: 2009-10-06 Member: 68959Members
    <!--quoteo(post=1891724:date=Dec 26 2011, 11:46 AM:name=Techercizer)--><div class='quotetop'>QUOTE (Techercizer @ Dec 26 2011, 11:46 AM) <a href="index.php?act=findpost&pid=1891724"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Making the game feature/mechanic-complete so they can start optimizing it as a whole?<!--QuoteEnd--></div><!--QuoteEEnd-->

    No, that's not how it works. Optimization is an ongoing process. They're doing it now, and if all goes well, they'll be doing it long after "release."
  • CrispyCrispy Jaded GD Join Date: 2004-08-22 Member: 30793Members, Constellation
    Bringing issues to the dev team and explaining which have the bigger impact on your playing and modding experience is one thing, telling them in which order they should undertake tasks and bug fixes is another. It's not your jurisdiction to project-manage NS2; start your own game dev project if that's what you want to do (at least that way you may begin to understand what you're talking about).
Sign In or Register to comment.