Welcome, Guest. Please Login or Register.  • Help
SMF Underground
+ SHMUP-DEV » SHMUP DEV FORUMS » Assistance
|-+ Should Rendering Always Be in Sync With Game State?

Pages: [1]   Go Down
0 Members and 1 Guest are viewing this topic. Topic Tools  
Read December 16, 2011, 01:34:38 PM #0
klaim

Should Rendering Always Be in Sync With Game State?

Hi,

Last year I made this prototype : http://code.google.com/p/radiant-laser-cross/

Now this weekend I'll remake this project in a clean way, but will also build it as a task-based concurrency and parallel-algorithms based system. That's half learning and half performance requirement. Also I will use Ogre3D as rendering engine instead of SFML.

So I was happy having planned my system, then I just hit something while preparing :

to make the bullet-hell fair, should I have rendering ALWAYS in sync the game state?

Most games can skip some frames if the rendering isn't fast enougth but for a bullet hell, slowing down the rendering to floor the update speed seems a better idea.

But maybe I shouldn't care?

Any advice or example of bullet hell rendered graphically not in sync with the game update?
« Last Edit: December 16, 2011, 01:36:53 PM by klaim »
Offline  
Read December 16, 2011, 03:18:32 PM #1
Hornet600S

Re: Should Rendering Always Be in Sync With Game State?

Of course skipping frames is a no-go for shmups, especially bullet-hell-style.

I'd say the best bet is to aim at a fixed frame-rate, 60 Hz for example. If your game for whatever reason (soooo many bullets and enemies) cannot render fast enough, then slow down. Many Cave shooters actually slow down on purpose in such situations. Though in that case it's a well controlled slow-down.

In general you should take care that the shmup-experience is practically 100% identical and replicable on any of your target devices. That again means: if possible you should avoid situations where the avg. PC would slow down. If you find such a situation you should consider to add an on-purpose-slowdown there, so it also slows down in the same way on faster PCs.
But in general better avoid it at all. I cannot really imagine a shmup bringing down a more or less half-decent PC, so most likely you just made something wrong if it happens nevertheless.

If you don't plan to have an online-ranking system, then you can ignore most of the above. It's only really important if scores need to be compared in a 100% fair way.


"When the Amiga came out, everyone at Apple was scared as hell."
(Jean-Louis Gassée - Head of Macintosh development at Apple)
Offline  
Read December 16, 2011, 03:22:57 PM #2
klaim

Re: Should Rendering Always Be in Sync With Game State?

Do you mean that if it's all gameplay without score, I shouldn't care?
Offline  
Read December 16, 2011, 03:38:18 PM #3
Hornet600S

Re: Should Rendering Always Be in Sync With Game State?

- never skip frames.
- better go for a fixed frame rate.
- if serious online ranking matters then only controlled slow-downs.
- if it's a hobby shmup then no need to care for anything.


"When the Amiga came out, everyone at Apple was scared as hell."
(Jean-Louis Gassée - Head of Macintosh development at Apple)
Offline  
Read December 17, 2011, 10:17:15 AM #4
klaim

Re: Should Rendering Always Be in Sync With Game State?

Thank you very much, you've put things in perspective.
There was two goals for me with this project :
 1. Make a complete version of this bullethell
 2. Practice concurrency in games, with another game in mind.

The other game is already part developed but I stopped working on it few years ago and want to get back to it soon. The problem is that I want to make sure it scales with multicore, so I need to practice task-based concurrency. However, you could categorize it as Real Time Strategy so there is no need for frame-game sync.

I still want to make a great game of RLC but I didn't thought about the scoring at all...

Assuming I'm going the way of making the rendering async, then I need to find a way to make it great without scoring system... And with excellent performance I guess.

That's quite a challenge.

As I'm starting to work on it today, I guess I should try things once I get the controlls working.
Offline  
Read December 17, 2011, 04:29:07 PM #5
kdmiller3

Re: Should Rendering Always Be in Sync With Game State?

Asynchronous rendering introduces a delay between what the player sees and what is actually happening, and can cause subtle problems in "arcadey" genres like shmups.  The discrepancy is proportional to the object's speed, so it might not be noticeable for relatively-slow-moving bullet formations in a "bullet hell" shmups.  Just keep in mind that the delay can make your game feel less responsive.  (This is more a problem when you have a low simulation rate and interpolate several rendering steps in between.)

The worst case is when the simulation rate and rendering rate are close but not identical (such as 60Hz simulation versus 59.97Hz rendering) so the two slowly drift in and out of phase.  It would be better to let the simulation run slightly fast or slow so it's always in phase.  The player is much less likely to notice the 60Hz simulation running at 59.97Hz (0.05% slow) than a frame of latency that builds up every 20 seconds.
« Last Edit: December 17, 2011, 04:32:44 PM by kdmiller3 »
Offline  
Read December 18, 2011, 03:59:44 AM #6
hima

Re: Should Rendering Always Be in Sync With Game State?

I've always wondering about how Cave manage to intentionally slow down the game and it's still the same on all machine. Touhou also have this fast forwarding replay. I think both are using fixed framerate. But I'd like to know what's the technique to make it always have the same result, regardless of the speed of the PC.
Offline  
Read December 18, 2011, 10:04:16 AM #7
Hornet600S

Re: Should Rendering Always Be in Sync With Game State?

@hima
Of course I actually don't know, since I didn't have the chance to take a look at some Cave-sourcecode Smiley
But it probably works that way:

- design the game and the engine to always run more than fast enough on your target devices (which in the case of Cave probably isn't that hard since they target consoles / arcade), like kdmiller3 said above.

- make the game 100% deterministic. If you want to be really sure use integer or fix-point math instead of floats for the game logic (for the renderer it doesn't really matter), since FPU-results may differ among different platforms.

- now a controlled slowdown is nothing more than a tweak of the update-ticker. Normally it would be let's say 1/60, now you make it 1/120 and since you're still running at 60 Hz it appears to slow down to half speed.

Another way would be to internally run the game logic at 120 Hz, display every second picture, so you get your normal 60 Hz. And to get a 50 % slowdown just skip every second call to the update function.


"When the Amiga came out, everyone at Apple was scared as hell."
(Jean-Louis Gassée - Head of Macintosh development at Apple)
Offline  
Read December 18, 2011, 11:10:26 AM #8
hima

Re: Should Rendering Always Be in Sync With Game State?

@Hornet600S
I have thought about that. I actually have a bullet hell game programming book in Japanese that show how to code an 'Awakening Mode' like in ESPGaluda. In there, it seems to do what you did, that is call update every other frame instead of every frame.

But what I don't understand is, wouldn't this affect the bullet pattern? Like,  the code is

Code:
bullet.Direction += 2;
bullet.Speed += 5;

Then, the number of time the update function is called will affect the pattern greatly. I've seen video on youtube that some people hack Touhou to 90 FPS, but surprisingly other than the game is sped up, the pattern seems to stay the same. That's when my head went kaboom @_@;

Using integer is a good point though. I think I should start doing that in future games.
Offline  
Read December 18, 2011, 06:12:08 PM #9
kdmiller3

Re: Should Rendering Always Be in Sync With Game State?

If your game logic is deterministic and uses a fixed time step (whether implicit or explicit), it should produce the same result regardless of how often you run the update.  The game will run faster or slower but each simulation step should produce the same result.
« Last Edit: December 18, 2011, 06:16:32 PM by kdmiller3 »
Offline  
Read December 19, 2011, 12:18:51 AM #10
Hornet600S

Re: Should Rendering Always Be in Sync With Game State?

@kdmiller3
Great article you linked to! A must-read.

@hima
Considering that article I have to slightly relativate what I said before:
Just tweaking the update-ticker does not always work, of course. It depends on the math you use. Simple stuff like linear moving bullets or similar stuff will work well, but your physics engine may very likely produce unexpected results unless you do as the article above explains.


"When the Amiga came out, everyone at Apple was scared as hell."
(Jean-Louis Gassée - Head of Macintosh development at Apple)
Offline  
Read December 19, 2011, 01:25:18 PM #11
klaim

Re: Should Rendering Always Be in Sync With Game State?

I fix timesteps of all my games and was aware of the potential problems with inputs, but I think there might be ways to still get no input lag with a concurrent-tasks aproach, the problem being more making sure the rendering is always running more or equal frequency than the game update (the "step" in timestep).

It looks like depending on the game itself, opportunities to apply concurrency are more or less reduced, particularly in bullet-hell context.

Pointing that scoring fairness might be a problem with async rendering (assuming you get sync rendering but might have more rendering frames for non-game-objects graphic elements for example) was a very good thing as now I'm considering interesting alternative gameplays.

Thank everybody.
Offline  
Pages: [1]   Go Up
Jump to:  

Page created in 0.079 seconds with 18 queries.