Home Page Forums MAME MAME Renderer WIP

Beyond that, Windler's bloviating is particularly fucking stupid and belies an abject sort of ignorance that can only come from not keeping up with his schizo meds. All of the potential "issues" cited aren't actually issues, because the person programming the renderer is in complete control of everything.

Got the info screens rendering again; it helps to update the constant buffer at the start of the frame, rather than when first encountering a screen texture.



Still left to do:
- Get the shader pipeline working again
- Get prescaling working again
- Figure out why some D3D11 resources are being leaked on exit

Currently working on getting the actual shader system (d3dhlsl.cpp) ported over to D3D11.

I finally have something showing up on-screen, but it doesn't seem quite right.

Shader system is ported over and running, but the actual post-processing is still pretty broken. That said, at least UI geometry and textures are routing through the shader system without issue:

Things are starting to look better. As far as I can ascertain, only the phosphor effect and bloom are broken right now. I thought scanlines were broken, but it was because I was doing all of my testing with the SGI Indy driver, which by default, outputs at 1288x1024 - a resolution that scanlines will naturally cause the equivalent of moiré if applied to:

Great progress. We are doing something similar at work, moving an ancient GDI rendering to the GPU.

Will moving the rendering to the GPU help with the current issues with interlaced video, such as the laserdisc games?

Obviously there is a cost to software render to textures for the GPU. I would expect the post processing of scan lines to be faster on the GPU, but does the rendering to textures negate the performance gain? Would you expect any performance improvements, if not using scan lines or other effects? Maybe the GPU could scale to 4K instead of changing resolutions?

Too many questions. Thanks for your hard work.

A-noid.

This work is just to port -video d3d9 to use D3D11, so that you don't have to install the Microsoft DirectX runtime on a new Windows 7/8/10/11 machine in order to run MAME.

There will be a more extensive new renderer down the line where doing things like a deinterlace shader could be a thing.

You're correct, that's all this is, but these two things are a bit intertwined.

I'm using this as a learning opportunity to write a brand new video backend from scratch, or at least while being able to use the existing D3D9 renderer as a guide - which hasn't been as helpful as one might think, given how much rendering APIs have changed in the intervening decade and a half.

The next step from here is to write a D3D12 renderer, and once that's working, start looking at writing a Vulkan renderer, and the equivalent macOS backend via MoltenVK. I'm going to need you to be available for that when I get around to it, RB.

More specifically, once all backends (Windows, Linux, macOS) are operating harmoniously, that's when the renderer rewrite becomes a viable thing.

Something I want to experiment with in a branch, prior to all of this, is adding the ability for drivers to request OSD resources more frequently than they currently do. Work units are currently something that the core benefits from which relies on handing out OS-side handles via the OSD layer, but beyond that, examples are pretty thin on the ground.

There are things as simple as bitmap allocation that currently exist 100% in software, but which would avoid a considerable amount of overhead if they could simply rely on being given a handle by the OSD layer. In the annoying and rare event that it's a purely software-rendering setup, or an anemic piece of hardware, then those handles can be managed in-situ by the relevant OSD module. If not, the OSD can hand off a handle to the relevant buffer in order to avoid a costly copy operation.

Quite a bit was broken compared to my original assumptions back on the 31st.

That said, all effects in raster mode are now working. This screenshot intentionally looks terrible, as it has all of the effects turned on and turned up in order to be distinctly visible:



To-do:
- Test vector screens and ensure those work
- Implement shader-based palette conversions and ditch the "copyline" functions (mainly porting over from the BGFX frontend)
- Massive amount of code cleanup
- Eliminate as many redundant state-set calls as possible