http://marp.retrogames.com/exe/alphamame32-067-1.zip
All we need now is for Pat to update the database.
AlphaMAME 0.67
Moderators: mahlemiut, seymour, QRS
AlphaMAME 0.67
http://marp.retrogames.com/exe/alphamame-067-1.zip
http://marp.retrogames.com/exe/alphamame32-067-1.zip
All we need now is for Pat to update the database.
http://marp.retrogames.com/exe/alphamame32-067-1.zip
All we need now is for Pat to update the database.
- Barry Rodewald
MARP Assistant Web Maintainer
MARP Assistant Web Maintainer
Great work!
Great work mahlemiut! Thanks alot for this really speedy release 
.
By the way, have you thought about whether to add any extra functionality to prevent 'pausing' yet, as described in the message about the possibility of asing Alphamame?
Thanks,
Kranser.
.By the way, have you thought about whether to add any extra functionality to prevent 'pausing' yet, as described in the message about the possibility of asing Alphamame?
Thanks,
Kranser.
yes Barry, but what about the time flag thing?
You just had 1 byte to each frame of data prior to encryption of that frame that includes a time flag that is zero if the passed time from the previous frame was less than let's say 2 seconds and set to "1" if more than 2 seconds has passed since the previous frame.
If that occurs that would mean the player likely did some pause trick like clicking the window bar etc.
Of course input playback code would have to be adjusted for that adding data thing also.
Given a big part of using alphamame is to prevent pausing during gameplay, this window bar "trick" is too easy to do as a workaround to still pause etc.
You just had 1 byte to each frame of data prior to encryption of that frame that includes a time flag that is zero if the passed time from the previous frame was less than let's say 2 seconds and set to "1" if more than 2 seconds has passed since the previous frame.
If that occurs that would mean the player likely did some pause trick like clicking the window bar etc.
Of course input playback code would have to be adjusted for that adding data thing also.
Given a big part of using alphamame is to prevent pausing during gameplay, this window bar "trick" is too easy to do as a workaround to still pause etc.
if you change the alphamame inp format like that it should proly be when there's a mo better encryption algorithm or when mame changes the default frame size. Also, you don't need to add a byte to determine if each frame it's slow or not. you just add that functionality to the decryption processing, and report the slowness at the end of alphamame playback. But, since barry might be busy doing other things (and really i can do that already with analinp) so if you want to analyze a recording just email me the url and i'll take a look at the slow frames and get back to you.
-skito
> Given a big part of using alphamame is to prevent pausing during
> gameplay, this window bar "trick" is too easy to do as a workaround to
> still pause etc.
Yes, indeed; I agree - especially seeing that this pause method doesn't just allow the user to pause for a few seconds, but minutes and hours if they want (and are able to use something to keep the left-mouse button depressed).
I still think that this issue needs to be addressed in Alphamame.
Kranser.
> gameplay, this window bar "trick" is too easy to do as a workaround to
> still pause etc.
Yes, indeed; I agree - especially seeing that this pause method doesn't just allow the user to pause for a few seconds, but minutes and hours if they want (and are able to use something to keep the left-mouse button depressed).
I still think that this issue needs to be addressed in Alphamame.
Kranser.
> Also, you don't need to add a byte to determine if each frame it's slow
> or not. you just add that functionality to the decryption processing, and
> report the slowness at the end of alphamame playback.
But, when you switch to windowed mode, the playback speed drops for a moment (probably doesn't drop much if you have a fast computer), the same as the speed difference that is noticed during the initialisation of some games, except that the speed change is only for 1 second or so. The pause itself is not recorded, as clicking on the Menu bar stops alphamame from running, so it does not write frames for the time elapsed during the 'pause'. The only way to detect the pause (IMO) is to check at the time of recording - as then at least we can compare the current time at every frame, to detect if pauses have occurred.
Kranser.
> or not. you just add that functionality to the decryption processing, and
> report the slowness at the end of alphamame playback.
But, when you switch to windowed mode, the playback speed drops for a moment (probably doesn't drop much if you have a fast computer), the same as the speed difference that is noticed during the initialisation of some games, except that the speed change is only for 1 second or so. The pause itself is not recorded, as clicking on the Menu bar stops alphamame from running, so it does not write frames for the time elapsed during the 'pause'. The only way to detect the pause (IMO) is to check at the time of recording - as then at least we can compare the current time at every frame, to detect if pauses have occurred.
Kranser.
However, even the 'checking time after each frame' may not work.
What if someone wrote a program (and I'm guessing that this wouldn't be too difficult for those in the know) which when run would:
A) find out which Windows task# MAME was running as and
B) suspend the MAME task (or stop system allocating any time at all to it - in other words the same as a pause).
C) Store the system Time to a temporary backup memory lcoation
D) wait until the player is ready to continue
E) Store back the system time
F) Restart the Task running MAME
Now, the question is, how would we prevent this from occurring (as I'm quite sure it would be possible to do this under windows)?
Kranser.
What if someone wrote a program (and I'm guessing that this wouldn't be too difficult for those in the know) which when run would:
A) find out which Windows task# MAME was running as and
B) suspend the MAME task (or stop system allocating any time at all to it - in other words the same as a pause).
C) Store the system Time to a temporary backup memory lcoation
D) wait until the player is ready to continue
E) Store back the system time
F) Restart the Task running MAME
Now, the question is, how would we prevent this from occurring (as I'm quite sure it would be possible to do this under windows)?
Kranser.
Yes, but while the game is pauses (by holding the left mouse button down on the menu bar) the game will not write any frames (for a minute, an hour, however long it is paused for), and when the pause is released, only a 1-frame drop in speed (if any, as fast PCs may not register much change) will be recorded, before jumping back to normal speed. So, that when playing back only a small slow down will be shown (1 frame or so), this will be almost identical to the situation where (for example) windows decides to do a background task, and the pause cannot be detected (well we will not know for sure if slow down was a pause or not).Chad says:
when it goes to windowed mode it IS recorded in the speed value, even though mame doesn't write any frames because the time written to the next frame written will be writen with a slow speed.
Kranser.
well, not that detectable with the human eye, and also, how do we know whether the brief slowdown was caused by the game requiring extra CPU power (as in the initialisation in some games), or whether windows started a backgroud task, both of these would result in an acceptable brief pause.
But, my main concern is that both of the above situations may pause for 1 second or so, but the overall average frame rate will still be quite high.
However, the same goes for pausing by clicking and holding the menu bar for 1 hour, slowdown will show for about 1 second and the overall average frame rate will still be quite high.
There is a big difference between a 1-second pause and a 1-hour pause!
But this doesn't make sense as a 1-second pause (that is out of our control) is legal, but a 1-hour pause is not. However, both appear the same when analysing the INP.
Also, who's to say that going into windows mode on a super fast computer (or maybe a faster computer in 5 years time) would show much slowdown at all - there might not be much slowdown on fast machines.
Kranser.
But, my main concern is that both of the above situations may pause for 1 second or so, but the overall average frame rate will still be quite high.
However, the same goes for pausing by clicking and holding the menu bar for 1 hour, slowdown will show for about 1 second and the overall average frame rate will still be quite high.
There is a big difference between a 1-second pause and a 1-hour pause!
But this doesn't make sense as a 1-second pause (that is out of our control) is legal, but a 1-hour pause is not. However, both appear the same when analysing the INP.
Also, who's to say that going into windows mode on a super fast computer (or maybe a faster computer in 5 years time) would show much slowdown at all - there might not be much slowdown on fast machines.
Kranser.
yeah the slowdowns for fast computers switching tasks will certainly be faster, but i don't think the speed of a frame is going to be the same when you pause for 1 second verses an hour. 1 minute verses an hour would proly both yield a 0 speed frame, and both are bonifide cheating attempts. The 1 to 10 second pauses will yield speeds of 10%-30% which might be acceptable, it just depends on where you draw the line, we haven't drawn that line yet... But certainly if i see a 0% speed in the middle of a recording (haven't yet) that wasn't caused by someone doing an accidental alt-enter. Pausing on fast computers vs. slow computers will yield the similar speeds so there's no issue there.
These pauses ARE detectable (by programs if not by the human eye) and are detectable "forever" the data is in the inp to stay.
The overal framerate of a paused recording will be LEGAL of course, but the recording would not be legal because there was a pause in it. I'm not sure if i'm adding to the confusion here, Your concerns led me to believe there might be a problem with alphamame here but i still think everything is cool, just that the users can't really detect potential pauses reliably yet (but the editors can with analinp :).
These pauses ARE detectable (by programs if not by the human eye) and are detectable "forever" the data is in the inp to stay.
The overal framerate of a paused recording will be LEGAL of course, but the recording would not be legal because there was a pause in it. I'm not sure if i'm adding to the confusion here, Your concerns led me to believe there might be a problem with alphamame here but i still think everything is cool, just that the users can't really detect potential pauses reliably yet (but the editors can with analinp :).
-skito
Ok thanks Chad, your explaination is very clear now
Well, if you are sure that, even on fast computers, the frame rate will always briefly drop to 0% when a pause is attempted, then I agree that maybe we do have all the information we need. . But, if it doesn't always drop to zero, then we have a problem.
Also, could a program be written that would suspend the AlphaMAME task for a period without causing the frameskip to drop to 0% I wonder?!
Thanks for clarifying that Chad.
Kranser.
Well, if you are sure that, even on fast computers, the frame rate will always briefly drop to 0% when a pause is attempted, then I agree that maybe we do have all the information we need. . But, if it doesn't always drop to zero, then we have a problem.
Also, could a program be written that would suspend the AlphaMAME task for a period without causing the frameskip to drop to 0% I wonder?!
Thanks for clarifying that Chad.
Kranser.