Question of SHMUP game timing

[MSW]

This is kind of an odd question. Especaily considering modern computer hardware...

But which is prefered for a SHMUP. A fixed frame rate, or a full bore game update rate?

When too much was happening on screen in older SHMUPs we would get slowdown - reflecting that both the game internals and the screen were updated in lockstep. Also the game would seem to have a fixed update rate (say 60 updates per second). This is easy enough to program for in the main game loop. Update the game internals, draw the screen, then wait a certain number of CPU time ticks inorder to maintain an established update rate.

However there seems to be a big push in general game development to seperate the game internal updates from the screen updates...allowing the game to update as fast as it can but scaleing movement and such to fit the performance capabilities of the computer running the game. This allows the game to run at many hundreds of frames per second in some sections on some computers; while allowing it to drop to something like 20 frames per second in others (like an automated frame skip)...with the idea it still takes just as long for actions to occur at either end of the game update performance spectrum.


Was playing a NES emulated game the other day when my spyware program fired up to perform a scheduled search and I could still play the game despite the massive slowdown...But with a "full bore game timing" system it can be like flipping through unrelated game screen shots as so much game time passes between each frame, makeing it nearly impossible to play.

Obviously, I much prefer the fixed update rate...but what do you guys think?

[BPzeBanshee]

I understand that computer programmers may want the most compatibility but I dont think they will fix that issue with frame rate options. Also I can't help but feel discriminated when my top-of-the-range PC for its time runs something like Portal at say, 69 FPS but some other guy tells me his runs at 300.
I prefer fixed frame rates because it's a useful way to determine just how good or bad your PC is for running a specific game, whereas with this other method you mentioned you're trusting the developers. And I can't trust the developers, not when companies like Valve say Half-Life 2 will be able to run on DX6-era PCs really well when really it doesn't.

[the2bears]

I'm a firm believer in fixing the frame rate. Some will disagree.

Bill

[battlegorge]

Read this:
http://dewitters.koonsolo.com/gameloop.html

I think the best solution is a fixed timer for game logic.
But the graphics drawing should be seperate.
With vsync the framerate should always match the monitor refresh rate.
Without vsync i am not sure.
The fps could reach several hundreds in a 2d shmup, maybe include a max framerate setting of 100 fps.

[BryanM]

WaitForVerticalBlank or an equivalent is necessary to make a game not look like poo. Since monitors have and can be set to different refresh rates, it is necessary to allow a variable to represent the update speed.

You can update the length of time that's passed frame to frame, or use a fixed number based on the person's monitor refresh rate (which will look smoother than frame to frame if your time measuring function isn't more precise than a millisecond). A fixed number will create real slow down if it's ever necessary, which won't be consistent from machine to machine. A constantly updated one will give you your slideshow if necessary.

If you want consistent predictable slow down, you're much better off simulating it. If bullets > crapload: LoopSpeed * 2 / 3 or somesuch.

[worstplayer]

Slowdown can be annoying, but frameskip almost always means certain death.

Also, getting variable timing right isn't always easy, you don't only have to adjust object speeds but also delays between attacks (remember Half-Life instagib crowbar?), enemy spawn timing, and tons of other things.

So, fixed is the way to go IMO.