It is possible to pause the game during recording. To do so, use mame window mode (ALT-ENTER), and click on the window bar. The game stops.
Block your mouse button and you can go for a walk
.I hope it helps you ...
Laurent.
Pausing is possible with alphamame66
Moderators: mahlemiut, seymour, QRS
Pausing is possible with alphamame66
Hello,
It is possible to pause the game during recording. To do so, use mame window mode (ALT-ENTER), and click on the window bar. The game stops.
Block your mouse button and you can go for a walk .
I hope it helps you ...
Laurent.
It is possible to pause the game during recording. To do so, use mame window mode (ALT-ENTER), and click on the window bar. The game stops.
Block your mouse button and you can go for a walk
.I hope it helps you ...
Laurent.
good thinking, but not really. this is "possible" with some windows configurations (many will let the game play while you can't see the screen thus proly losing a life or two while you're back in windows mode.) In some situations you can actually pause the game and do other windows eXtra crapPy stuff, pausing the game of course is still illegal since it's not in the spirit of true arcade play (and can be detected in the alphamame inp). Inp files with pauses detected will get disqualified if detected.
If you suspect a pausing has occured, this please notify the editors.
If you suspect a pausing has occured, this please notify the editors.
-skito
I wonder if "pausing" by clicking on the window bar would be detectable within the alphamame inp. If some real time variable stamp is saved within each frame of data, then it would easily be detectable if someone did this because you would see a skip in the time stamp within the inp that doesn't correspond roughly to the frame rate. It could easily just be something like if more than 1 second has passed from 1 frame to the next...then a flag pops up in watching the inp within alphamame or some check util saying the game was "paused".
I would set it at a whole second because you wouldn't want some freak pc-util check that bogs down your system for a split second here and there to result in that time skip.
Maybe the speed detection the time stamp is already saved within each frame so if you paused the game with the window bar then it would already be detectable and show up as a drop in speed.
I would set it at a whole second because you wouldn't want some freak pc-util check that bogs down your system for a split second here and there to result in that time skip.
Maybe the speed detection the time stamp is already saved within each frame so if you paused the game with the window bar then it would already be detectable and show up as a drop in speed.
anything that takes cpu cycles away from mame is detected with alphamame, so pause detection is a subjective/objective (never know which) science. I'm not all that familiar with the timing calculation done by mame for the alphamame speed but here's a possible scenario, if it gets an average speed for the last 60 frames. If you pause (or steal cpu cycles away from mame) for 1 second and your game normally reports 60 frames per second, a speed "might" be reported for an alphamame frame at 50%=100*(60/2)/60 because it took 2 seconds instead of 1 second to show 60 frames. If you pause for 10 seconds and should alphamame shows a 10% speed = 100*(60/11)/60=9.09%. But i think the averaged speed stored might be not averaged by the last 60 frames, since it rarely works this way in practice.
With old insecure m35tg3 mame i would consider a pause if it went below 30% speed, since i was able to pause for 10 seconds and still only get 30% speed frames, when i should have recorded 10% speed frames. And other times you can pause for only a few seconds and get a 0% speed frame.
NOTE : pause detecting will be NOT applicable for parts of the inp that do not involve game play, i.e. the initialization of mame often records very low speed frames which will be ignored by the detector (although included in the average speed of the whole recording :).
With old insecure m35tg3 mame i would consider a pause if it went below 30% speed, since i was able to pause for 10 seconds and still only get 30% speed frames, when i should have recorded 10% speed frames. And other times you can pause for only a few seconds and get a 0% speed frame.
NOTE : pause detecting will be NOT applicable for parts of the inp that do not involve game play, i.e. the initialization of mame often records very low speed frames which will be ignored by the detector (although included in the average speed of the whole recording :).
-skito
I would say that any pause would show as at least a moderately sharp drop in speed. Although, speed is only calculated each 12 frames, so it might be 'buffered' a bit, depending on the length of the pause.
And do note that this really only affects Win32 versions, if you're running DOS MAME in a window, then you're nuts.
And do note that this really only affects Win32 versions, if you're running DOS MAME in a window, then you're nuts.
- Barry Rodewald
MARP Assistant Web Maintainer
MARP Assistant Web Maintainer
tried
I tried doing this on Alphamame, and it works in general.
When going into windows mode (ALT+<RETURN>) the framerate skips down to 1% briefly, and when I paused by clicking (and holding) the Menu bar (which I did for about 20 seconds) the framerate also briefly went down to 1% on playback - but the average framerate was still high enough for the recording to be accepted, and no matter how long I pause for, the playback only goes to 1% for a brief second - so it's not dependant on how long you pause for - as it would be if you had set Windows doing other tasks in the background to reduce speed.
The FPS figure was 585 when I recorded, but on playback it thinks that 696 FPS was recorded!
This is definately a bug in Alphamame. And I agree with LN2 that a time check is needed. However, this time check wouldn't need to be saved in the INP (however, it would be useful), but Alphamame would need a way of flagging the INP file when 1 second, or more, has elapsed between one frame and the next - either by storing a ERRORFLAG value (and displaying a message on playback that the game was paused at this point), or by storing the time of each frame, and detecting any 1+ second gaps in time during playback and warning the user if there was any.
Also, on exit from AlphaMAME, it should say if a 'Pause' was detected.
What do others think?
Regards,
Kranser.
When going into windows mode (ALT+<RETURN>) the framerate skips down to 1% briefly, and when I paused by clicking (and holding) the Menu bar (which I did for about 20 seconds) the framerate also briefly went down to 1% on playback - but the average framerate was still high enough for the recording to be accepted, and no matter how long I pause for, the playback only goes to 1% for a brief second - so it's not dependant on how long you pause for - as it would be if you had set Windows doing other tasks in the background to reduce speed.
The FPS figure was 585 when I recorded, but on playback it thinks that 696 FPS was recorded!
This is definately a bug in Alphamame. And I agree with LN2 that a time check is needed. However, this time check wouldn't need to be saved in the INP (however, it would be useful), but Alphamame would need a way of flagging the INP file when 1 second, or more, has elapsed between one frame and the next - either by storing a ERRORFLAG value (and displaying a message on playback that the game was paused at this point), or by storing the time of each frame, and detecting any 1+ second gaps in time during playback and warning the user if there was any.
Also, on exit from AlphaMAME, it should say if a 'Pause' was detected.
What do others think?
Regards,
Kranser.
Last edited by kranser on Thu Apr 03, 2003 4:14 pm, edited 1 time in total.
The reason why the length of the pause doesn't matter is that while you are clicking (and holding) the Window menu bar, AlphaMAME is not running, as Windows (at least Windows 2000) stops the task, waiting for you to move the window to a new location. Thus, the speed will not be saved every 12 frames (or whatever) until ALphaMAME is resumed.
Hope this makes things clearer.
kranser.
Hope this makes things clearer.
kranser.
the pause detection needs some intelligence not worth putting in alphamame i think. although it would be nice to at least put a flag up for further investigation. It would at least have to skip the first 100 or so frames since otherwise it would always think there is a puase with mame initialization the way it is. analinp the inp analyzer (that does autofire detection and slowdown detection) makes a distribution report of speeds and is easy to spot check (with out having to patientlly look at the F11 screen through the whole recording) for pauses; i do this for almost every recording i confirm and others that are already confirmed. I might make a stripped down analinp that just does this speed distribution analysis for users, provided that the other editors think it's alright and if barry can't think of an easy way to pause flag in regular alphamame....
To really acurately pause detect would be time consuming, you'd have to first deteremine there was a slow frame and then actually go to that part of the game where it happened to make sure it wasn't during a cutscene or something that wouldn't benefit the player. And there'd have to be some rules/tests to ensure we know certain recordings were paused for X time and created Y% speed frames to be sure we can correctly acuse someone of using pauses if theyre speeds are such. (something already done for autofire and slow down detection.)
To really acurately pause detect would be time consuming, you'd have to first deteremine there was a slow frame and then actually go to that part of the game where it happened to make sure it wasn't during a cutscene or something that wouldn't benefit the player. And there'd have to be some rules/tests to ensure we know certain recordings were paused for X time and created Y% speed frames to be sure we can correctly acuse someone of using pauses if theyre speeds are such. (something already done for autofire and slow down detection.)
-skito
It sounds complicated having to check whether the game is in a cut scene or an initialise phase (first 100 frames)!
Wouldn't it be far easier to compare the computer time at the current frame with the time at the next frame (could slow down AlphaMAME of course!) and see if there is a big difference? Seeing that during cut scenes and initialation phases, the frame count is still continuing, this could automatically disregard any slow-down in these phases.
But, if windows slows down the game (either by another process taking 100% of the CPU, or by switching to a Window mode (from Full screen) [if your computer is not so fast], or by pausing the game by holding mouse clicked on the window memu bar, then the time between frames will be different!
Kranser.
Wouldn't it be far easier to compare the computer time at the current frame with the time at the next frame (could slow down AlphaMAME of course!) and see if there is a big difference? Seeing that during cut scenes and initialation phases, the frame count is still continuing, this could automatically disregard any slow-down in these phases.
But, if windows slows down the game (either by another process taking 100% of the CPU, or by switching to a Window mode (from Full screen) [if your computer is not so fast], or by pausing the game by holding mouse clicked on the window memu bar, then the time between frames will be different!
Kranser.
I totally agree with you that it should be complicated to synchronize some timer with the inp recording timer, to detect any pause due to the windows system.
But what do you think of making impossible to record an inp in window mode ?
Well, are there many players trying to break records in window mode ? I'm not so sure...
Laurent.
But what do you think of making impossible to record an inp in window mode ?
Well, are there many players trying to break records in window mode ? I'm not so sure...
Laurent.
laurent, it isn't likely but if you have what you know is a 6-hour game ahead of you and 4 hours into it you really have to get AFK for a few minute for bathroom break or whatever, I can easily see someone knowing that window bar thing playing in windowed mode so if they must then they just right-click or whatever in that bar so the game is essentially "paused".
I think the above is a good suggestion..to not worry about time stamps within the inp...but just have some encrypted info for a flag where if the time without frame advanced has passed beyond a few seconds, then that flag is set within the inp so on playback it lets the viewer know the game appears to have been paused etc. which of course would make it illegal.
Just players know alphamame had that in it would be enough to keep most from even attempting a workaround to allow a pause.
The problem is when that occurs how do you add it in the inp file? You would have to formally close and reopen the file to edit those few bytes in the header if stored there....if stored in some footer at the end when you hit escape then that would work but then what happens to someone that had a great game going and lost power or computer crashed etc. That footer info would be missing...so perhaps 1 byte every frame that would indicate if timing was "ok" would be the way to go.
That way you could even know exactly what point in the playback the pause occurred....so the score up to that point could actually still be counted.
I think the above is a good suggestion..to not worry about time stamps within the inp...but just have some encrypted info for a flag where if the time without frame advanced has passed beyond a few seconds, then that flag is set within the inp so on playback it lets the viewer know the game appears to have been paused etc. which of course would make it illegal.
Just players know alphamame had that in it would be enough to keep most from even attempting a workaround to allow a pause.
The problem is when that occurs how do you add it in the inp file? You would have to formally close and reopen the file to edit those few bytes in the header if stored there....if stored in some footer at the end when you hit escape then that would work but then what happens to someone that had a great game going and lost power or computer crashed etc. That footer info would be missing...so perhaps 1 byte every frame that would indicate if timing was "ok" would be the way to go.
That way you could even know exactly what point in the playback the pause occurred....so the score up to that point could actually still be counted.
Yes, I agree LN2 that the best solution would be to have a 1-byte flag (or maybe a 1-bit value (the top bit of the Frameskip# ?) on each frame to indicate whether it is ok (there was no long gap between this frame and the previous one!).
As it would be helpful to know when a pause happened, and this method would also show multipl;e pauses (if the game was paused more than once).
I still think AlphaMAME should print a message at the end if a pause occurred or not.
Kranser.
As it would be helpful to know when a pause happened, and this method would also show multipl;e pauses (if the game was paused more than once).
I still think AlphaMAME should print a message at the end if a pause occurred or not.
Kranser.