Main > Main Forum

Donkey Kong (us set 1) slow on mame 147

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

Haze:


--- Quote from: rCadeGaming on November 30, 2012, 08:14:25 pm ---"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?"

--- End quote ---

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:


--- 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.

Haze:


--- Quote from: gman314 on November 30, 2012, 09:02:16 pm ---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.   :cheers:

--- End quote ---

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:


--- Quote from: rCadeGaming on December 01, 2012, 12:02:41 am ---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?

--- End quote ---

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)


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

Go to full version