I have rather limited experience in creating game engines, but wouldn't it make sense to have the rendering be as independent from updating the game world as possible? So that game logic would never slow down rendering and vice versa? Perhaps some kind of double buffered game state, one for the game logic to work on and one for the renderer to render. And when the game logic has done its loop the renderer gets a new copy of the game state. Rather than having the render function wait for the update function to finish.
<!--quoteo(post=1912433:date=Mar 13 2012, 02:09 AM:name=NurEinMensch)--><div class='quotetop'>QUOTE (NurEinMensch @ Mar 13 2012, 02:09 AM) <a href="index.php?act=findpost&pid=1912433"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I have rather limited experience in creating game engines, but wouldn't it make sense to have the rendering be as independent from updating the game world as possible? So that game logic would never slow down rendering and vice versa? Perhaps some kind of double buffered game state, one for the game logic to work on and one for the renderer to render. And when the game logic has done its loop the renderer gets a new copy of the game state. Rather than having the render function wait for the update function to finish.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think the problem is with consistency, and more recently with threading. If the update and render stages are completely independent, you can have half the drawn objects relating to frame 1 and the other half relating to frame 2. In most cases this doesn't sound like it would be much of a problem, not for NS2 anyway, but its not a very pretty or robust approach.
Another problem may be with threading. If one thread is busy running update code on an object, that object will be locked from access or modification. If the render stage then tries to draw that object using its position, it may have to wait until the lock is disabled.
I don't have experience with an engine as complex as spark, but these sound like some issues that would arise from having update and draw completely independent. Typically each is run in a continuous game loop, with draw obviously at the end, so it wouldn't be infeasible to simply terminate the draw call if its taking too much time.
Yes I see those problems which is why my idea was (and I'm really just speculating wildly here) that the renderer works on a copy of the game state. Basically you have a game state double buffer. Every time the update process is finished it puts a new copy of the game state into the buffer. The renderer will in the meantime render the latest game state in the game state buffer.
Now if we get that to work the problem is what do we gain other than being able to render the exact same game state twice so to speak?
<!--quoteo(post=1912456:date=Mar 12 2012, 10:18 PM:name=Max)--><div class='quotetop'>QUOTE (Max @ Mar 12 2012, 10:18 PM) <a href="index.php?act=findpost&pid=1912456"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I just fixed a bug where the animations weren't properly synched up during lag compensation.<!--QuoteEnd--></div><!--QuoteEEnd-->
Im guessing that if the latency compensation is implemented, which apparently it is, then its an issue with the tight coupling of update with frame rate. Whereas in BF3 the likelyhood of such a low frame rate is unlikely, in this game it is a very real and commonly occurring possibility. I guess I probably am shooting the skulks I see, but I'm only able to shoot 1 or 2 bullets over the course of 2 to 3 seconds. The fact that frame rate decreases with latency doesn't help much either.
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
There is no reason to design an FPS that works well in the sub-20 fps range - noone would buy it. The solution to low fps is not to design the game to work well at low fps, the solution is to make the game run better so you get then 60+ fps you need to enjoy it.
<!--quoteo(post=1912292:date=Mar 12 2012, 03:04 PM:name=Imbalanxd)--><div class='quotetop'>QUOTE (Imbalanxd @ Mar 12 2012, 03:04 PM) <a href="index.php?act=findpost&pid=1912292"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Maybe I should make a video of it. Basically I can empty shotgun shot after shotgun shot into skulks, hearing them make there default pain noise, seeing my screen go green with alien blood, and having the hit indicator on the cross-hair light up, but they will never take any damage.<!--QuoteEnd--></div><!--QuoteEEnd--> If the alien makes the pain noise, then it's taking damage. That's played only when their health lowers. Hit indicator doesn't light up either if it's not actually a hit. But you can see green blood regardless whether the hit registers or not. Currently we think the animations are the culprit, hopefully Max put the nail on the coffin on that one.
<!--quoteo(post=1912519:date=Mar 13 2012, 01:34 PM:name=Skie)--><div class='quotetop'>QUOTE (Skie @ Mar 13 2012, 01:34 PM) <a href="index.php?act=findpost&pid=1912519"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If the alien makes the pain noise, then it's taking damage. That's played only when their health lowers. Hit indicator doesn't light up either if it's not actually a hit. But you can see green blood regardless whether the hit registers or not. Currently we think the animations are the culprit, hopefully Max put the nail on the coffin on that one.<!--QuoteEnd--></div><!--QuoteEEnd-->
This I know to not be true. If i fire a bullet at a skulk the hit indicator will instantly light up and the skulk will play the pain noise. Because it is instant, that obviously means its client side, and clients don't determine hits, the server does.
<!--quoteo(post=1912533:date=Mar 13 2012, 02:17 PM:name=Imbalanxd)--><div class='quotetop'>QUOTE (Imbalanxd @ Mar 13 2012, 02:17 PM) <a href="index.php?act=findpost&pid=1912533"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->This I know to not be true. If i fire a bullet at a skulk the hit indicator will instantly light up and the skulk will play the pain noise. Because it is instant, that obviously means its client side, and clients don't determine hits, the server does.<!--QuoteEnd--></div><!--QuoteEEnd--> False. Don't pull things out of your butt. First post of this thread explains it: <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=116894" target="_blank">http://www.unknownworlds.com/ns2/forums/in...howtopic=116894</a>
Blood is immediate, client-side hit tick comes later (but only comes if it's a hit), pain flinch comes even after that.
But I'll let you know that Max's hit registration fix works sweetly. See you on the battleground, skulks...
Comments
I think the problem is with consistency, and more recently with threading. If the update and render stages are completely independent, you can have half the drawn objects relating to frame 1 and the other half relating to frame 2. In most cases this doesn't sound like it would be much of a problem, not for NS2 anyway, but its not a very pretty or robust approach.
Another problem may be with threading. If one thread is busy running update code on an object, that object will be locked from access or modification. If the render stage then tries to draw that object using its position, it may have to wait until the lock is disabled.
I don't have experience with an engine as complex as spark, but these sound like some issues that would arise from having update and draw completely independent. Typically each is run in a continuous game loop, with draw obviously at the end, so it wouldn't be infeasible to simply terminate the draw call if its taking too much time.
Now if we get that to work the problem is what do we gain other than being able to render the exact same game state twice so to speak?
o/
Nice.
All in all a thoroughly annoying situation.
If the alien makes the pain noise, then it's taking damage. That's played only when their health lowers. Hit indicator doesn't light up either if it's not actually a hit. But you can see green blood regardless whether the hit registers or not. Currently we think the animations are the culprit, hopefully Max put the nail on the coffin on that one.
This I know to not be true. If i fire a bullet at a skulk the hit indicator will instantly light up and the skulk will play the pain noise. Because it is instant, that obviously means its client side, and clients don't determine hits, the server does.
False. Don't pull things out of your butt. First post of this thread explains it:
<a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=116894" target="_blank">http://www.unknownworlds.com/ns2/forums/in...howtopic=116894</a>
Blood is immediate, client-side hit tick comes later (but only comes if it's a hit), pain flinch comes even after that.
But I'll let you know that Max's hit registration fix works sweetly. See you on the battleground, skulks...