Author Topic: Game clock vs. fps + rendering options & effects  (Read 12784 times)

Orion Pax

  • Contributor
  • Regular
  • **
  • Posts: 38
    • View Profile
    • OPX
Game clock vs. fps + rendering options & effects
« on: 2006-02-05, 08:09:38 AM »
Im curious how you might handle this in sgdk2. I consider the fact that game time is directly connected to FPS to be a disadvantage in 1.4.x. There is a frame limiter but it conflicts with vsync which will cause a nasty jitter if they don't match or if the frame limit isnt diviable, ex: 30 fps 60hz vsync. If a project ran slow frame skipping could be imployed to keep game time consistant as well as making sure the gaming experiene was roughly the same for all users. I don't know what frame skipping effects would be on collsion detection and the like though. If there will be any syncing with music it would be a futher concern. I also hope that you add vsync controls for running projects. It is true video drivers can force vsync on or off but the default is 'application specific' leaving the control to the application. 

As this ties a bit into rendering and the fact you are using dx9/d3d I'd like to know if control of the render/blitting will be made avaible as far as linear (blur) or nearest ( blocky) and if the games intended resolution can be overidden by such. It is of particular importance for LCD's but in general as well. Game system emulators have to deal with some of this so perhaps lookinto into something like VBA http://vba.ngemu.com/ would be useful. Something that would be neat is the inclusion of visual filters that run independantly of the game/project in question. A resolution doubler, fake scan lines, fake lcd, motion blurr, etc. If you could invoke different filters per project that would be a plus too but I dont know how feasbile this would be. Motion bluring would rock though =]

I suppose this is pretty much engine related which I know hasnt started yet but just throwing some ideas and thoughts out there. I really do want to see some measures taken to insure the game i run locally runs the same speed for someone else. The frame limiter in 1.4 feels like something incomplete and hacked in.

Render effects
I'm hoping that there will be some tools for lighting and other effects. SGDK2 will be dx9 and its pretty much the norm for modern 2d games. example: If I'm iin the dark but have a glow around the player to see what is immediatly infront of me or there is an explosion/ etc producting light. The level editor could drop various styles of lights like droping a path on a map, be it fixed, moving or in relation to a sprite/object. Particle effects for exploisions, weapons, etc could be scriptable.

With translucany I can do a lot of things like shadow maps via tiles but dynamic lighting will be more tricky depending. Basiclly I'm lookin for coded effects where producing them from a png/file is not the best option. This could be considerd for transition effects, fading or flashing a screen to a color etc as well. I suppose I am invisioning a gfx scripting engine for effects plus light droppin on map. Feel free to tell me I'm out of my gord for the request =P







bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #1 on: 2006-02-05, 09:23:15 AM »
Im curious how you might handle this in sgdk2. I consider the fact that game time is directly connected to FPS to be a disadvantage in 1.4.x. There is a frame limiter but it conflicts with vsync which will cause a nasty jitter if they don't match or if the frame limit isnt diviable, ex: 30 fps 60hz vsync. If a project ran slow frame skipping could be imployed to keep game time consistant as well as making sure the gaming experiene was roughly the same for all users. I don't know what frame skipping effects would be on collsion detection and the like though. If there will be any syncing with music it would be a futher concern. I also hope that you add vsync controls for running projects. It is true video drivers can force vsync on or off but the default is 'application specific' leaving the control to the application.

Kevin

  • Visitor
  • *
  • Posts: 4
    • View Profile
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #2 on: 2006-02-07, 12:39:39 AM »
Im curious how you might handle this in sgdk2. I consider the fact that game time is directly connected to FPS to be a disadvantage in 1.4.x. There is a frame limiter but it conflicts with vsync which will cause a nasty jitter if they don't match or if the frame limit isnt diviable, ex: 30 fps 60hz vsync. If a project ran slow frame skipping could be imployed to keep game time consistant as well as making sure the gaming experiene was roughly the same for all users. I don't know what frame skipping effects would be on collsion detection and the like though. If there will be any syncing with music it would be a futher concern. I also hope that you add vsync controls for running projects. It is true video drivers can force vsync on or off but the default is 'application specific' leaving the control to the application. 

The reason I have resisted moving to time-based movement rather than a frame-based movement is because I want the engine to be deterministic.  I want the same set of inputs to produce the same output.  This makes it possible to record a sequence of action within a game and play it back knowing that it will behave exactly the same on any computer.  Also, on a related concern, I don't want it to be possible (for example) to jump a couple pixels higher on some computers just because they had time to calculate the extra frame at the top of a jump.  Am I misunderstanding the technique here or is this a valid concern?

However, it's possible that SGDK2 might just be flexible enough to support both depending on how you customize your game.  I'm not sure if that's the case yet, but I'm certainly approaching that degree of flexibility in what I'm planning so far.

Time based movement isn't necessarily any less deterministic than frame based movement. You just have to implement the various pieces correctly and design it so that things are consistent for inputs and events at particular times.

As this ties a bit into rendering and the fact you are using dx9/d3d I'd like to know if control of the render/blitting will be made avaible as far as linear (blur) or nearest ( blocky) and if the games intended resolution can be overidden by such. It is of particular importance for LCD's but in general as well. Game system emulators have to deal with some of this so perhaps lookinto into something like VBA http://vba.ngemu.com/ would be useful. Something that would be neat is the inclusion of visual filters that run independantly of the game/project in question. A resolution doubler, fake scan lines, fake lcd, motion blurr, etc. If you could invoke different filters per project that would be a plus too but I dont know how feasbile this would be. Motion bluring would rock though =]

I wasn't planning on doing this myself, but I was talking to a skilled developer a couple months ago (I think it was Kevin Gadd aka "Hiretsukan" (http://www.luminance.org/)).  But he showed me a demo he had with dynamic lighting on 2-D sprites/tiles based on Direct3D.  We talked about him maybe working on some similar effects for SGDK2, but were waiting for SourceForge to release their new version control system (which I think comes out at the end of this month) before uploading all the SGDK2 code and maybe splitting the work.  Cool, I don't think I've been to his web site until just now -- looks like he's done quite a bit of work with game engines (same age as durnurd too).

Real motion blurring would require a lot more than a filter - you'd have to render multiple seperate frames for every displayed frame, which means that if you wanted to display motion blurred gameplay at 30fps, you'd need to render at 60fps for 2x motion blur, or 120fps for 4x motion blur. And the game would need to update at that rate as well. (This is a good reason to go for time-based movement and processing, because it allows you to render more frames than you update and still get reasonable accuracy.)

Other filters like resolution scaling and scanlines are pretty straightforward, though. Draw the game screen to an offscreen render target, and draw that render target to the screen while applying a shader to perform the effect.

Render effects
I'm hoping that there will be some tools for lighting and other effects. SGDK2 will be dx9 and its pretty much the norm for modern 2d games. example: If I'm iin the dark but have a glow around the player to see what is immediatly infront of me or there is an explosion/ etc producting light. The level editor could drop various styles of lights like droping a path on a map, be it fixed, moving or in relation to a sprite/object. Particle effects for exploisions, weapons, etc could be scriptable.

With translucany I can do a lot of things like shadow maps via tiles but dynamic lighting will be more tricky depending. Basiclly I'm lookin for coded effects where producing them from a png/file is not the best option. This could be considerd for transition effects, fading or flashing a screen to a color etc as well. I suppose I am invisioning a gfx scripting engine for effects plus light droppin on map. Feel free to tell me I'm out of my gord for the request =P

I haven't looked into what kinds of things Direct3D can do.  Hopefully we can get Kevin in here to talk about what might be possible.

Given access to render targets and multitexturing, you can pull off a lot of cool things. Lighting's fairly simple. Access to pixel and vertex shaders makes it easier and lets you do a lot of really interesting things - convolution filters (blur/sharpen/emboss/etc), deformation mapping, etc.

Fairly simple, unfortunately, doesn't necessarily mean easy to design, implement, or test. But it's definitely doable. (The performance you'll get out of it is another matter, but generally speaking it should be more than playable on a modern 3D card.)

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #3 on: 2006-02-07, 07:38:14 AM »
Time based movement isn't necessarily any less deterministic than frame based movement. You just have to implement the various pieces correctly and design it so that things are consistent for inputs and events at particular times.

I don't see how that's possible.  In a time-based movement system, the pixel a sprite ends up at in any particular frame is, to some extent, dependent on time (I believe that's the definition of time-based movement).  That means a sprite can be at different locations on different-speed computers.  That means the system is non-deterministic, because time is an unpredictable input.  There may be ways to work around the system's non-deterministic-ness (non-determinism?), but I don't see how it can be turned into something deterministic and still be time-based.  The only ways I can think of to make it deterministic starts going back toward frame-based motion -- for example poll the input and process game logic at fixed intervals, then just draw as many frames as possible between these fixed intervals while only processing sprite velocities and positions -- not doing any collision detection or anything.  I'd consider that time-based rendering with frame-based movement (not even sure if that's possible).  Is that what we're after?

Kevin

  • Visitor
  • *
  • Posts: 4
    • View Profile
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #4 on: 2006-02-07, 07:04:25 PM »
I don't see how that's possible.  In a time-based movement system, the pixel a sprite ends up at in any particular frame is, to some extent, dependent on time (I believe that's the definition of time-based movement).  That means a sprite can be at different locations on different-speed computers.  That means the system is non-deterministic, because time is an unpredictable input.  There may be ways to work around the system's non-deterministic-ness (non-determinism?), but I don't see how it can be turned into something deterministic and still be time-based.  The only ways I can think of to make it deterministic starts going back toward frame-based motion -- for example poll the input and process game logic at fixed intervals, then just draw as many frames as possible between these fixed intervals while only processing sprite velocities and positions -- not doing any collision detection or anything.  I'd consider that time-based rendering with frame-based movement (not even sure if that's possible).  Is that what we're after?
Time is consistent no matter what computer you use, unlike framerate. Therefore, time-based movement would be entirely consistent between machines, while frame-based movement is only consistent if you guarantee a consistent framerate.

In time-based movement, you basically would 'update' certain things in a frame-based way, in that they are updated N times a second in discrete steps. Things like movement and linear animation, however, aren't actually done in discrete steps so you can 'update' them in one huge chunk by determining the amount of elapsed time since the last update and applying changes appropriately.

Generally speaking, this is how time-based processing is done in most games. Some crazy AI systems can update in a time-based manner as well using some sort of complex mathematical abstractions I don't entirely understand, but generally speaking things like AI and pathfinding are frame-based (done in increments) while animation, collision detection/response, and movement can be done in huge steps based on elapsed time.
« Last Edit: 2006-02-07, 07:14:52 PM by Kevin »

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #5 on: 2006-02-07, 11:04:08 PM »
Hmm... I have a feeling this isn't going to be resolved quickly with abstract descriptions.  But I'm up for one more round.  I still get the feeling that time-based movement is non-deterministic compared to frame-based updates because the computer can control exactly how much it does within each frame, but it can't predict how much will get done within a certain timespan.  So the amount that gets done on different machines will be different, causing the game to play differently on faster machines versus slower machines (I guess that's the whole point -- you get a better experience on a faster machine).  But that also means that repeatability of the exact same sequence is difficult to implement at best (and impossible at worst).

Kevin

  • Visitor
  • *
  • Posts: 4
    • View Profile
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #6 on: 2006-02-08, 01:21:26 AM »
Hmm... I have a feeling this isn't going to be resolved quickly with abstract descriptions.  But I'm up for one more round.  I still get the feeling that time-based movement is non-deterministic compared to frame-based updates because the computer can control exactly how much it does within each frame, but it can't predict how much will get done within a certain timespan.  So the amount that gets done on different machines will be different, causing the game to play differently on faster machines versus slower machines (I guess that's the whole point -- you get a better experience on a faster machine).  But that also means that repeatability of the exact same sequence is difficult to implement at best (and impossible at worst).
Here's an example:

Update @ 0.00 seconds (no movement)
Left pressed @ 0.50 seconds
Update @ 1.00 seconds (distance_moved = 0.5) (movement: X -= distance_moved * velocity)
Left released @ 1.25 seconds
Update @ 2.00 seconds (distance_moved = 0.25) (movement: X -= distance_moved * velocity)

Provided that you do the appropriate processing when events (like key presses) occur instead of waiting for the next update, you can get almost exactly the same results every time you run it, even if you vary the update rate. (Of course, rounding errors and floating point accuracy can be a problem, but that's pretty manageable). You just have to handle timing properly everywhere. For things like AI that need to be processed X times a second, you can either update them in chunks or run them in a background thread. However, you will lose complete repeatability there, since there's no real way to execute more code per second than your system is capable of executing. So if you reach the point where your system is just too slow to run the AI in realtime, the system won't be able to maintain correct behavior. But if your system is fast enough to run at 120FPS, you can get totally smooth updating at 120fps without needing to run your AI at 120fps (useful for rendering subframes for doing motion blur, for example), and if your AI only needs to run at 15fps, you can run at 30fps or 60fps and still get the same behavior (even if the framerates are different).

You can approximate this to some extent with a good frameskipping algorithm, but time-based processing is more efficient than frameskipping if done properly, which is definitely desirable if you're aiming to make your game run good on low-end systems (since they're definitely going to be skipping frames.)
« Last Edit: 2006-02-08, 01:32:43 AM by Kevin »

Uhfgood

  • Regular
  • **
  • Posts: 26
    • AOL Instant Messenger - Uhfgood
    • View Profile
    • Indie Flux
Re: Game clock vs. fps + rendering options & effects
« Reply #7 on: 2006-02-08, 03:50:17 AM »
I'll attempt to shed some light on this subject.  Essentially time based movement is supposed to keep movement consistant reguardless of actual frame rate.  It is essentially based on elapsed time between calls, so that if you have a slow computer the object will appear to move at aproximately the same rate as it does on a fast computer.  Let's say you need to move a spaceship from star A to star B, and let's say they're aproximately 50 pixels away from each other.  On a slower computer (hypothetical) the spaceship might move 5 pixels per second, on a faster computer it may move 10 pixels per second.  At 5 pixels per second 50 pixels would take 10 seconds, at 10 pixels per second 50 pixels would take 5 seconds.  But here's the problem, the speed isn't the same, the slow computer takes 10 seconds whereas the faster one takes only 5.  So how do you account for that?  Time based movement.  You call a timing function (usually with millisecond resolution), Save the start time and the end time, and subtract the start time from the end time, to get the actual amount of time elapsed.  You then use it to input into your movement.  Essentially you adjust the pixels the ship moves per step based on how long it's taken since the last call to get_time.  What it results in, is that now, the slow computer will move the ship 10 pixels per second, resulting in the 5 second move, which is exactly what the faster computer does.  (Ie the slower ship moves farther in the step than the faster one does).  The only major problem with this is that with a really slow computer the frame-rate gets a little jerky, because it apears to jump farther to stay in sync with what a faster computer would do.

Frame based movement of course relies on how fast the computer can update frames.  This is why you have some older games that move unplayably fast on more modern computers, and at a correct speed on slower computers.  Newer games that use this method essentially rely on the speed the video can update, which means a slow computer on a modern game appears to make the game move "in slow motion" because it can't update fast enough.

So really it's a tradeoff.  If you can guarantee at least x amount of frames per second on slower computers, then it shouldn't be a problem, because usually you frame-limit games so they don't go too fast on new computers.  (Say 30-60 fps depending on what you're doing).  Time based movement on the other hand requires that the computer be fast enough for the game to feel smooth.

I hope this clears up what you're trying to talk about.

Keith
Keith Weatherby II
http://www.gamesafoot.com
Uhfgood -at- verizon -dot- net

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #8 on: 2006-02-08, 07:07:45 AM »
Well, that pretty much describes what I already knew about time-based movement.  So now let me describe another example of a problem that it presents.  Consider a sprite standing on a cliff looking accross to the right at a wall on the other side.  In the wall (a ways below) is a narrow passageway that the sprite can duck into if he presses toward it while falling down against the wall.  Lets say the sprite is 50 pixels high and the passageway is 52 pixels high and the top of the passageway is a y coordinate of 100.  The sprite jumps to the other side and begins his fall at a y coordinate of 95.

Here's how the frames work out in a time-based movement system:

Fast computer:
Frame 1 y =95 Time = 0.0 sec
Frame 2 y =96 Time = 0.25 sec
Frame 3 y =98  Time = 0.5 sec
Frame 4 y =101 Time = 0.75 sec

Slow computer:
Frame 1 y = 95 Time = 0.0 sec
Frame 2 y = 98 Time = 0.5 sec
Frame 3 y = 105 Time = 1 sec
Frame 4 y = 116 Time = 1.5 sec

Now on the fast computer, when the sprite hits 101 pixels it can fit into the passageway because it has one pixel of space both above ane below and nothing stops it from moving to the right.
On the slow computer, the sprite skips from 98 pixels (where there are to more pixels of solid wall in its way) to 105 pixels (where there are 3 pixels of solid wall from the other side in the way) so it never makes it into the passageway.
This is based on the exact same input but you get completely different results depending on whether you're playing on a fast computer or a slow computer.

The answer to this might be that I should perform collision detection for every pixel along the path instead of only once at each frame.  But now you see why time-based movement starts to be slower than frame-based movement if I want repeatibility.

Kevin

  • Visitor
  • *
  • Posts: 4
    • View Profile
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #9 on: 2006-02-08, 02:46:26 PM »
Well, that pretty much describes what I already knew about time-based movement.  So now let me describe another example of a problem that it presents.  Consider a sprite standing on a cliff looking accross to the right at a wall on the other side.  In the wall (a ways below) is a narrow passageway that the sprite can duck into if he presses toward it while falling down against the wall.  Lets say the sprite is 50 pixels high and the passageway is 52 pixels high and the top of the passageway is a y coordinate of 100.  The sprite jumps to the other side and begins his fall at a y coordinate of 95.

Here's how the frames work out in a time-based movement system:

Fast computer:
Frame 1 y =95 Time = 0.0 sec
Frame 2 y =96 Time = 0.25 sec
Frame 3 y =98  Time = 0.5 sec
Frame 4 y =101 Time = 0.75 sec

Slow computer:
Frame 1 y = 95 Time = 0.0 sec
Frame 2 y = 98 Time = 0.5 sec
Frame 3 y = 105 Time = 1 sec
Frame 4 y = 116 Time = 1.5 sec

Now on the fast computer, when the sprite hits 101 pixels it can fit into the passageway because it has one pixel of space both above ane below and nothing stops it from moving to the right.
On the slow computer, the sprite skips from 98 pixels (where there are to more pixels of solid wall in its way) to 105 pixels (where there are 3 pixels of solid wall from the other side in the way) so it never makes it into the passageway.
This is based on the exact same input but you get completely different results depending on whether you're playing on a fast computer or a slow computer.

The answer to this might be that I should perform collision detection for every pixel along the path instead of only once at each frame.  But now you see why time-based movement starts to be slower than frame-based movement if I want repeatibility.
Your problem there is that you're basing collision detection on pixels and increments instead of vectors.  :P I guess there might be some design reasons for this, but generally speaking you're better off using vectors since the collision detection breaks down into some simple equations instead of requiring a bunch of expensive checks every frame. (And as a bonus, it's much easier to get it to work correctly in situations like the one you're describing.)

Using vectors for collision detection also gives you the bonus of not requiring the player to be so exact in positioning a sprite to fit through a narrow passageway, since you can more easily do things like making a sprite slide across a surface in a convincing manner and determining whether or not it can fit.

In general, if you *do* want to use time-based movement, you want to avoid algorithms that must be processed in set increments (like pixel-based collision detection). Trying to mix the two does result in bad framerates, for the reasons you've noted.
« Last Edit: 2006-02-08, 02:52:44 PM by Kevin »

Uhfgood

  • Regular
  • **
  • Posts: 26
    • AOL Instant Messenger - Uhfgood
    • View Profile
    • Indie Flux
Re: Game clock vs. fps + rendering options & effects
« Reply #10 on: 2006-02-08, 05:00:54 PM »
Yeah, vectors heh.  I implemented a decent collision system that accounted for falling into a tile, however, not for going through tiles or sprites.  That would have been the next thing I learned about collisions.  But usually it's something like drawing a line and then testing if the line intersects the tile(s) at any point.  And by lines I mean mathematical lines, not actually drawing lines on the screen.

That's the theory at least.  I mean obviously a line is a simple case of a vector (or what I understand of vectors)

Keith
Keith Weatherby II
http://www.gamesafoot.com
Uhfgood -at- verizon -dot- net

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #11 on: 2006-02-08, 07:53:20 PM »
So I think that's the problem.  Even if I were prepared to re-invent my understanding of collision detection with the map, I think I'm still going to want to be able to support pixel-based collision detection between sprites, which presents similar problems.  Time-based movement may be OK for specific games, but I fear that trying to incorporate it into a general-purpose engine might present problems and/or might make the kit significantly harder to use.  I don't want to dismiss an important feature lightly, but I really am ... "terrified"?  This is such a funtamental feature that it would affect almost every aspect of the engine, and if I find a problem somewhere down the line, I may have to start all over or completely give up.  I'm not prepared to take such a risk when I have in mind something that I know I have been able to work out in the past in a way that's reasonably user-friendly for a general purpose 2D game creator.  One of the things that makes me nervous is a piece of frame-based tile collision code that I've been carrying along from various projects and slowly enhancing and mutating for the past 15 or so years.  I can't imagine having to re-develop and test that from scratch :o.

Don't get me wrong, I'm not afraid to try new technologies and I may someday make a game with time-based movement or might even figure out a way to incorporate time-based movement support into SGDK2 if it turns out not to be as fundamental as it feels (maybe I can design specific "sprite rules" that are time-based instead of frame-based).  But the only reason I am able to make an engine like this on my own is because I have thoroughly understood and worked with practically every technology I'm dealing with before and am comfortable with it.  If I wanted to trust myself with incorporating time-based movement into a project like this, I think I would have to start small.

Uhfgood

  • Regular
  • **
  • Posts: 26
    • AOL Instant Messenger - Uhfgood
    • View Profile
    • Indie Flux
Re: Game clock vs. fps + rendering options & effects
« Reply #12 on: 2006-02-09, 02:37:36 PM »
I'd say try to find the benefits.  Perfect collision detection, and a game that runs the same on almost every system.  (In other words you don't get the slow down from too many sprites on screen in some frames, and in others were it speeds back up.  Instead it gets jerky but every position is updated to the right position based on how much time it takes).

Most all the games you play nowadays use some form of time based movement.  (In some 3d cases there's an even different technology called rendertweening for 3d, essentially it uses the time and then generates the inbetween poses so you're assured of the smoothest movement possible on your system, but that is way more advanced)

In any case, i'm not going to change your mind.  In fact I found out that anything you suggest to anyone is just not going to take.  Because unless it's their idea, they don't really care much what you think.  Even in cases when someone asks you for your opinion they've already made up their mind.  They just want some validation even if you choose the opposite idea from theirs.

I personally go by the 2-3 rule, if 2 or 3 or more people suggest something, then I start listening, otherwise I don't worry about it.  And we're only 2 people... but I wasn't even trying to convince you to do it, i'm just saying that the problems you're naming are mostly an excuse for the fact you don't want to implement it.  And that's fine by me.  No one else has made a nice system like you have here, and until there's a better system i'm sticking to it.

Keith
Keith Weatherby II
http://www.gamesafoot.com
Uhfgood -at- verizon -dot- net

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Game clock vs. fps + rendering options & effects
« Reply #13 on: 2006-02-09, 03:42:53 PM »
Well, another problem with time-based movement is that if it's running on a low-end computer, and it gets jerky, then suddenly you have no idea where your player sprite is, and you may have walked too far and fallen off a ledge and DIED.  with Frame-based movement, there's no chance of that.
Edward Dassmesser

Orion Pax

  • Contributor
  • Regular
  • **
  • Posts: 38
    • View Profile
    • OPX
Re: Game clock vs. fps + rendering options & effects
« Reply #14 on: 2006-02-09, 07:07:34 PM »
Losing track of sprites & falling off a ledge... this is at what, 5 fps? At 5 fps its gonna suck either way. At 15-20 fps time based would be somewhat jerky but playble vs less then one 3rd the speed the intended speed. Its an easy choice for which I'd rather play.

In a fast paced arcade style game, timing is everything. Someone with a slow machine has a huge unfair advantage. That is if they are even willin to sit through the slow experience. Many people wouldn't notice that a game is running half framerate in time based but no one could miss the fact with all frames rendered it running half the intended speed. Technical issues aside time based makes the most sense for peserving playabilty (as well as the game designer intentions) on low end systems.