Engine question

countbasiecountbasie Members Join Date: 2008-12-27 Member: 65884Posts: 824
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 Members Join Date: 2005-02-25 Member: 42431Posts: 464
    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 Members Join Date: 2008-12-27 Member: 65884Posts: 824
    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 Members Join Date: 2005-02-25 Member: 42431Posts: 464
    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. Members, Squad Five Blue, Reinforced - Shadow Join Date: 2011-11-01 Member: 130634Posts: 941 Advanced user
    edited December 2011
    <-- Ignore this post. Everything relevant below.
    Post edited by Unknown User on
  • NurEinMenschNurEinMensch Members, Constellation Join Date: 2003-02-26 Member: 14056Posts: 1,352
    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 think 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.
    This is the kind of thing that goes on behind close doors on normal game releases, where they are optimizing it right up until the end. You guys are just getting to play with a version of the game that normally only the developers see.

    --Cory
  • DghelneshiDghelneshi Aims to surpass Fana in post edits. Members, Squad Five Blue, Reinforced - Shadow Join Date: 2011-11-01 Member: 130634Posts: 941 Advanced user
    QUOTE (NurEinMensch @ Dec 22 2011, 11:49 PM) »
    Meaning when the server doesn't send the updated you need to render don't wait for them but render whatever you have instead.

    "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 Members, NS2 Playtester Join Date: 2011-01-24 Member: 78824Posts: 38
    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 Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer Join Date: 2002-03-15 Member: 318Posts: 1,737 admin
    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.
    Max McGuire
    Technical Director, Unknown Worlds Entertainment
  • countbasiecountbasie Members Join Date: 2008-12-27 Member: 65884Posts: 824
    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 Members Join Date: 2010-09-12 Member: 73982Posts: 1,677
    QUOTE (Max @ Dec 23 2011, 01:09 AM) »
    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.

    That's not a bad idea, at least when the server has not sent a single update-packet the past second.
  • IronsoulIronsoul Members Join Date: 2011-03-12 Member: 86048Posts: 869 Advanced user
    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 Members Join Date: 2002-12-23 Member: 11426Posts: 4,469
    QUOTE (player @ Dec 23 2011, 12:03 PM) »
    That's not a bad idea, at least when the server has not sent a single update-packet the past second.



    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 Members Join Date: 2010-09-12 Member: 73982Posts: 1,677
    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 Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer Join Date: 2002-03-15 Member: 318Posts: 1,737 admin
    QUOTE (countbasie @ Dec 22 2011, 06:56 PM) »
    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?

    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.
    Max McGuire
    Technical Director, Unknown Worlds Entertainment
  • croncron Members Join Date: 2010-06-21 Member: 72122Posts: 142
    edited December 2011
    QUOTE (player @ Dec 23 2011, 11:13 AM) »
    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).


    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.
    "This relentless restlessness"
  • KalabalanaKalabalana Members Join Date: 2003-11-14 Member: 22859Posts: 1,049 Advanced user
    QUOTE (Max @ Dec 22 2011, 08:09 PM) »
    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.

    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 Members Join Date: 2010-09-12 Member: 73982Posts: 1,677
    QUOTE (cron @ Dec 23 2011, 04:16 PM) »
    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.

    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.

    QUOTE (Kalabalana)
    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.

    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 Members Join Date: 2003-11-14 Member: 22859Posts: 1,049 Advanced user
    edited December 2011
    QUOTE (player @ Dec 23 2011, 09:52 PM) »
    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.

    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 Members, Constellation Join Date: 2003-02-26 Member: 14056Posts: 1,352
    What is causing it then? Why is there such a noticeable correlation between server tick rate and client fps?
    This is the kind of thing that goes on behind close doors on normal game releases, where they are optimizing it right up until the end. You guys are just getting to play with a version of the game that normally only the developers see.

    --Cory
  • playerplayer Members Join Date: 2010-09-12 Member: 73982Posts: 1,677
    QUOTE (Kalabalana @ Dec 24 2011, 06:12 PM) »
    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.

    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 Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer Join Date: 2002-03-15 Member: 318Posts: 1,737 admin
    QUOTE (player @ Dec 24 2011, 08:31 PM) »
    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.

    Exactly.
    Max McGuire
    Technical Director, Unknown Worlds Entertainment
  • KalabalanaKalabalana Members Join Date: 2003-11-14 Member: 22859Posts: 1,049 Advanced user
    Well then, I believe we've found priority one for the dev team.
  • TechercizerTechercizer 7th Player Members Join Date: 2011-06-11 Member: 103832Posts: 1,850
    QUOTE (Kalabalana @ Dec 26 2011, 10:19 AM) »
    Well then, I believe we've found priority one for the dev team.

    Making the game feature/mechanic-complete so they can start optimizing it as a whole?

            Once the infestation reaches the Command Chair, the process begins. One Gorge enters the chair to provide the necessary height. Another climbs on its shoulders to access the controls.

            A Gorge Lab is quickly established, staffed by microscopic Gorges who work tirelessly to unlock the secrets of Frontiersman Technology, stopping only to change their lab coats when they become dirtied. Once the research progresses to a certain point, the Gorgecom gives the order. Nanites are called into service.

            The armature forms. A chosen Gorge, tested many times in the field of battle, enters the machine.

            Servos whir; miniguns spin up in diagnostics; an Exogorge is born.

  • cmc5788cmc5788 Members Join Date: 2009-10-06 Member: 68959Posts: 291
    QUOTE (Techercizer @ Dec 26 2011, 11:46 AM) »
    Making the game feature/mechanic-complete so they can start optimizing it as a whole?


    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 Members, Constellation Join Date: 2004-08-22 Member: 30793Posts: 3,225
    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.