[SDL] Disappearing newlines

[Mike Powell]

Okay, is there a reason that the mailing list keeps stripping out half the newlines and making messages nearly unreadable?


Mike Powell wrote:
> I think David is completely correct. However, I want to emphasis one point:
> "it's easier and safer to just run the game logic at a fixed frame rate."
> Notice the "game logic" point. You don't have to RENDER at a fixed frame rate, so long as the game logic is at a fixed rate.
> The way I typically do it is with something like:
> for (int i = 0; i < deltaTime; i++) {    updateGameLogic();}
> Thus, the game logic gets called once per millisecond (assuming deltaTime is in milliseconds), regardless of what frame rate you're rendering at. Of course, you can adjust this easily to run once every 3 milliseconds, or 10 milliseconds, or whatever value you like, to speed things up, though as the increments get larger the results will get less precise.
> David Olofson wrote:> On Saturday 13 October 2007, necronology at cox.net wrote:> Wow that paper is something. My opinion is that he easy answer is as> follows>[...the usual delta time solution...]> I think you're completely missing the point, actually.>> In the simple case of your example, there is indeed no difference. However, any real game> will have collision detection, time driven "AI" and other stuff that is not directly> related to user input or video frame rate.>> For example, collision detection: As soon as an object is moving more than one pixel per> frame, collisions will frequently happen *between* frames. That is, first there is no> collision, and next, the collision already happened some "random" (frame rate dependent)> time ago - and you might even fail to detect it at all, if you're relying on naïve "Do we> have an intersection right now?" tests.>> Another example; time driven "AI": We have this enemy firing ten bullets a second at the> player. Ideally, this
 would produce a nice spiral of evenly spaced bullets as the player> circles around the enemy - but unless the rendering frame rate happens to be exactly N * 10> fps, the spiral will have a sawtooth like distortion to it, caused by interference between> the nominal firing rate and the rendering frame rate. And if the rendering frame rate should> ever drop below the firing rate, the firing rate will drop with it!>> Considering all math and logic needed to deal with these problems properly (and this without> *really* getting it right anyway!), I strongly suggest that it's easier and safer to just> run the game logic at a fixed frame rate. This way, you can safely use simple iterative> methods (ie vx+=ax; vy+=ay; x+=vx; y+=vy; if(collision) die(); if(!count--) ax=-ax; etc)> like it was often done back in the days of constant frame rates throughout the games. You> don't have to test the game logic at various rendering frame rates, as the logic behaves> *exactly* the same way ever
ywhere, every time, whether the frame rate is 10 or 1000 fps._______________________________________________SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
> 
>