Windows MAME & OpenGL

[u-man]

Hello Calamity,

Maybe you allready know, but since 0159, the MAME devs implemented OpenGL to the official source build.
You can get the source here: http://git.redump.net/mame/commit/?id=f33d0614c397ad25b16523f96910cc8fdc1a8a00

Or you can grab my MAME 64Bit build with allready enabled OpenGL: https://www.dropbox.com/s/b32dmtud2gutnyj/mame64_0159_r36143_opengl.zip?dl=0

Its just the MAME.exe, for faster testing. You still need to create a new mame.ini, to get the additional parameters.
To activate OpenGL, you need to change the following line of your mame.ini OSD VIDEO OPTIONS section :

video opengl

So for now, you can switch between different graphics renderers including OpenGL and here comes the interesting part:

a view days ago, i have compared different shaders, OpenGL vs. HLSL (direct3d) and found out interesing things. It seems that OpenGL has a way better handling of the graphiclayer than Direct3D and it doesnt matters, if you use shaders or not. I did all of the testing only on a LCD (still not at home right now, cant test on CRT).

i.e. you can try Wonderboy Deluxe and compare the two different graphic-engines. At default settings, Direct3D creates tearing and stutter. Now if you start the same game with default settings and OpenGL, all errors are gone. It seems that every game that runs at different speed from 60Hz, looks way better on OpenGL at default settings with audio synced (the audio is NOT pitched up and down, to stay sync).

I am really impressed how OpenGL turns out. Will this be the new standard? Is it interesting for GroovyMAME? I wish i could check this on my CRT .
I just wanted to inform you, about this.

Greetings from u-man

[Calamity]

Hi u-man,

i.e. you can try Wonderboy Deluxe and compare the two different graphic-engines. At default settings, Direct3D creates tearing and stutter. Now if you start the same game with default settings and OpenGL, all errors are gone. It seems that every game that runs at different speed from 60Hz, looks way better on OpenGL at default settings with audio synced

Thanks for the pointer. Yes, not long ago I compiled a Windows binary with OpenGL enabled and to my surprise it behaved much like the multithreaded implementation of triplebuffer in GroovyMAME as explained here. This means it performs v-synced asynchronous blitting out of the box. The good thing is this is done natively, without hacks, so it will be much more stable. The bad thing that I need to confirm is if this behaviour is default, so you no longer can perform the good old v-synced synchronous blitting without hacks (see the paradox?).

(the audio is NOT pitched up and down, to stay sync).

This is as impossible as the circle quadrature. Trust me on this.

For instance, when you run a 55 Hz game at a 60 Hz video mode, if the audio stays in sync (not pitched) it is because the video doesn't. It is the same as enabling -multithreading and -triplebuffer in GroovyMAME.

I am really impressed how OpenGL turns out. Will this be the new standard? Is it interesting for GroovyMAME?

Well it's definitely interesting. Whether it will be the new standard, I don't know. As for GroovyMAME, the patch is not implemented yet for OpenGL. Most of the exciment around OpenGL is due its filters, and also probably because many MAME devs these days are focused on non-Windows platforms such as Linux and even oddities like Mac.

[u-man]

Well, to be honest, I am a small learning Padawan comparing to you and others here , but my interest is way higher than that from a average MAME user .

If i correctly understand you, OpenGL at current state, have the downside that it CANNOT play the games at original-speed, which is a huge bonus from GroovyMAME. But looking from a LCD users perspective, I can say it looks way better than D3D with hacks. With hacks you can eliminate tearing and other stuff, but the end-result of OpenGL is a more fluent gameplay, that still looks better to me, than D3D. i.e. just compare attraction mode from Asteroids with OpenGL and D3D and watch how the asteroids move .

The most excitement for OpenGL, was the possibilty to use the awesome "Timothy Lotte´s" shader conversion from Sultan42 at Mameworld and all LCD users, should keep an eye on the next release of MameUIFX .... it will be awesome.

Cheers, u-man

[bulbousbeard]

I have no idea what you're talking about. MAME with OpenGL still runs games at their native speed.

With a G-Sync monitor, it runs Mortal Kombat at 54hz fine, for example.

What are you on about?

[Calamity]

If i correctly understand you, OpenGL at current state, have the downside that it CANNOT play the games at original-speed, which is a huge bonus from GroovyMAME.

No, I meant the opposite. OpenGL can't synchronize emulation speed with the video card's refresh rate as defined by us. At least as it is implemented right now.

But looking from a LCD users perspective, I can say it looks way better than D3D with hacks. With hacks you can eliminate tearing and other stuff, but the end-result of OpenGL is a more fluent gameplay, that still looks better to me, than D3D.

No, it looks way better than D3D *without* hacks Filters apart, and from a fluency point of view:

[-video opengl]  = [-video d3d -multithreading -triplebuffer] (GroovyMAME implementation)

It is nice that OpenGL does this natively. What I mean is that it looks like you *can't* get the equivalent to [-video d3d -syncrefresh] which is the base of GroovyMAME. EDIT: Well it definitely works, at least testing with a Nvidia GT 630M.

Besides, current implementation does not support switching resolutions, i.e. using e.g. -resolution 320x240 does nothing.

[bulbousbeard]

-resolution only seems to work with OpenGL when you run in Windowed mode.

[Calamity]

-resolution only seems to work with OpenGL when you run in Windowed mode.

I've included resolution switching in OpenGL mode for the next GroovyMAME patch, from what I've seen OpenGL doesn't manage video mode switching natively.

I still need to test things, maybe what I stated yesterday about -video opengl replicating the beviour of -video d3d & multithreading is not true. Besides it's possible that ATI implementation differs from Nvidia's (the one I tested). When I tested all this in Linux (at the time of the SDL2 adoption) I can confirm that vertical sychronization was completely unconsistent between different models of ATI cards and it didn't match the documented OpenGL behaviour. Maybe under Windows things are more consistent.

[u-man]

Hello again,

first of all, I have to say that I ONLY COULD compare official MAME vs. OpenGL MAME and only on a 60hz LCD. So please consider this.
I believe in all of your statements blind and believe what you are saying. I am pretty sure we meant the same here, but I couldnt better describe it:

If i correctly understand you, OpenGL at current state, have the downside that it CANNOT play the games at original-speed, which is a huge bonus from GroovyMAME.

No, I meant the opposite. OpenGL can't synchronize emulation speed with the video card's refresh rate as defined by us. At least as it is implemented right now.

It is nice that OpenGL does this natively. What I mean is that it looks like you *can't* get the equivalent to [-video d3d -syncrefresh] which is the base of GroovyMAME. EDIT: Well it definitely works, at least testing with a Nvidia GT 630M.

-resolution only seems to work with OpenGL when you run in Windowed mode.

I've included resolution switching in OpenGL mode for the next GroovyMAME patch, from what I've seen OpenGL doesn't manage video mode switching natively.

I still need to test things, maybe what I stated yesterday about -video opengl replicating the beviour of -video d3d & multithreading is not true. Besides it's possible that ATI implementation differs from Nvidia's (the one I tested). When I tested all this in Linux (at the time of the SDL2 adoption) I can confirm that vertical sychronization was completely unconsistent between different models of ATI cards and it didn't match the documented OpenGL behaviour. Maybe under Windows things are more consistent.

I am very interested in this patch or source and would be very happy, if you could give me some basic hint/ instructions on how to make this possible with a MAMEUIFX source. I see this video mode switching as a essential feature and I am trying to help mamesick (creator of MAMEUIFX) to make proper implementations of new shaders into his MAMEUIFX. Off course I would understand it, if you would it keep exclusive to GroovyMAME.

thx for listening u-man

[Calamity]

Maybe under Windows things are more consistent.

They aren't 

It turns out when using OpenGL vsync doesn't work with ATI (at least the one I'm testing). However it did with Nvidia.

https://www.opengl.org/wiki/Swap_Interval

GPU vs CPU synchronization
To glFinish or not to glFinish, that is the question!

Swap interval = 1 without glFinish​: The buffer swapping command instructs the GPU to swap the front and back buffers. This command is typically treated like any other GL command, and is executed by the GPU asynchronously from the CPU. However, because all subsequent rendering commands that affect the back buffer must wait until the back buffer has been swapped, these commands will pile up in the queue and eventually force a CPU synchronization. It is generally a good idea in this case to put the buffer swapping last in this case, and spend CPU time doing non-OpenGL tasks.

Swap interval = 1 with glFinish: The CPU thread can be synchronized with the buffer swap by calling glFinish() after issuing the swap. This introduces a penalty as it kills throughput advantages offered by the GL pipeline when the video card is under consistent activity. Video latency becomes the same as the vertical refresh period; at 60 Hz, this is 1/60th of a second or 16.666...ms. This method may save power on laptops, but may be less favorable for fast-paced games.

In one test case, in which "Wait for Vertical Refresh" was set to Always on both setups, an Intel graphics chipset from a 2011 Sandy Bridge laptop was found to exclude the buffer swap from glFinish, thus churning 1000 frames per second, and a PCI-e 2.0 AMD Radeon HD 3870 from 2008 was found to drop to 55fps with the addition of glFinish to SwapBuffers. If GPU<->CPU synchronization is desired, you should use a high-precision/multimedia timer rather than glFinish after a buffer swap.