So my friend was doing some testing in FBA-rr (and using VirtualDub to count the frames) and figured out that each in game second happens in 54 frames.
So my question to anyone who knows - is the arcade version accurately timed? Should we be seeing 60 frames per second if the game is running at the correct speed?
If the answer is yes, it seems like we’ve got an exact number for how far off FBA is from real hardware: it runs at about 111% speed. Or that means that the emulator is dropping frames? Help me make sense of this.
Okay, so after thinking this through I came up with something much simpler - just run a minute off the game clock in FBA, and check how long that takes in real life time.
From the time the timer starts to the time it hits 39 seconds in a round, takes roughly 54 seconds in real time. Which suggests that the information in the first post may be correct, that it’s running fast enough to drop 6 seconds over the course of each minute. The second method is a more easily testable and easy to understand way of measuring the same thing.
I’m curious if we can reproduce this over several different systems. I’m running the most recent version of FBA on Windows 7 64 bit with the Windows Aero fix enabled. If you try this I’d be interested in finding out if you experience the same thing.
Presumably it should be pretty easy to measure how much faster PS2 and OE are in the same way.
nice ideas. i don’t quite understand what the first method tells us though. if the game runs faster in fba, that would mean the in-game clock also runs faster (assuming timer speed is tied to gameplay speed and are not independent of each other), so the corresponding number of frames inside each in-game second would end up being the same for all versions even if there are speed differences. i might just be having a brain cramp since it’s 4:30 in the morning and i can’t sleep.
the easiest thing, i think, would be to take your second idea and maximize the amount of countable time (a full 99-second blank round) to bring out the largest difference possible, and base the comparisons on that.
on the bad side, this wasn’t helpful for console. both PS2 and 360 OE clocked at pretty much exactly a 1:1 in game time to real time ratio. since we can probably rule out PS2 and 360 being arcade perfect timing wise, that either means the clock in those ports is calculated independently of the gameplay speed, or my test is useless.
yeah I’ve been thinking about this too. that first test might not actually be useful. in game seconds should always be 60 frames assuming that’s how the timer works. if that’s not what we’re getting on his end that could mean that the emulator is dropping frames but I would think the time to frame ratio should be the same regardless otherwise.
honestly I think the best way to get an idea of the gameplay speeds would be to set up a programmable controller, have the inputs do something timing-specific on the arcade version, then move that programmed controller to the other versions of the game and see where the inputs fail. that’d require a lot of stuff that I don’t have though, and wouldn’t give us exact information, just a general “this is how far you can stretch the inputs before the timing fails” and maybe “this version seems to be way further off than this version.”
yeah that makes sense. I’ll give that a whirl and run it 20 times or so and see what I come up with.
from 98 to 38 on the in-game clock is exactly 3240 frames. recorded at 60fps. so real time clock is 54 seconds.
the character select timer is a little different. 29 to 09 on the character select is exactly 1000 frames. real time clock is 16 and 2/3 seconds. extrapolated out to a minute means that 60 seconds on the character select would be 50 seconds in real time.
with that in mind, is the in-game clock even supposed to be a real time clock?
since it’s more or less established that ps2 is faster than either version of OE, their clocks running at identical speeds is surprising. gameplay speed being independent of the timer speed is also something that i find interesting if true.
there’s also the sorta-ghetto jump test where you hold up on both versions and see if/when the jumps become desynchronized. it shows gameplay speed difference instead of the timer, but it doesn’t help quantify the amount of difference.
afaik, in a lot of fighting games this isn’t the case. that’s why “in-game seconds” has become common terminology when people describe time-based events in the games nowadays. in many (most?) games, even the timers in original/perfect versions don’t seem to perfectly match with real time.
well damn, if real seconds differ from game seconds even on original hardware, this topic was a waste of everyone’s time.
I suspect the only way to know for sure is to get someone with a stopwatch to time against an arcade machine. if we find out how fast 99 in game seconds goes on CPS3, we should be able to measure the difference if any exists.
if there is no difference I should think that means the game handles the timer in a pretty whacky way.
Interesting.
Do you record directly with FBA-RR embedded functionality? I would not trust him 100% to have a true representation on what happens on screen as it takes data from framebuffer (or whatever it’s called). I may be wrong though, just something crossing my mind.
I think a more accurate and easier approach would be to record (with an external cam/smartphone/whatever, at 60fps or higher) a full round from the “are you ready” to the end of timer, just pushing up direction all along. This with all versions of the game, with the same camera, and possibly on the same CRT, and no fucking LED TV and their crap ghosting.
Then, with a bit of video editing, you can put all the vids side by side and have a direct view on which one is faster, etc…
it wasn’t a waste. there are still useful concepts presented here even if the arcade timer isn’t perfect, but it probably is anyway if PS2 and OE were. also, remember that fba IS the arcade data. so even if the emulator or your computer hardware runs the game at a different overall speed, it will do so equally to both the timer and gameplay together.
i was kind of wondering about that too, but wouldn’t it be easier to compare if they were direct feed 60 fps recordings? or would that add unwanted variables?
Yeah I like the hold up idea since that eliminates the input lag variable completely from the equation. So any input buffering that happens on any version or any screen lag if you’re not on a CRT won’t be an issue since holding up is not time dependent, and the results should be consistent across all platforms since there’s no real human interaction happening.
I don’t have an arcade machine but I can test PS2, 360, PS3, and FBA against each other with the holding up method. I’m pretty sure my video camera records at 60FPS as well. So long as I can edit the videos together correctly and sync up the starting points that should work.
I can hook up my PS2, 360, and PS3 to a CRT. I don’t have a good way to connect my PC to the CRT though. Presumably for the jump test it shouldn’t matter so long as the start of the round is synched up properly.
i mean like recording directly from the arcade machine or console using a DVR (? sorry, i forget what device it is that people use for this) when making match videos and combo videos. basically, a direct video comparison without camera angle and display device variables. sort of like what this is to pictures, except in video form. i guess it’s a lot of work though. sorry if i’m not being clear.
Ok.
Should work too, but, as a professional nitpicker, i’d prefer to catch the exact same thing we see when playing. Again, it’s more a feeling than a real argument.
Final video quality would probably be way better with DVR though.
I’d check that you have the following options set right in FBA before making any tests vs. cab:
Select the best blitter that yields the best performance (prolly enhanced D3D7)
Blitter options > disable all effects
Auto Frameskip off
Force 60hz refresh rate on (that is if you have a 60hz screen, if you don’t, find one)
Full screen
Triple buffering can help with stuttering and/or dropped frames in full screen, but causes input lag
Also you can set VSync on in the ggpofba.ini by changing it’s value to 1, that too can help with screen tearing and stuttering
Check these or otherwise the gameplay isn’t going to match cab 3s too accuretly and your results will be skewed.
EDIT: I also wouldn’t record the game using anything like Fraps and such, those just cause performance loss too.
Just for completion sake, I finished those in game timer vs real time timer tests, this time stretched for the 99 second clock and repeated enough times to be sure.
From the moment the round starts to the moment the timer hits zero is roughly 1:40 every time on PS2 and 360. It takes roughly 1:30 in FBA running on my computer.
I’ll start recording footage for the hold up test later today.
I thought that might affect the results so I tried with various settings. I tried with D3D7 and the Basic DD7 blitters. I ran it with vsync on and off, triple buffering on and off, fix Windows 7 DWM on and off, and force 60 hz on and off. Got the same results for all of those as far as I can tell.
The only things I haven’t messed with that might make a difference is the difference between fullscreen and windowed. My tests were all done in windowed mode with the Windows 7 Aero stuff enabled. I can test with Aero disabled or in fullscreen mode with the appropriate settings as well if we think it’ll make a difference.
EDIT: I just ran it in full screen mode and made sure that I had all the settings the way you mentioned, including with auto frameskip off. Same results on my end.
For the first test, AFAIK my buddy ran the game in FBA-rr and took the resulting video file and plugged it into VirtualDub to look at it. I don’t have FBA-rr myself and I wasn’t there when he tested it, so I’ve just got his word on that.
For the hold up test I’m just gonna run FBA straight up and point my video camera at the screen.