frame locking

[arnoldemu]

If we have a game that, for example can sometimes take more than 1 frame to execute, if we always lock to the vsync, then we have the potential that sometimes it'll run at 50hz, and then sometimes at 25hz when it slows down. The problem here is that the game speeds up and slows down.

to resolve this we can use frame locking. We can make sure the game always runs at 25hz, then the speed up/slow down doesn't happen. The disadvantage is that we are running at a slower frame rate all the time.

This is how it can be done:

Code Select Expand


;; number of frames -1
LOCK_FRAMES equ 1 ;; 1 for 25fps, 2 for 16fps etc, 3 for 12fps

;; init
xor a
ld (signal),a
ld (frame),a


main_loop:

;; wait for signal from interrupt code - this is triggered every 25fps in this example
signal_wait:
ld a,(signal)
or a
jr z,signal_wait
xor a
ld (signal),a

;; .. do something


my_interrupt:
ld b,&f5
in a,(c)
jr nc,not_vsync

ld a,(frame)
inc a
ld (frame),a
cp LOCK_FRAMES
jr nz,not_vsync
xor a
ld (frame),a

;; here we can do the double buffer update for the hardware


;; indicate we reached the locked frame rate position
ld a,1
ld (signal_code),a


not_vsync:

;; ...
;; int code
;; ...
ret

frame:
defb 0
signal:
defb 0



The interrupt tests if the vsync has happened. If it has it updates the frame count. If the frame count reaches our value it then resets it and signals it has been reached. Code can then wait on this to lock itself to 25fps.

[TFM]

Where is the gain in slowing down a game?

[gerald]

Where is the gain in slowing down a game?

Did you miss something in the original message

If we have a game that, for example can sometimes take more than 1 frame to execute, if we always lock to the vsync, then we have the potential that sometimes it'll run at 50hz, and then sometimes at 25hz when it slows down. The problem here is that the game speeds up and slows down.

to resolve this we can use frame locking. We can make sure the game always runs at 25hz, then the speed up/slow down doesn't happen.

So, if you look it from the player perspective, slowing down the game gives a smother experience.
I personally prefer a game that runs at constant 25fps than one that speeds up and down.

[TFM]

And I prefer a game which runs smooth at 50 fps, even if it slows down from time to time to jerky 25 fps. However an option in an game could let the user decide about an automated slowdown.

[gerald]

And I prefer a game which runs smooth at 50 fps, even if it slows down from time to time to jerky 25 fps.

If it slows down, that it does not run smooth 
How do you define "time to time"? Once every 1, 5, 20 seconds ? when there are more than X objects ... ?

I do not bother that game have 25 or 50 FPS refresh rate, but I do appreciate when the "game time" stays linear.

I do not like games that get a speed-up when there is nothing to display, and then slow down when there is more than X objects. And by slow down, I mean that an object expected to move at  32pixel/s moves a 16pixel/s.

Would you like a race game where you feel like running at 300km/h when there is no one in front of you, but feel like running at 50km/h when there are 5 cars ahead ? Not me.

[TFM]

In a game you will always have sitiations in which it will slow down by factor 3, 4 or even 5. I don't think it would be a good idea to slow down by factor 5 just to have it all always linear.

A slowdown of factor 2 may be valid for few games only.

To have examples you can take a look at Antiriad or others. In Antiriad CPC the factor is actually abouve 5.


Furthermore if a game slows down only in 10% of its game-play, there is no need to slow down the other 90% of time.


It finally always depends on the game itself. Guess we can agree in that.

[gerald]

@arnoldemu :
Are you keeping track of "game time" or do you just count rendered frame ?
If you have a "game time", and (enough base ram) you might consider using triple buffering and start rendering a new frame without waiting for the frame sync.

[TFM]

Hmmm.... a good idea for 128 KB games.


If using double buffering, with some tricks you can also do a similar thing. Close before the display of one frame ends you can already start calculation the next one. And short after the new frame is displayed its calculations get finished. It also works with overscan if you have the upper part of the screen made first. I tried this and you can 'steal' up to 20% of the next screens time without a problem.

[TotO]

In a game you will always have sitiations in which it will slow down by factor 3, 4 or even 5. I don't think it would be a good idea to slow down by factor 5 just to have it all always linear.

Making an engine to be constant not mean that was the worst speed, but the engine work differently.

[gerald]

In a game you will always have sitiations in which it will slow down by factor 3, 4 or even 5. I don't think it would be a good idea to slow down by factor 5 just to have it all always linear.

It should not need that much to keep a somehow linear perceived time. Either you design your game level so you do not get into trouble (or less than 10% of the time), or your game engine estimates how many frame sync it takes for rendering one image according to the changing objects,  and then render the proper frame.

Furthermore if a game slows down only in 10% of its game-play, there is no need to slow down the other 90% of time.
It finally always depends on the game itself. Guess we can agree in that.

Agreed

[TFM]

"Influence on level design". That's a good point.

[arnoldemu]

@arnoldemu :
Are you keeping track of "game time" or do you just count rendered frame ?
If you have a "game time", and (enough base ram) you might consider using triple buffering and start rendering a new frame without waiting for the frame sync.

In my case I am counting vsyncs and using that to make the game time constant.

I know there are other methods such as triple buffer and frame compensation. I'll make a post about these too

(I work for a games company too ).


EDIT: The problem I was experiencing was that I moved a constant amount each game loop. When there were less rings the game speeded up and you could miss them easily. That is wrong, I need to move at a constant speed and the speed must not change here. So I currently lock the frames, yes it doesn't run at 50hz.

I could frame compensate, but I haven't tried this on cpc yet, I may be able to do this on my game, or it may take too much time to do.

[arnoldemu]

And I prefer a game which runs smooth at 50 fps, even if it slows down from time to time to jerky 25 fps. However an option in an game could let the user decide about an automated slowdown.

In an ideal world all games would run at 50fps.

This is not always possible, especially when it comes to games with intensive calculations (e.g. 3d).

Not even all modern games run at 50fps!!! Yes it is true!!!

On most they use frame compensation where they time how long each game logic loop takes, then they adjust the real world values (e.g. speed in kph) so that it is always correct. You just don't notice it.
On the CPC this is more trouble because you have to do multiplies and divisions generally to adjust values to compensate.

So here I presented one way people can use to help make their games smoother. I'll present other methods too. This was not meant to be: This is the only way to do it.

This was meant to be: here is one thing you can do, there are others too.

[arnoldemu]

when making games, even on modern hardware you often have to take compromises or make adjustments to make it run either in memory or with a good frame rate.

Remember a game is not about graphics and sound only.

There must be good gameplay.

[TFM]

In an ideal world all games would run at 50fps.

This is not always possible, especially when it comes to games with intensive calculations (e.g. 3d).

Not even all modern games run at 50fps!!! Yes it is true!!!

Well, then it's either a lack of resources (64 KB CPC) or sloppy programming (PC side). If I run Cyber Huhn on a 128 KB machine it works with 50 fps even in the 3D space. (You got 64 chicken and 21 shots to compare in all 3 dimensions for being close to each other). Ok, with 30 or more sprites on screen it comes to a slow down, but that does not disturb me. 

[AMSDOS]

If we have a game that, for example can sometimes take more than 1 frame to execute, if we always lock to the vsync, then we have the potential that sometimes it'll run at 50hz, and then sometimes at 25hz when it slows down. The problem here is that the game speeds up and slows down.

Wouldn't that make it an emulator fault if things were slowing down that much?

[ralferoo]

Wouldn't that make it an emulator fault if things were slowing down that much?

The problem isn't an emulation issue. It's that you only have a fixed amount of processing time per frame (usually 19968us or about 0.02s). There's only so much drawing you can do in this time - for instance, it's impossible to draw to every pixel in a frame because there just isn't the time to do it.

So, the programmer has a choice - either you draw less than a full screen each time (e.g. you might only need to redraw sprites but not wall areas) or you accept the fact that you can't run at 50 frames per second and run at 25 instead.

The problem comes when you try to take the first approach, but there's just too much to update (e.g. suddenly there are more enemies on screen) and you can no longer to it all in 0.02s. There are then 2 ways you can try to recover from this. You can either wait for the next whole frame so you waste most of the second frame, but which allows you to synchronise the screen (which might prevent flickering) or you just carry on the next frame and hope that you manage to render it in less time to catch up. If you're clever, you might no update some objects that aren't as important. Doing this, however, there's always the risk (in fact, it's usually likely) that the next frame will take too long too, so you gradually build up a slight time deficit each frame and then at some point, this rolls over to being an entire missing frame. Another disadvantage with this approach is that you will see tearing and flickering on the screen, you will probably need to double buffer the screen and so use up more precious memory.

So, like with most things it's a compromise. Most games, even modern games on super powerful hardware prefer to have a slower refresh rate but more action and no risk of frame drops and so would run at 25fps (actually consoles are invariably all 30fps nowadays) rather than 50fps. Obviously, for some games reaction time is the most important issue, so you'd use as high a frame rate as possible and solve the compromise by having less happening.

[AMSDOS]

Ok, so I was just wondering if someone could physically make a Real CPC run faster by tinkering with Resistors or some other hardware (CTRC type?) of that nature. I heard of people doing this with their PCs, though I'm unsure if it relates to what's being discussed here - IIRC it was more of a performance thing in PCs.

I've been playing the old ACU type-in N-SUB a bit, which is BASIC, though BASIC 1.1 seems to run the game a little bit better than BASIC 1.0, though both versions seem to slow up a bit whenever a lot is happening on screen, I guess being written in BASIC isn't helping it, though I cannot help but wonder if some of that relates to how much is going on, which spoils a bit of an enjoyable game.

[fano]

Interesting and usefull example, regular frame time control is very important for gameplay.More , a game running at constant speed looks fairly better than a game with changing speed.

[redbox]

Iregular frame time control is very important for gameplay.More , a game running at constant speed looks fairly better than a game with changing speed.

Definitely, I agree.

Prehistorik 2 is a good example of a potentially great game ruined by slow-down IMHO (although I still can't work out what's slowing it down so much).

[fano]

That's a good example.I'd speak of R-Type as frame can go from <20Kµs to >100Kµs so i can not imagine not using frame locking there (it is a more a bit complex as scroll is updated only 1 frame on 2 but the idea is the same)

[steve]

CPC-Wiki has a page on making the CPC run at 6Mhz, here 6 MHz CPC - CPCWiki

[AMSDOS]

CPC-Wiki has a page on making the CPC run at 6Mhz, here 6 MHz CPC - CPCWiki

Hmm, that's interesting. I thought my 6128 might of been tinkered with before I brought the machine to make it run faster than usual. Though after reading about the disadvantages with that technique, I know my 6128 is still happily reading standard discs.

I just wondered cause I always remember playing Wizard Willy on my 464 and it would slow down when more monsters appear onscreen and even in Level 3 onwards when they were firing fireballs at you - the trick I found was to just keep moving and shoot them as you were moving along, I just don't remember it happening on my 6128, though by that stage I would of had the game nailed every time I played it.

[ivarf]

The slowdowns and speedups in Knight Lore never bothered me. I liked it! For me it was a feature... At the time it never crossed my mind that the game shouldn't have been like this.


In my mind Demomakers and C64-users are too obsessed with 50Hz. Interesting to read that many of todays games on todays hardware are less than 50Hz