Home Page Forums MAME Non-Windows MAME Support SDLMAME OpenGL hardware (de)accelleration

I just compiled the latest SDLMAME with the test3 patch, but the 3D-acceleration doesn't seem to work.

Changing from soft to opengl results in abysmal framerates and maxed-out CPU, while all games I tried run full speed in software-mode with plenty of CPU power left.

I am running Ubuntu 6.06 and my GFX card is a Ati Radeon x1300 (using the latest official Ati drivers).

Hardware OpenGL works with other programs, so I probably messed something up?

Here is the output of the program:

Note: the Average FPS stated here must be wrong, during the game it was almost always below 20, with choppy sound and everything.

Please help me! I just went through compiling AdvanceMAME, XMAME and XMAME/SDL and it seems like I finally found the perfect version, if it weren't for the not working OpenGL.

So this only happens with OpenGL and not if you run with "-video soft"? Because this sounds more like an RDTSC issue than an OpenGL one.

Also, you do realize the OpenGL mode will *not* speed up 3D games - they are still rendered internally in software. Only vector games currently get true h/w acceleration, for the rest it's just a way to get nice filtered hwstretch on Linux at last (although on my GeForce 7800 it's also a lot faster than software).

Yes, it's just as I said.
For example, if I run Puyo Puyo 2 in soft mode I get smooth 60 FPS, in opengl mode I get constant 5 FPS... and the image quality is really poor, as you can see on the screenshot.

[screenshot cut for bandwidth savings]

And yes, I realize the acceleration is only for the scaling which is exactly what I am looking for (I want to scale to my native LCD resolution via OpenGL, like I do in Mednafen already).

The text looks awful at output resolutions below 640x480, this is known. You can mitigate it by using a plainer .bdf font.

Apparently whatever I'm doing is hitting a "fallback to MesaGL" path in ATI's drivers. I'll ask Pete, since he's expert with dealing with their Linux drivers.

If you're capable, try changing to different 32-bit pixel formats in glTexImage2D() (src/sdl/drawsdl.c). The game will look wrong then, but if it suddenly gets very fast on some format let me know.

It is not the font. Look at the image around the menu, it is distorted in some places.

This is how it looks in soft mode:



The font looks perfectly fine here, as does the image. (disregard the black blotch on the image, it has nothing to do with SDLMAME)

I tried using RGBA instead of BGRA, but it didn't make any difference, except for the changed colors. The only other 32bit format I could find was GL_DEPTH_COMPONENT32 and while I don't really see anything anymore... the cpu usage is normal now and at least the sound seems perfectly fine!

The image just stays white all the time but if I press Tab I see the menu but the text is just a bunch of white blocks.

Odd. I may have to see if I can find an ATI PCI-Express card cheap and bang on it.

I just recompiled Mednafen and there's no problem with OpenGL there at all.
It seems to use GL_RGBA for everything.

Maybe you can figure something out by looking at how it works there? I don't understand much of this...

Follow the above link to get to the source.
You'll probably be interested in src/drivers/opengl.cpp . The file is pretty small, I almost pasted it here.

Let us at least go through all the options before you buy another gfx card (especially if it's such a useless waste of money like my card! ).

They're doing exactly what I'm doing modulo RGBA vs BGRA. Weird.

ETA: well, ok, a few differences.

Try this:
src/sdl/window.h, line 61 (should be right after "int yprescale", add this line:
int uploadedonce;

And in src/sdl/drawsdl.c, line ~1077 (I'm working off a MAME u11/12 updated codebase here so it's not exactly test 3), delete the glTexImage2D() call and add these lines:

glPixelStorei(GL_UNPACK_ROW_LENGTH, texture->rawwidth);

if (!texture->uploadedonce)
{
glTexImage2D(GL_TEXTURE_2D, 0, 4, texture->rawwidth, texture->rawheight, texture->borderpix ? 1 : 0, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8, dbuf);
texture->uploadedonce = 1;
}
else
{
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, texture->rawwidth, texture->rawheight, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8, dbuf);
}

In theory, those things (which Medafen also does) should help. In practice I saw no difference on my NVidia card - it was 290 FPS either way in Gokujou Parodius, but maybe ATI's drivers will appreciate the help

Unfortunately it didn't help.

And why does SDLMAME say my average framerate was 59FPS while actually I had constant 5FPS?

Urge to destroy gfx card rising...

If you hit F11 while in-game what rate does it say?