Main > Main Forum

Does Mame Take Use of Graphics Card

<< < (4/5) > >>

u_rebelscum:
Okay, an inteligent point deserves an inteligent answer.  This is a valid point, from a user's point of view:


--- Quote from: uprightbass360 on March 18, 2009, 04:20:13 pm ---My answer to all that protest 3rd party emulators is if it can be done more streamlined, why not do it. Why not just have 3d rendering report to a renderer like in many emulators (Nulldc for one), so that 3d information can then be passed to the gpu. If you are to separate the two from themselves then you can then support other people to find ways of better emulation of the graphics themselves. If setting for a specific game were not properly supported by the renderer then simply setting it back to software is always an option. It just would make so much sense to put more stress on the gfx card when processing the game, when you can get enormous cards for next to nothing now a days.

--- End quote ---

If this were easy while still allowing mame to render authentically (some other way), I'm pretty sure someone would have figured it out.  (It's actually closer to being possible now then it was pre-0.106, if I understand mame design correctly.)

However, from a developer's point of view, there are three major reasons besides the "goals" and "helps only a few games a small amount" points raised in earier posts, on why not in official mame.  The combination of the five all contribute to why it's the way it is.

Bugs, Fake bugs, and non-bugs:  MameDev removed the hiscore.dat hack because it introduced bugs that people reported as emulation bugs, but were introduced only because of the hiscore.dat code.  It was a headache to work with.  Using 3d cards for emulation (or resemblence there of) would be like adding back hiscore.dat.  (see example by VicBond007.)  Having the 3d card code done by 3rd parties would mutiply  bug report mix ups by the number of plugins (aka making it far worse than hiscore.dat).  At the same time, the changes themselves will introduce there own bugs (anyone remember the thirteen u updates in the 0.106-0.107 transition for the last video change?).

Increased amount of code to support, aka code bloat: Right now, official mame can render (post-emulation) the images three ways: d3d, ddraw, and gdi.  (There are other ways to render in other builds, sdlmame, etc).  However, this is post emulation.  (currently) If you wanted to do the emulation on the 3d card, each video chip emulated would need the current emulation way + a new added 3d card way (assuming only one 3d card way).  That means doubling the code (at least) of the hardest to emulate video chips (we don't need to speed up the old, easy to emulate chips on the 3d cards, even though those would be the easiest to do, right?).  Much of this could actually could be "pushed off" to 3rd party by creating a "middle langauge", something like what was done for easing up drc for the different OSes and 32/64 bit multipliers that drc speedups were facing.  However, that wasn't easy, and neither would doing the video; it would take some MAJOR recoding of all the video shuff.  Again.  Plus see bugs problems with 3rd party.

Portability (or lack there of): Unless coded correctly, adding 3d card use for emulation with reduce mame's portability.  Currently, mame runs on windows, MacOS, & linux (including PS3).  If done incorrectly, this could tie mame to one OS and one directX version (assuming it uses directX).  If directX or windows changes something needed by the 3d card code, SOOL until recoded.  But doing it correctly involves a lot more work than doing it quickly, and AFAIK, only a few (if not only one) people in mameDev have the skills to even think about doing it right.  And two of the three I'm thinking about don't use windows/vista, nor run mame in windows/vista; so the "most people use windows so why need portability? (so why not do it the easy way?)" point will not convice the majority of the people that might be able to do it, and the remaining wouldn't want to alienate some of the major coders in the mameDev by forcing windows only.


I'm not sure what's the biggest reason: bugs, code bloat, portability, GPU will only help a very few games a small amount, or keeping with the goals, that's the moving (or not moving, depending on your POV ;)) force on this issue.  Heck, probably most people differ the exact whys even when agreeing "no" view.  However, I wouldn't be surprised if something like this might happen in 5-10 years if CPU power increases slow down as much as people think.  (using CUDA gpu power is slightly more possible, IMO though.)  OTOH, if the CPU hardware continues to keep up with emulation, so only ~5% of the games run too slow in mame, I would be surprised if it does happen.

[tech=off]

Blanka:

--- Quote from: u_rebelscum on March 17, 2009, 03:21:01 pm ---B. Have you looked at video card comparison reviews?  Ones that compared image quality as well as benchmark speeds?  Different cards render different images from the same OpenGL or DirectX commands.  This goes against mame's "reproduce that game as faithfully as possible" goal (quote from the front page of the official mamedev site).

--- End quote ---
The good thing is that the new original game systems use OpenGL and not DirectX. OpenGL is generally the same on OSX, XP and Linux.
If the original system had a Geforce 6600, Mame could advice a Geforce 6600 for best emulation, but I bet that 99.9% of Mame users would not give a sht if a Geforce 7600 or better would render those 6 out of 500000 pixels 1 shade from 255 levels darker. Making a Geforce 6600 emulator run by the CPU might be accurate, but would need a 8-core nehalem system overclocked to 20Ghz to run at 5fps. This is beyond nuts-ness.

I know 3d rendering of specific chips should be handled with care, but those games using OpenGL calls will look great to most of the users and run supersmooth on the average today machine. It would be sticking the head in the ground to port those titles to CPU rendering.

taz-nz:

--- Quote from: Blanka on March 19, 2009, 07:01:16 am ---but I bet that 99.9% of Mame users would not give a sht if a Geforce 7600 or better would render those 6 out of 500000 pixels 1 shade from 255 levels darker.

--- End quote ---

Problem is with the current graphics APIs there is no control over what the final output will looks like, you could feed in shades of gray and get a bad LSD trip out the other end currently,  this will change will Directx 11 and OpenCL, but until then it will not just be a problem of a half dozen pixels one shade off, it's more likely to be like the missing stones issue in Far Cry 2.





The way 3D game graphics are currently drawn results change from driver version to driver version, let alone from graphic chip to graphic chip, now think about what it be like to upgrade you graphics card or just update your graphics drivers and then find all the characters in your favorite fighter game now have no faces, or that driver game you love so much no longer has any road textures or maybe the sky is now pink in that shooter you played just last month.


Turnarcades:
This has all gone a bit  :dizzy:

Blanka:

--- Quote from: taz-nz on March 19, 2009, 09:47:20 am ---then find all the characters in your favorite fighter game now have no faces, or that driver game you love so much no longer has any road textures or maybe the sky is now pink in that shooter you played just last month.

--- End quote ---
So what?
Pac Man started out having far from acurate emulation in Mame 1, and today it can drive a core2duo nuts if you want more accuracy and better looks. If we wan't to archive classic games, we should not give a sht about OpenGL glitches now untill there are OpenCL emulations of all graphic card/driver combinations in 2026. If we say 'don't port 3D calls yet" these games may be under soil by the time they become playable pixel-perfect. If they play mediocre today, people will redistribute them and keep them around until it is up to total Mame-dev-team standards.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version