Donkey Kong (us set 1) slow on mame 147

[Haze]

"Is it possible that the input/frame buffering present in some games would be unnecessary when running on a PC that's fast enough to ensure everything gets done in under a frame?  Perhaps there should be a configuration option to turn buffering on or off, depending if it's necessary in your setup, or for certain games but not others?"

There are some theoretical ways, doubling the framerate would mean you can present with 'half a frame' delay after the frame is finished rather that a complete frame, but not a magic bullet.

You're always going to have to prepare an image, then send it with emulation tho, as opposed to having a display updated in realtime with exactly what is going on.  That means until you've reached the end of a frame in emulation, you can't present whatever frame it is you've rendered until the next refresh on the pc.

It's by no means a field I'm an expert in, I do the actual system emulation code, not the core work, but it's a problem even the minds of Sony etc. have failed to fix, with many complaining of similar noticeable issues with the software emulators they use for back compatibility etc.

[Haze]

Speaking of gambling games. Is Omega's Double Up dumped?

This one here.

http://www.arcade-museum.com/game_detail.php?game_id=7628

I know it isn't the same as HI-LO Double Up Joker Poker or Cal Omega - Game 15.9 (Wild Double-Up).

If it isn't dumped then is there any interest in dumping it? I have one.

Good question, the honest answer is I don't know, based on the screenshot on the site I can't say I have an exact match for it in my head, but there are quite a few Cal Omega games supported.

If you have the means to dump it then by all means do, there is definitely interest in getting them dumped and given the vast number of games and minor variations on games it's always worth a punt.

[Haze]

By the way, I figured that I would throw my 2 cents in.  Do I like fruit machine and unplayable pinball roms?  No.  Do I like the fact that my merged 147 set is over 40 gb while my split 127 set is barely 16 gb?  No.  But what is the true reason that Mame exists?  It is to preserve games that we otherwise would likely no longer be able to play.  Think about it, technically, you are only only "legally" entitled to download a rom if you own the actual hardware (anyway, that's what the nag screens say).  So, the bottom line is, to that end, that the developers are doing a great job at preserving "all" of gaming for future generations.  The fact that we can actually get to play these games on our arcade cabs is just an awesome byproduct of this.  I never truly appreciated games like Donkey Kong and Galaga until I built my cab.  Thank youmame developers, for bringing them to my attention.   

fwiw, it might be many thousand sets but I'd say less than 2gb of the total romset size (as merged 7z) was fruit machines, then maybe that again for some video based things.  It's utterly insignificant compared to the amount of size added to the romset by things like the ROM based Naomi games, or the CHD stuff (there are individual CHDs bigger than that without even talking about the crazy LD ones)

It's another reason people like to use, but really, a blank dvd costs pennies and holds more than that, you can even buy blu-ray discs inexpensively these days holding 25gig each.

I've also seen this one thrown forward as a reason why MAME and MESS should never merge, but for all the systems MESS emulates it adds maybe a few hundred sets and 300 meg of data to the base romset, it's only 'huge' if you decide to collect the individual software lists (which are understandably huge but not even part of a default ClrMAME scan etc.)  if it happened most people wouldn't notice the bump in the base romset size, but I've seen people moan about it like it would be the end of the world and they'd be forced to have tons and tons of things they didn't want wasting all their precious space.....

People get worked up by the most insignificant of things which should be the least of their concerns; you're starting to see modern PC games in the 20 gig range and that will probably become the norm once the next generation kicks in.

As for the OP's problems, all I can suggest is try the latest MAME version in a fresh folder with clean config, ensure all your hardware drivers are up to date, ensure you have directX properly installed, make sure nothing bad is running in the background and if it still doesn't work there probably isn't anything anybody can actually do to help.

[rCadeGaming]

Haze, I think I had a bit of a misconception of these different types of buffering.  I think I've got it now.

Mind if I break this down to a really basic conceptual level to make sure I understand?

Let's say there's a really tightly written arcade game with no buffering of any kind.  At some time in between frames, the player presses the fire button.  The very next frame is rendered to the screen (must be a CRT) with the character beginning a firing animation.  Most real arcade games don't respond this quickly, but for the sake of argument we'll define this as zero frames of input lag.  Any user input is apparent in the very next frame rendered on the screen; meaning no more than about 16.6ms after pressing the button, if the game's running at 60Hz.

Now let's say this exact game is emulated in MAME.  At some time in between frames, the player presses the fire button.  Due to the nature of emulation, this cannot be apparent as the very next frame is rendered on the screen.  When the next frame is rendered on the screen, the character is not yet beginning the firing animation; the button press has just been detected in software.  Then the frame with the character beginning the firing animation is rendered in software/VideoRAM/whatever in preparation for the next refresh, and it is rendered on the screen as the following frame.  We'll define this as 1 frame of input lag.  Any input is apparent in gameplay not upon the very next frame rendered on the screen, but one frame after that.

So, due to the nature of proper emulation, any game in MAME must always run 1 frame behind where the original game would be, or at game lag +1.

So, let's say that a normal arcade game runs at 2 frames of input lag.  MAME should run at game lag +1, meaning 3 frames of input lag.

Do I have it so far?

As I said before, 1 frame of necessary lag is no problem, but are there cases where the game is running more than one frame behind the original game, and it could be improved?

For example if RSG runs at 4 frames of input lag, does that mean the original game ran at 3, or is more than 1 frame of lag coming from MAME due to the problems in emulating that hardware?

Are there cases with games running more than 1 frame behind on other hardware that would be easier to fix?

[Haze]

Haze, I think I had a bit of a misconception of these different types of buffering.  I think I've got it now.

Mind if I break this down to a really basic conceptual level to make sure I understand?

Let's say there's a really tightly written arcade game with no buffering of any kind.  At some time in between frames, the player presses the fire button.  The very next frame is rendered to the screen (must be a CRT) with the character beginning a firing animation.  Most real arcade games don't respond this quickly, but for the sake of argument we'll define this as zero frames of input lag.  Any user input is apparent in the very next frame rendered on the screen; meaning no more than about 16.6ms after pressing the button, if the game's running at 60Hz.

Now let's say this exact game is emulated in MAME.  At some time in between frames, the player presses the fire button.  Due to the nature of emulation, this cannot be apparent as the very next frame is rendered on the screen.  When the next frame is rendered on the screen, the character is not yet beginning the firing animation; the button press has just been detected in software.  Then the frame with the character beginning the firing animation is rendered in software/VideoRAM/whatever in preparation for the next refresh, and it is rendered on the screen as the following frame.  We'll define this as 1 frame of input lag.  Any input is apparent in gameplay not upon the very next frame rendered on the screen, but one frame after that.

So, due to the nature of proper emulation, any game in MAME must always run 1 frame behind where the original game would be, or at game lag +1.

So, let's say that a normal arcade game runs at 2 frames of input lag.  MAME should run at game lag +1, meaning 3 frames of input lag.

Do I have it so far?

As I said before, 1 frame of necessary lag is no problem, but are there cases where the game is running more than one frame behind the original game, and it could be improved?

For example if RSG runs at 4 frames of input lag, does that mean the original game ran at 3, or is more than 1 frame of lag coming from MAME due to the problems in emulating that hardware?

Are there cases with games running more than 1 frame behind on other hardware that would be easier to fix?

With real hardware you could (in theory, with an unbuffered sprite system) read the inputs on scanline 20 of the display (which might be the middle of a status bar or something) process them, and have your character be displayed in the moved / updated position as long as it was further down the screen than line line 20 in the very same frame you pressed the button on because as soon as the display beam hits the point where it gets to draw your sprite it will draw it, on the very same frame, with whatever the current position spriteram says it is in.  Of course that tends to be bad practice, and most things will update the positions of everything outside of the display period, but you get the point.  In emulation you can't really do that because you're never presenting the display in realtime like that, sure the *effect* will be the same, but because it's being rendered to a buffer you won't see it until the frame is fully rendered, has been sent to the PC video hardware and is shown next update.

It should, in theory, be +1 frame compared to real hardware and nothing more, but of course with any modern system you have a massive dependency chain of drivers, polling frequencies etc. and if the way a certain game is coded and polls the inputs is out of step with when MAME polls the inputs, when your hardware drivers polls the inputs, and even with modern pads, how long the pad takes to process your inputs and send them, of course it can get worse; you have more processing power in some modern keyboards and gamepads than you had on your entire desk 15 years ago!

With many old original arcade systems you had a pretty direct route from sticks / buttons to the game code, if the game code wanted, at any point the status of a button it pretty much would just read a port which corresponded more or less directly to a line on the edge connector of the PCB where the inputs were connected.  (Of course for later systems as I mentioned they had their own entire chain of actual CPUS / MCUs to read, process, sanitize and pass inputs to the main cpus, Namco started doing this rather early but these days it's pretty standard)

I guess what I'm saying is that many original systems did have lag too, and there are MANY factors to consider which could introduce more lag, most of them completely outside the scope of MAME to eliminate, I mean MAME can't do a thing if your actual monitor is adding it's own frame of lag for some kind of display filtering for example, and many modern screens do exactly that (some will have a 'gaming mode' to turn such off, but not all)

[paigeoliver]

Ok, cool. I will dump the game then. I have two boardsets that may possibly be different. Who do I send the files to?

Speaking of gambling games. Is Omega's Double Up dumped?

This one here.

http://www.arcade-museum.com/game_detail.php?game_id=7628

I know it isn't the same as HI-LO Double Up Joker Poker or Cal Omega - Game 15.9 (Wild Double-Up).

If it isn't dumped then is there any interest in dumping it? I have one.

Good question, the honest answer is I don't know, based on the screenshot on the site I can't say I have an exact match for it in my head, but there are quite a few Cal Omega games supported.

If you have the means to dump it then by all means do, there is definitely interest in getting them dumped and given the vast number of games and minor variations on games it's always worth a punt.

[Haze]

Ok, cool. I will dump the game then. I have two boardsets that may possibly be different. Who do I send the files to?

Speaking of gambling games. Is Omega's Double Up dumped?

This one here.

http://www.arcade-museum.com/game_detail.php?game_id=7628

I know it isn't the same as HI-LO Double Up Joker Poker or Cal Omega - Game 15.9 (Wild Double-Up).

If it isn't dumped then is there any interest in dumping it? I have one.

Good question, the honest answer is I don't know, based on the screenshot on the site I can't say I have an exact match for it in my head, but there are quite a few Cal Omega games supported.

If you have the means to dump it then by all means do, there is definitely interest in getting them dumped and given the vast number of games and minor variations on games it's always worth a punt.

There are multiple avenues

a) put them on some free webhosting (something like sendspace) and use the form on http://mamedev.org/contact.html to send details
b) contact the Dumping Union and work with those guys as the middlemen (would be easier if MameWorld wasn't down at the moment, but they're moving hosts)
c) like a) but PM me on here instead

generally advised to do a quick photo of the boards as well for future reference :-)

and yeah, one of the thing that has helped the project survive is people just dumping whatever boards they come across

[Calamity]

Hi guys, sorry for the interruption. We have been discussing about the input lag issue lately in this thread:

http://forum.arcadecontrols.com/index.php/topic,128993.msg1318353.html

We are suggesting a method to reduce the 1-frame lag associated to frame-based emulation to the theoretical possible minimum, without breaking the emulation with dirty hacks.

It's a shame we don't have reliable information about the current scanline in modern operating systems as we used to have in the old days, that would allow for truly perfect video emulation in the terms that have been discussed here by Haze.

[rCadeGaming]

With real hardware you could (in theory, with an unbuffered sprite system) read the inputs on scanline 20 of the display (which might be the middle of a status bar or something) process them, and have your character be displayed in the moved / updated position as long as it was further down the screen than line line 20 in the very same frame you pressed the button on because as soon as the display beam hits the point where it gets to draw your sprite it will draw it, on the very same frame, with whatever the current position spriteram says it is in.  Of course that tends to be bad practice, and most things will update the positions of everything outside of the display period, but you get the point.

Ok, I didn't consider that it actually make use of new information that has arrived within the current frame being drawn.  I can certainly see how that could easily become a mess though.

It should, in theory, be +1 frame compared to real hardware and nothing more, but of course with any modern system you have a massive dependency chain of drivers, polling frequencies etc. and if the way a certain game is coded and polls the inputs is out of step with when MAME polls the inputs, when your hardware drivers polls the inputs, and even with modern pads, how long the pad takes to process your inputs and send them, of course it can get worse; you have more processing power in some modern keyboards and gamepads than you had on your entire desk 15 years ago!

Can these problems get better with higher processor speeds?  Would a faster processor reduce to the time for data to travel through the driver chain?  Could it increase polling frequencies, or is that regulated by the controller encoder's hardware or driver?

Also, these effects shouldn't be relevant when using the frame-advance method for measurement, as there's plenty of time for everything to reach MAME "in between frames" right?

I guess what I'm saying is that many original systems did have lag too, and there are MANY factors to consider which could introduce more lag, most of them completely outside the scope of MAME to eliminate, I mean MAME can't do a thing if your actual monitor is adding it's own frame of lag for some kind of display filtering for example, and many modern screens do exactly that (some will have a 'gaming mode' to turn such off, but not all)

I use a CRT running native res from MAME with DirectDraw and syncrefresh, no wait vsync or triple buffering, which should minimize lag from the display.  I use an MC Cthulhu, which is supposed to be "lag free," as a controller encoder.

Hi guys, sorry for the interruption. We have been discussing about the input lag issue lately in this thread:
We are suggesting a method to reduce the 1-frame lag associated to frame-based emulation to the theoretical possible minimum, without breaking the emulation with dirty hacks.

To be honest, that thread is massive, I can't read it all right now (I will when I can though).  From what I saw it looked like you were talking about removing lag from triple buffering.  Are you thinking of a method that would help even if you're already strictly using syncrefresh?

What's the core idea?

[Haze]

Can these problems get better with higher processor speeds?  Would a faster processor reduce to the time for data to travel through the driver chain?  Could it increase polling frequencies, or is that regulated by the controller encoder's hardware or driver?

Also, these effects shouldn't be relevant when using the frame-advance method for measurement, as there's plenty of time for everything to reach MAME "in between frames" right?

It would require more extensive studying of what MAME does in a pause situation when it comes to reading inputs etc.  I don't have time for that, sorry.

I imagine what you'd end up measuring is how long it takes for the game to respond to inputs tho.  If the inputs were read in the previous frame you'll see the on-screen effect the next time you frame advance, if the game has built in buffering in the code, or the video hardware, the one after that etc.

Unfortunately, for the rest, as I say there is a chain of dependency right down to the actual input device you're using.

I can't give you any better answers than the ones I'm giving, it's starting to feel like you're asking me the same questions again and again in the hope that I'm going to say something else, or pick up the code, plough through it, and come up with some magical impossible solution, that isn't going to happen, it isn't my area of the code.

[rCadeGaming]

Sorry, just trying to gain a deeper understanding of it.  It has been very helpful.

Is there someone who works specifically in this area of the code that would be open to questions?

[Haze]

Sorry, just trying to gain a deeper understanding of it.  It has been very helpful.

Is there someone who works specifically in this area of the code that would be open to questions?

unlikely, I don't think any of the core devs bother with public forums, nor want what they might consider 'obsessive' email wanting unfixable things 'fixed'  Most have been hounded off at one point or another and cut contact for those very reasons; this very topic / subject matter has been the cause of such things in the past.

[rCadeGaming]

Yeah, that's understandable.  That's why I really appreciate the conversation here.   

I'll stick to my plan of trying console ports if lag in MAME is excessive (I think I'll still be playing a LOT of games in MAME though).  This conversation has made me want to buy more actual PCB's too.  Whether using a port or a PCB I'll use a camera test to compare if MAME is really adding much lag, or if most of it is in the game itself.

[harveybirdman]

Finally, I don't get why people are taking offense to me looking at it, I've consistently delivered things people WANT to see in MAME over the years, even recently, the PGM games (Demon Front, DoDonPachi II) that many people consider make 146 worth upgrading to, that was my work...

FWIW Thank you!  Just grabbed Demon Front and it looks freaking awesome.

[Haze]

Finally, I don't get why people are taking offense to me looking at it, I've consistently delivered things people WANT to see in MAME over the years, even recently, the PGM games (Demon Front, DoDonPachi II) that many people consider make 146 worth upgrading to, that was my work...

FWIW Thank you!  Just grabbed Demon Front and it looks freaking awesome.

Yeah, it's a decent game, IGS clearly took Metal Slug as a template for what they wanted to create (some of it is so similar I'm surprised they got away with it) but the theme is more refreshing and it has it's own blend of gameplay elements which prevent it from being a direct rip-off.  The official Metal Slug offering from the same year was Metal Slug 4 so I think IGS can easily say they had the better offering that year ;-)

It's a shame the remaining newer IGS titles have such insanely nasty protection at hardware level they might never be *properly* emulated, they were pretty nutty about their protection on everything from the casino games to their arcade titles, but I guess coming from Taiwan they know first hand how bad bootlegging is in the asian regions.

Obviously for the same reasons the games, including Demon Front are *hugely* popular in China.

[harveybirdman]

I assume The Gladiator - Road of the Sword falls into the category of insanely nasty protection?

Not that it matters, I need a faster PC anyway and I can always still play Knights of Valor.

[Calamity]

To be honest, that thread is massive, I can't read it all right now (I will when I can though).  From what I saw it looked like you were talking about removing lag from triple buffering.  Are you thinking of a method that would help even if you're already strictly using syncrefresh?

What's the core idea?

Although triple buffering is discussed too, the main idea is related to managing syncrefresh in a different way.

Skip the first posts, better go to the last one and read backwards, that usually helps.

By the way, I'm interested on your high speed camera method. May I ask you which model are you using? Price?

[rCadeGaming]

Ok, so when you force MAME to wait for part of a frame before beginning emulation of the next frame, is that to allow new buttons presses that happened during that waiting period be considered during the emulation of that next frame?  This is what would lower the minimum lag below one frame right?

This is extremely interesting.  So then, the faster the PC, the longer it could wait during a frame to start emulating, and the less lag there would be, right?

Would you mind looking at some questions about switching to GroovyMAME?  I posted them here, so it wouldn't derail this into yet another direction:

http://forum.arcadecontrols.com/index.php/topic,128879.msg1318540.html#msg1318540

Similarly, I posted info about testing lag with high speed video here:

http://forum.arcadecontrols.com/index.php/topic,129004.0.html