| Main > Main Forum |
| Hardware 3D Acceleration In Mame |
| << < (16/20) > >> |
| purpledrillmonkey:
--- Quote from: Jdurg on February 26, 2008, 11:10:14 am ---Yes, but when the same questions/suggestions are asked on a seemingly daily basis and very valid reasons are given by the developers as to why they aren't going to implement it, it starts to get a bit annoying. People have asked questions, been told no and a very detailed explanation and reason why the answer is no, but they still won't stop the complaining and whining about it. --- End quote --- fair enough |
| u_rebelscum:
FWIW, getting mame to use 3d hardware acceleration would be harder than most other emu's. Why? Short Answer: Mame is set up to be able to be cross platform, and directX is windows only, and opengl is not on all OSs (and not as well supported on consumer video cards as directX on OSs it is on). Long Answer: Mame's architecture has many parts. Core, game driver, CPU emulation, video hardware emu, sound emu, discrete circuit emu, and OS dependent code are separate from each other. This is great for what mame does: emulate lots of different systems that share some (to none) hardware. Want to add a game that is on the same system as other games? Map the roms to the memory with cut and pastes, add game to mame's internal list, and go. New game on new system that all chips are already in mame? "Connect" the parts to build the system and map the memory, and bang. Need a new CPU emulated? or sound chip? Write the code into the CPU part of mame; the structure is ready for it. (Hmmm, maybe this isn't that easy ;) but not too far if you know emulation, the chip and mame's structure.) But notice how the OS code (ie: directX) is totally separate from the video emulation code? (With the core directing the info between the two parts.) This is perfect for mame's current cross platform flexibility, the support of many original hardwares, and documenting the original hardware. Add since Mame has windows, linux, mac, and maybe PS3 current builds, whatever changes are made at least these OSs need to be considered. Remember the 0.106 to 0.107 video change? Non-windows OSs projects either stopped (ie: AdvanceMame) or took a little while to catch up; maybe one or two versions. That's about the limit change would be accepted. And remember, OS specific code like directX or openGL must be kept separate from the video emu code even though it's replacing it so the different OSs can all work, and the original code needs to still be there to fall back to. It would be much easier (short term) for someone to take the mame structure, merge the OSD code into the core and emu code, then add 3d hardware use code. I think most people (OP & others) are thinking the codes are merged already, and that's is the level of ease when they say it's easy. (Note: this is basically the same problem forcefeedback has in being added to mame.) |
| brandon:
hmm.. maybe someone sould code an unofficial windows only build that optimize things for DirectX and DirectX Input since I'm sure that's what the majority of folks are running Mame on. Then wouldnt it be easier to add things like force feedback? |
| SavannahLion:
USB 05h + Randy or Andy = Kick ass products. I say that's a nice starting point for feedback. Anyone know if MAMEDev looked into it? |
| Cakemeister:
--- Quote from: u_rebelscum on February 26, 2008, 05:50:17 pm ---FWIW, getting mame to use 3d hardware acceleration would be harder than most other emu's. Why? Short Answer: Mame is set up to be able to be cross platform, and directX is windows only, and opengl is not on all OSs (and not as well supported on consumer video cards as directX on OSs it is on). Long Answer: Mame's architecture has many parts. Core, game driver, CPU emulation, video hardware emu, sound emu, discrete circuit emu, and OS dependent code are separate from each other. This is great for what mame does: emulate lots of different systems that share some (to none) hardware. Want to add a game that is on the same system as other games? Map the roms to the memory with cut and pastes, add game to mame's internal list, and go. New game on new system that all chips are already in mame? "Connect" the parts to build the system and map the memory, and bang. Need a new CPU emulated? or sound chip? Write the code into the CPU part of mame; the structure is ready for it. (Hmmm, maybe this isn't that easy ;) but not too far if you know emulation, the chip and mame's structure.) But notice how the OS code (ie: directX) is totally separate from the video emulation code? (With the core directing the info between the two parts.) This is perfect for mame's current cross platform flexibility, the support of many original hardwares, and documenting the original hardware. Add since Mame has windows, linux, mac, and maybe PS3 current builds, whatever changes are made at least these OSs need to be considered. Remember the 0.106 to 0.107 video change? Non-windows OSs projects either stopped (ie: AdvanceMame) or took a little while to catch up; maybe one or two versions. That's about the limit change would be accepted. And remember, OS specific code like directX or openGL must be kept separate from the video emu code even though it's replacing it so the different OSs can all work, and the original code needs to still be there to fall back to. It would be much easier (short term) for someone to take the mame structure, merge the OSD code into the core and emu code, then add 3d hardware use code. I think most people (OP & others) are thinking the codes are merged already, and that's is the level of ease when they say it's easy. (Note: this is basically the same problem forcefeedback has in being added to mame.) --- End quote --- Well said. I think you said it all. I think some posters in this thread are confusing accelerated display with accelerated video hardware emulation. Hardware accelerated display is a reality. The Windows backend can use Direct3D, and the SDLMAME derivitive can use OpenGL. MAME also can run the display code in a separate thread than the other parts of the emulator. Contrast that with accelerated video hardware emulation. Like you said, the OS-dependent stuff has been factored out of MAME into its own code. The video hardware emulation is done strictly in software that is platform-neutral. The answer to Fozzy's question: Why doesn't MAME use hardware accelerated graphics? can be: 1) It does! (hardware accelerated display) 2) It can't, it completely goes against the architecture of the frontend. (hardware accelerated graphics emulation) Other emulators are not bound by the restriction of platform independence. So other emulators can go ahead and run the graphics emulation on the video card. |
| Navigation |
| Message Index |
| Next page |
| Previous page |