Main > Main Forum

Donkey Kong (us set 1) slow on mame 147

Pages: << < (10/12) > >>

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?


--- Quote from: Haze on November 30, 2012, 10:53:19 pm ---
--- Quote from: paigeoliver on November 30, 2012, 09:14:13 pm ---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.

--- End quote ---

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.

--- End quote ---


Haze:


--- Quote from: paigeoliver on December 01, 2012, 03:03:36 am ---Ok, cool. I will dump the game then. I have two boardsets that may possibly be different. Who do I send the files to?


--- Quote from: Haze on November 30, 2012, 10:53:19 pm ---
--- Quote from: paigeoliver on November 30, 2012, 09:14:13 pm ---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.

--- End quote ---

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.

--- End quote ---

--- End quote ---


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:


--- Quote from: Haze on December 01, 2012, 01:50:48 am ---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.
--- End quote ---

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.


--- Quote from: Haze on December 01, 2012, 01:50:48 am ---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!
--- End quote ---

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?


--- Quote from: Haze on December 01, 2012, 01:50:48 am ---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)

--- End quote ---

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.


--- Quote from: Calamity on December 01, 2012, 10:41:20 am ---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.
--- End quote ---

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:


--- Quote from: rCadeGaming on December 01, 2012, 08:27:38 pm ---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?

--- End quote ---

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.

Pages: << < (10/12) > >>

Go to full version