News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Carnivius

How to find games speed?

Started by Carnivius, 13:22, 07 July 18

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Carnivius

Not really sure where to ask this but since it's relating to games I'll put it here and if it's to be moved then please do so.
I just wanted to ask how do you find out the FPS of a particular CPC game?  Is there a feature on emulators that lets you know?  I don't mean the 50FPS of monitor updating and such but the cycle speed of any running CPC games cos clearly a lot don't run or scroll at every one of the 50 frames per second the screen would update.  I think some scrolling action games ran at about 12 or 13?
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

GUNHED

You could use the single-step / debugging mode of some emulators and trace the ray, so you see what's going on. But that's tedious. Which emu do you want to use for detecting fps?


Also you could set a breakpoint at &0038, that one will pop us six times per hardware frame.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

andycadley

FPS isn't really a meaningful metric in 8-bit games. There are plenty of titles in which the screen technically changes every 50th of a second, which would imply 50fps- but they aren't updating every part of the screen at that rate because the work gets split across multiple frames and so they're arguably more like 25fps or 12.5fps.

Carnivius

Quote from: GUNHED on 13:52, 07 July 18
You could use the single-step / debugging mode of some emulators and trace the ray, so you see what's going on. But that's tedious. Which emu do you want to use for detecting fps?


Also you could set a breakpoint at &0038, that one will pop us six times per hardware frame.
I'm sorry but I don't know what much of that means. :/  I don't know what rays, trace, breakpoints of hardware frames are.  :(

Quote from: andycadley on 13:54, 07 July 18
FPS isn't really a meaningful metric in 8-bit games. There are plenty of titles in which the screen technically changes every 50th of a second, which would imply 50fps- but they aren't updating every part of the screen at that rate because the work gets split across multiple frames and so they're arguably more like 25fps or 12.5fps.
I just remembered I asked a similar thing a while ago http://www.cpcwiki.eu/forum/programming/fps-of-scrolling-in-certain-games/msg138791/#msg138791 and Axelay gave a couple answers about RoboCop being 12.5 fps and Stormlord being 17fps (possibly dropping to 12.5 when too many enemies) and was curious how that information is found.  I just wanted to know if there was a simple feature in an emulator such as Caprice Forever or Winape or whatever that pops up a number of that actual speed during a game.  They often have one for the 'system' speed (Winape shows this FPS in the bottom right corner of the window) in which it displays 50FPS if your PC is running the emulator properly but obviously that's not the rate the game is updating.   Just wanted a display thing like that if it's possible in any of the emulators.
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

andycadley

Quote from: Carnivius on 14:17, 07 July 18
I'm sorry but I don't know what much of that means. :/  I don't know what rays, trace, breakpoints of hardware frames are.  :(
I just remembered I asked a similar thing a while ago http://www.cpcwiki.eu/forum/programming/fps-of-scrolling-in-certain-games/msg138791/#msg138791 and Axelay gave a couple answers about RoboCop being 12.5 fps and Stormlord being 17fps (possibly dropping to 12.5 when too many enemies) and was curious how that information is found.  I just wanted to know if there was a simple feature in an emulator such as Caprice Forever or Winape or whatever that pops up a number of that actual speed during a game.  They often have one for the 'system' speed (Winape shows this FPS in the bottom right corner of the window) in which it displays 50FPS if your PC is running the emulator properly but obviously that's not the rate the game is updating.   Just wanted a display thing like that if it's possible in any of the emulators.

Basically, you just eyeball it and guess at how it "feels". You can try to be a bit more scientific by disassembling the game, finding a key routine that will be called once per "logical" frame - drawing Robocop, for example - and then see how much time elapses between each call but even things like that are problematic (the game might not bother redrawing something if you aren't moving for example).


There's no real way an emulator can just show a "frame rate" figure, because it just doesn't mean anything.

Carnivius

Well that's frustrating.  I don't know how you eyeball something and figure it's 12.5 rather than 12 or 13.   I was hoping it would be possible to easily get a result from any game being played in the emulator and be able to use that to compare with other games for the purpose I required.  Guess I'll have to forget about that.

Thanks anyways.  Have a good day.
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

andycadley


If the main game loop fits entirely within a frame, you'll get 50fps. If it takes two frames, you'll get 25fps. Three is ~17fps and four is 12.5fps. Anything else is extremely unlikely because 8-bit games aren't usually written to cope with variable CPU speeds that would mandate handling movement in a framerate independent way - even early 16-bit games often didn't, I'm sure we've all experienced some of those old PC games that run insanely fast on more modern machines.


The only other variance you might get are games that occasionally take a little too long when things get very busy and thus drop down a level (from 17fps to 12.5fps for example), which is when you see that notorious slow down effect and things get choppy.

VincentGR

I would like to have a real fps counter too.
There was a guy on youtube who did that with modern games on consoles but can't recall his channel.


Anyway, I think it's very difficult to count it as sometimes games have multiple framerates even at the highest peak of their speed.
As an example see agony on the amiga, scrolls at 50 but enemies are slower. Maybe this happens to cpc games too.

ukmarkh

I always wondered if you could record the video and then look at the FPS, by slowing and speeding up...

ldaneels

Please spend a few seconds reading Andycadley's (multiple) replies, that should answer all your questions.

@UKmarkh: that wouldn't work simply because recording a video of something is not that something. i.e: if I take a video of you, it is not you but an image of you. It does not breathe, think, eat...

reidrac

The emulator should be able to know that by checking when the video memory is changed; and unless the game updates the screen at different times, you can tell the FPS.

I think RVM2 debugger supports that, so when it is released, it would be possible to find how many FPS have most games.
Released The Return of Traxtor, Golden Tail, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

Axelay

Quote from: andycadley on 13:54, 07 July 18
FPS isn't really a meaningful metric in 8-bit games. There are plenty of titles in which the screen technically changes every 50th of a second, which would imply 50fps- but they aren't updating every part of the screen at that rate because the work gets split across multiple frames and so they're arguably more like 25fps or 12.5fps.


I think that's dramatically overstating things.  While there certainly are situations where it's going to be difficult to nail a game down to a frame rate, I've not actually come across a game where I've wondered what the frame rate was, and not been able to determine one with a fair degree of certainty in some way or other.  Though mostly via disassembling and looking for different things in different games, so that doesn't help Carnivac any.  My point though is that, at least as far as I'm concerned, fps most certainly is relevant on an 8 bit platform because it's a fundamental part of the the player experience through the control responsiveness it provides.  Even with the sorts of game you mention with screen updates staggered across frames, you can still arguably consider the player characters update rate as the 'effective' frame rate.

andycadley

Yes, but it's that "effective" frame rate, which is more of a "how does it feel" thing, than an actual frame rate that matters. You can toggle one pixel on every frame and claim it's 50fps, but if all the sprites move on alternate frames it isn't going to feel like that. And once you accept that how it feels is what you're really trying to measure, it's fairly obvious why automated tools are unlikely to give you an answer that's meaningful.

MaV

Here's a way to do it in WinApe:
1 - open the debug screen and set a breakpoint in the main game loop
2 - set the T counter in the debug screen to zero (click cross on the right)3 - press F9 to continue gameplay; the breakpoint will follow immediately (by human standards) and the cycle counter will show a number; write down the number
4 - repeat 2 and 3 over and over again to get an average, or to discover the top and bottom values to determine minimum and maximum fps

insert the numbers into this formula:

fps = 50/(cycles/19968)
frames_per_second = frames_of_device / (cycles_of_one_game_loop / cycles_of_one_CPC_frame)

It's tedious but it gives you a good indication of the games' speed.The hardest part is to find the main game loop, and in the game loop the part that is executed only once per game frame. Obviously there'll be quite a bit of variation in the numbers depending on what is going on in the game, so you need to repeat it often. Ideally - that is if the game has a constant frame rate - the numbers' variation will be within one CPC frame (19968 cycles), so the fps should be the same. If it goes beyond, either the breakpoint is set at the wrong part of the code or the game actually has a varying frame rate.
Unfortunately, it's almost impossible to play the game effectively this way.

If some parts are updated slower that should be visible just looking at the changes on screen of every frame, I guess.
Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

AMSDOS

Should be simple enough to work out in the short Assembly game I wrote:-[
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

MaV

Sure, here are the numbers:
73436  = 13.6 frames
59885 = 16.7 frames
59902 = 16.7 frames
59917 = 16.7 frames
59892 = 16.7 frames
59921 = 16.7 frames

I set the breakpoint at the start of your main game loop. The first value supposedly happens due to evaluation of a button press or something similar. The others are gained while not doing anything on screen, just running the game and waiting for the break point to happen. Playing the game while being interrupted by the debug screen is nigh to impossible.


Two things in my above post that I need to clarify: When I write frames_per_second it's rather "if this value would happen 50 times" the game would achieve this amount of frames per second. That's why a lot more examples and calculating an average are important. Secondly, the fractional part of a result should be ignored. It's just an indicator that there's a bit of leeway that can be used to add code within a frame (presuming it happens frequently and the fps are constant).

I wonder if Executioner would add an "fps breakpoint" that calculates the cycles take each time the point is passed and records this numbers until the user interrupts the game and then calculates the fps. One advantage would be that we'd be able to determine average fps in actual, uninterrupted gameplay.
Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

andycadley

Quote from: MaV on 11:38, 08 July 18
Two things in my above post that I need to clarify: When I write frames_per_second it's rather "if this value would happen 50 times" the game would achieve this amount of frames per second. That's why a lot more examples and calculating an average are important. Secondly, the fractional part of a result should be ignored. It's just an indicator that there's a bit of leeway that can be used to add code within a frame (presuming it happens frequently and the fps are constant).

Yes, this is basically the technique I described in post #4 and it certainly works if you can find a suitable bit of code. Essentially you're replacing count frame buffer swaps (which is what a modern FPS counter is doing) with counting some other point that gets hit once per "logical frame". You don't need to ignore the fractional part though, 16.7 is exactly the number that comes out if the main game loop takes 3 physical frames - because 50/3 = 16.7ish
QuoteI wonder if Executioner would add an "fps breakpoint" that calculates the cycles take each time the point is passed and records this numbers until the user interrupts the game and then calculates the fps. One advantage would be that we'd be able to determine average fps in actual, uninterrupted gameplay.

It would be an option, though you need a reasonable understanding of the code to be able to use it in any meaningful sense and so not terribly useful for a non-developer. And I'm not sure there's an enormous need from a developer perspective, if you're writing the code yourself you are likely to know roughly how much time things take and thus what your target "frame rate" really is.

MaV

Quote from: andycadley on 16:31, 08 July 18Yes, this is basically the technique I described in post #4 and it certainly works if you can find a suitable bit of code. Essentially you're replacing count frame buffer swaps (which is what a modern FPS counter is doing) with counting some other point that gets hit once per "logical frame".
Yes, I was just underpinning your info with a ready to use formula. :)

QuoteYou don't need to ignore the fractional part though, 16.7 is exactly the number that comes out if the main game loop takes 3 physical frames - because 50/3 = 16.7ish
My bad, you're totally right.
Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

VincentGR

Well here is an example of frame counting  :o



https://www.youtube.com/watch?v=cR65ZIR7KS0


12:40 and on

Carnivius

Quote from: Axelay on 09:02, 08 July 18

I think that's dramatically overstating things.  While there certainly are situations where it's going to be difficult to nail a game down to a frame rate, I've not actually come across a game where I've wondered what the frame rate was, and not been able to determine one with a fair degree of certainty in some way or other.  Though mostly via disassembling and looking for different things in different games, so that doesn't help Carnivac any.  My point though is that, at least as far as I'm concerned, fps most certainly is relevant on an 8 bit platform because it's a fundamental part of the the player experience through the control responsiveness it provides.  Even with the sorts of game you mention with screen updates staggered across frames, you can still arguably consider the player characters update rate as the 'effective' frame rate.
That's what I thought (but I did so in more stupid thoughts). Also amusing you used the old version of my name before I changed it to something a tad more unqiue that Hasbro (of Transformers) couldn't trademark. :P

Quote from: MaV on 10:28, 08 July 18
Here's a way to do it in WinApe:
1 - open the debug screen and set a breakpoint in the main game loop
2 - set the T counter in the debug screen to zero (click cross on the right)3 - press F9 to continue gameplay; the breakpoint will follow immediately (by human standards) and the cycle counter will show a number; write down the number
4 - repeat 2 and 3 over and over again to get an average, or to discover the top and bottom values to determine minimum and maximum fps

insert the numbers into this formula:

fps = 50/(cycles/19968)
frames_per_second = frames_of_device / (cycles_of_one_game_loop / cycles_of_one_CPC_frame)

It's tedious but it gives you a good indication of the games' speed.The hardest part is to find the main game loop, and in the game loop the part that is executed only once per game frame. Obviously there'll be quite a bit of variation in the numbers depending on what is going on in the game, so you need to repeat it often. Ideally - that is if the game has a constant frame rate - the numbers' variation will be within one CPC frame (19968 cycles), so the fps should be the same. If it goes beyond, either the breakpoint is set at the wrong part of the code or the game actually has a varying frame rate.
Unfortunately, it's almost impossible to play the game effectively this way.

If some parts are updated slower that should be visible just looking at the changes on screen of every frame, I guess.
This is interesting.  I may give this a go when I have a bit more time to wrap my brain around it.  Thanks. :)
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

Axelay

Quote from: Carnivius on 15:09, 11 July 18
That's what I thought (but I did so in more stupid thoughts). Also amusing you used the old version of my name before I changed it to something a tad more unqiue that Hasbro (of Transformers) couldn't trademark. :P


Ugh, sorry about that.  Was going by memory.  Was an old memory apparently.  ;D

Powered by SMFPacks Menu Editor Mod