Home Page Forums MAME MAME Renderer WIP

I was making a program so that I could re-create the UI system I wrote at my day job that I worked for the past 6 years (currently between jobs, starting a new one in August) in order to more easily make animations for the videos that I create, and wasn't sure what to choose as a renderer.

I did some cursory searching on Google, and found a minimal D3D11 example that manages to create a 3D scene and render it in just 340 lines of code - including comments.

I had kept hearing how weird D3D10 and D3D11 were, and I'll admit that they are compared to D3D9, but that's just it: They're weird compared to D3D9 and OpenGL, which were dominant in the industry at the time.

What does this have to do with MAME? Well, how many of you are tired of installing the June 2010 DirectX 9 redistributable, or are tired of having to tell users on Windows 8 and up to do so?

In any case, my code currently crashes - I'm not bringing things up in the correct order, as I don't seem to be creating a swap chain early enough - but, have some initial output!


ETA: I know that BGFX is a thing now, but truth be told, I've been growing tired of dealing with it. It has random idiosyncrasies on some systems, it's not quite as good of an abstraction layer as it's held out to be, and it's tiresome having a nonexistent level of support. As I see it, the path forward leans primarily on a D3D11 renderer for Windows, a Vulkan renderer for Linux, and whatever it is that's allowed on macOS, then an OSD-side abstraction layer in front of all three.

Having modern standalone renderers for each OS opens the door to gradually shifting resources from a "core-owned, thrown over the fence to OSD" model which was growing increasingly archaic even when 0.106 rolled around, into a "core requests a handle for a hardware-backed buffer from OSD" model.

Much of MAME's rendering architecture still performs multiple copy operations between the time its core render system creates a texture, to the time the OSD is drawing it on-screen. Reworking this to directly fill screen-texture buffers, for example, eliminates these redundant copies.

Great idea! If -video hlsl could just become D3D11 that would solve the persistent annoyance of the redistributable until we get to the new renderer, assuming none of our other DirectX backends (dsound, dinput) require it.

That's what I'm thinking, yeah. And ideally, the "new renderer" would just be a MAME-owned abstraction layer on top of a D3D11 renderer for Windows, Vulkan for Linux (and mobiles, too, though the Yuzu and Ryujinx people have some things to say on that), and whatever it is that macOS uses.

From there, it makes it easier to more gradually transition the rendering system, rather than doing it in one enormous task.

Yeah. The more complicated/interesting part of the "new renderer" will be to unify video effects so that they're common on all backends that can handle it (and vulkan/d3d11/metal/gl4 are essentially the same level of capability). With a touch of glslang/spirv-cross so that they're actually only written once.

Metal on macOS was designed to facilitate D3D11 ports to an extent, but it's set up similarly to D3D12 and Vulkan.

And yeah, making the new renderer opt-in instead of global would be ideal. Start with the fallback where MAME renders in software and we're just blitting to the screen, add support for the common case of processing tilemaps and sprites on the GPU so we get half a million FPS in pacman on a 3080, and go forward from there.

I just did some light reading on the differences between D3D11 and D3D12 - yeah, seems like a pretty major change, so most of this work towards a D3D11 renderer is a bit worthless. I like the sound of D3D12, though, it being more low-level sounds more my speed.

Oh, I really expect the render-on-gpu to be fully optional. But we really need a better backend however we do the rendering, the per-osd video effects are beyond annoying, and bgfx not at all handling live shader compilation makes it a dead end.

After thinking about it, I'm not sure what GPU acceleration being optional gets you. If the intention is to preserve the existing F12 screenshot functionality that gets you the exact output of the driver with no post-processing, in order to be able to diff PNGs to find regressions, that can still be done. I can't think of a single platform at this point where taking a screenshot of a GPU-accelerated program is impossible, and it would be a win to be able to abandon the shitfest of code that is rendersw.hxx.

In other news, have a screenshot with things actually on-screen:


MAME currently crashes when quitting (not all resources are destroyed correctly), the initial info screen doesn't render for some reason, and as you can see, dynamic textures don't currently work. Still, it's progress. Last week was a non-MAME week for me since I had company over.

Beware! Keep GPU acceleration strictly optional. Not every office PC supports hardware 3D rendering or has Linux drivers those enable it on exotic (RasPi-like) hardware. My laptop e.g. has no modern 3D GPU at all.

And if MAME wants to be a "reference" implementation for rendering the most authentic graphics output, relying on the 3D SFX of the installed graphics card driver is a truly bad idea. E.g. you may get automatically interpolated sprite zoom pixels (blurred Atari Lynx games can look better, but are they authentic?) and all kind of image dishancer artefacts, those in future may go up to AI hallucinations those by default e.g. replace what looks like a pixelish tree with photos of an actual tree, similar like some soundcard drivers add reverb, loudness and equalizer to the sound. For a commercial game app player with emulation that is optimized for speed and "modern" image quality (upscaling etc.) the 3D graphics driver of the operating system may be an appropriate choice (with the same attitude like hacking the game code itself to run smoother or look more modern), but for MAME this needs to stay optional.

You're 17 years behind MAMEdev's thinking on all of those topics. Please try to keep up.

- Pis that we support have GPU drivers. In 2023 if your device doesn't have GPU drivers, it sucks.
- We're going to run renderer programs on the GPU. No "normal" drawing will take place so the drivers can't touch it.