Aaron Giles wrote:Removed cpu_scalebyfcount(). Changed input ports to register a frame
callback, which is called immediately after throttling and updating.
This is the proper "sync point" between emulated time and real time.
Moved all analog and digital port processing into a central place
here. Added tracking of time since the previous frame update and use
that as an estimate for the time of the current frame. This is used
to scale analog ports without the use of cpu_scalebyfcount(). This
is not perfect in the case where frame rates are dynamic (vector
games), but works well for other cases. [Aaron Giles]
I can't understand a thing (I suppose it requires very good knowledge of MAME source code, as many updates reports do )
This doesn't tell us much; is this supposed to change something with input lag, or is just cleaning and reorganizing of the program, I couldn't tell...
(very useful post I know)
Well unlike other stuff in the whatsnew log this one is relatively easy to understand. I'll help you with some terms and this should make sense(correct me if i'm wrong with anything)
input ports = anything that goes into mame to control games (trackball, joystick, keyboard, mouse, lightgun)
frame callback = means the function will be done BEFORE displaying the "next" frame, not while it is displayed.
analog and digital port processing = the handling of the data from the input ports
"Added tracking of time since the previous frame update and use
that as an estimate for the time of the current frame. This is used
to scale analog ports without the use of cpu_scalebyfcount()." = this is only for analog input (like wheels, tackballs, mice)
Ok, mame 0.124 is released and I did a bit of testing.
I tested with Armed police batrider wich is known to have relatively high input delay.
the testing was done with the frame by frame option. But the feel of the game seems to prove that the frame by frame mode is accurate in comparing mame versions.
in mame 0.99/0.101 -------> 4 frames delay
(probably 4 frames for earlier versions too)
in mame 0.122 ------> 5 frames delay
(probably the same between .103 and .123)
in mame 0.124 ------> 4 frames delay
To give an idea of how high it is in batrider: most games have 2 frames delay in 0.101 and 0.124
also testing with other games 0.124 seems to be on par with mame 0.101. Which is pretty good.
edit: I tested Darius Gaiden and guess what it is faster in 0.124 with only 3 frames instead of 4 in 0.101.
We can safely say that MAME 0.124 is THE BEST VERSION of mame as of right now.
Last edited by nimitz on Tue Apr 08, 2008 2:04 am, edited 2 times in total.
My laptop still trips over the same button combinations it always has (CTRL + Up/left arrow keys, and down/right).
Lag? Get a computer, a better one, s'all I have to say. I have to increase my CPU's power to get it to run some games without skipping, but that's normal.
Well for Batrider, it seems that even though the delay is 4 frames in the frame by frame mode the actual gameplay feels more like 3 frames delay which could be explained by differences in the way the emulation for this specific hardware is programmed.
Also 2 frames delay in the frame by frame mode = no delay. It takes one frame for mame to take the actual input and then it is displayed in the next frame. So 3 frames delay is only about 16.6 milliseconds behind instant response.
nimitz wrote:Well for Batrider, it seems that even though the delay is 4 frames in the frame by frame mode the actual gameplay feels more like 3 frames delay which could be explained by differences in the way the emulation for this specific hardware is programmed.
How does that work, anyhow?
Here's what I think, from what I already (think I) know:
Twin Cobra always seems to stutter along, though that looks like partial updates (in the original hardware) and the game's frames not syncing perfectly. So there perhaps the 1/10 setting means that one out of every ten frames normally shown is dropped.
I think it might work this way:
Normally all (100%) of the frames are shown, but the underlying emulation always processes every opcode (in theory). When you cut down the frames displayed rate it is simply dropping that frame of output, but still doing the underlying emulation.
Ed: What you are talking about seems to be screen tear because of the lack of v-sync. Twin cobra runs at 54.9** frames per second (not 60) and when displayed in 60hz without v-sync or triple buffering you get this kind of weird effect.
you can solve that by increasing the frame rate of to game to 60 with the on-screen display or by turning v-sync or triple buffering on (but then if you do this you add some mighty input delay (well actually its video lag))
im kinda confused.....ive never noticed one bit of lag with anything im running through mame.....
im using mame32
what kinda systems are you guys running this on??
Its not about display lag we are talking about. Its about input lag: The time it takes for the input you make (like pressing a button) to the time it shows on your screen (in the game). Its a matter of milliseconds, MOST people will never notice it. But I think some people see it more than others and themore competitive you get at games the more you notice it.
)
