forums.marpirc.net

It seems to me even for the speed calculation and fps mame is using some time() function call.

As stated above though how would you know the difference between a 1-2 frame 0% speed that was from a long pause versus a 1-second pause or evne just some stupid utility that starts up in the background that for that 1 second really slows mame cuz of big HD activity?

I thought even if the speed drops a lot for a couple frames nothing is really suspected there because otherwise you could be playing a long game and just because your system does something like perhaps even re-time syncs with a time-server so the time variable is slightly adjusted that can result in low speed detection!

Heck if I would want an honestly played game to be DQ'd just because the system auto-adjusted it's time by 1 second or so at some point during play or because some util loads and starts running where during the loading you get a lag in mame for a few frames.

The 1 to 10 second pauses will yield speeds of 10%-30% which might be acceptable

How do you figure that? I guess it depends how the "speed" is calculated. Is that done by a running average over so many frames or seconds? If so then yes your above has a point...if frame by frame...then it really can't as even a 1 second delay would have 1 frame in that last 1 second so that's already down at 1.67% speed.

Think about the time-adjustment thing some...and how that would be reflected within an alphamame inp.

It seems like you really need to go full screen and not allow windowed mode for alphamame so there isn't this window bar pause possibility.
It's tons easier to deactivate windowed mode and force full screen mode in the code than it is to add new code to try and detect that kind of "pause".

You can still allow the args for size etc. of the game display...but not windowed mode. That will make the emulation run a little faster for many anyway cuz the video won't also be updating other display stuff on screen as you are playing.

it all really depends on how the time is measured or if it's averaged (which i think it is) if it's averaged it doesn't just use the time for one frame it uses the time for lots of frames averaged. I explained this on another thread somewhere (alphamame pause is possible something or other). I should proly go to the code sometime to clarify it so we know that a pause of this amount of time will result in a speed of this much...

Even if you disable the mechanism for going to a window you can MAKE it happen anyway, and weather you make it happen or it is allowed to happen it will still result in a slow frame and we'd detect it.

Kranser: yeah i was thinking about if it was possible to time the window switching at the right clock cycle to avoid detection, if the timing code is done right (and i think it is) this would not be the case because the end timer can be the start timer of the next frame thus eliminating the possibility of catching it at the right moment between timings (which would be hard anyway) and if it averages it then it would be impossible to avoid it because it would get averaged into the surrounding frames (something i'm pretty sure it doesnt do) i just have to look at the code...

Chad, yes I agree but my point above was how can you differentiate between low speed from a time delay among frames from a pause versus a system/OS time adjustment where it just happens to resync and adjust it's time by 1 second at some point during your gameplay?

Most players have that on in their OS so the system just automatically checks time versus a time-server and adjusts to the nearest second. Given they have that feature on so it's syncing likely daily I would doubt they would be off by more than 1-2 seconds.

The time() call would be shifted from that adjustment in time...thus give a false positive of bad speed or a pause when nothing of that sort was done.

You definitely don't want a false positive where you end up dq'ing a valid record just because you felt they paused when they perhaps didn't.

So, keep that in mind when you draw "the line" of what seems like something in a drop in speed that can just be a 1-2 second time shift or lag from some background task doing some HD maintenance or whatever versus what was caused by a pause in the game. If that running average is large enough I guess you could make a chart of seeing a drop in the frame rate/speed what that means in terms of a lag in time or pause...plus see how many times that occurs during the gameplay etc.

I think it also depends on the game involved. If a shooter game or maze type etc. pausing for a few seconds doesn't really benefit you at all. If anything it will screw up the timing. Those even short pauses can really make a difference for the quiz/puzzle type games where you might only have a few seconds to provide an answer or do a move etc. Pausing for a few seconds here and there would definitely give you more time for each move and thus an unfair advantage over others.

because an OS issue will make mame pause for 1 second, unless it's intializing. The time frames measured here are 12/60=1/5th of a second long, if some game operation takes 5 times what it normally should (1 second) it's the only operating system issue that could be doing that is something that would be trying to slowdown the game you are playing... And, a pause of 1 second is proly NOT going to be behind the line for pausing, also I'm not going to be the one drawing the line: Examples of pausings to speed% and votes will, and we don't have that data yet. the game does depend a lot too... but if you really are using pause it's something you couldn't do in the arcade even if it is a shooter. pausing for a second delibrately is really a form of slowdown, it proly doesn't give you a distinct advantage but it certainly would give you more points with saving a life because of the extra decision time to evade a barage of fire that should have killed you, etc. there will be plenty of lee way when the real effect of os issues has on the pause detection, but i can bet heavily that normal os usage will not be in the range of what real pauses do.

no comment on a time shift by the OS from syncing with a time-server?
That shift is quick and likely wouldn't even be noticed by the player in mame or see any actual drop in actually playing it.

Yet the drop would be there cuz a second was skipped or perhaps even if adjusted the other way a second was redone...so you would perhaps see speeds displayed well over 100% for a bit from that time change.

I'm pretty sure it doesn't use the "clock" to calculate time, it uses clock ticks... but again i still have to look at the code... need more time in my day!

http://marp.retrogames.com/exe/alphamame-067-2.zip (Win32 console)
http://marp.retrogames.com/exe/alphamame32-067-2.zip (Win32 GUI)
http://marp.retrogames.com/exe/alphadmame-067-2.zip (DOS console)

Fixed Namco System 1/2, and Shanghai 3 driver crashes (from MAME Plus!)
Also, added Super Street Fighter II: The New Challengers (ETC 930911) and Mighty Pang! (Japan 001011). Both are fully playable.

Thanks, Barry! I've been wanting to try some of those Namco games under AlphaMAME.

Screw-up #435256...

The CRCs for the graphics SIMMs of Mighty Pang are jumbled up. I saw it, and promptly forgot to fix it. As long as the files are named the same as MAME expects, it should work though. Blame Raz, I copied the graphic SIMM loading from CPS2MAME to save time trying to figure out the graphics.

EDIT: Eh, forget it all, I have the correct gfx SIMM dumps now. The CRCs in AlphaMAME are quite correct. Makes no noticable difference though.

something else is wrong with 67 (not only alphamame but regular too), puzzloop lost sound :(

That's a known bug, no fix for it as yet.

http://marp.retrogames.com/exe/xalphamame-067-2.zip (Linux/X11 console)
Linux version up now. Have fun testing it. Let me know if it runs (or even if it doesn't) on systems other than Red Hat.

Build info:
System - Red Hat 7.2
Compiler - GCC 3.0.2
Architecture - i386, Linux, X11
Xv hardware stretching enabled
DGA enabled
i386 joystick driver enabled (-joytype 1)
ASM 68000 CPU core enabled
Dynamic Recompiling MIPS 3/4 CPU core enabled
Will run on x86 systems only.