I'm messing around with OpenGL support in SDL for my compile of SDLMAME.
I managed to get it to compile by removing the line #define GL_ARB_multitexture 1 in GL/gl.h. Before I removed that I had an error where it didn't know what PFNGLACTIVETEXTUREARBPROC was. By removing the define, the GL/glext.h adds the prototype itself, and defines GL_ARB_multitexture explicitly.
The problem is that MAME just displays white blocks instead of letters, or a big white square for the screen - which sounds like it's unable to render textures.
What's going on here? MiniGL is saying in its header that it supports multitexturing, but it doesn't compile unless I disable the minigl multitexturing bit.
So is multitexturing supported or not? Is this the problem? Is it possible to disable it?
PFNGLACTIVETEXTUREARBPROC is used to obtain the glActiveTexture() function (a gl extension) like that wglActiveTexture = (PFNGLACTIVETEXTUREARBPROC) wglGetProcAddress((LPCSTR)"glActiveTextureARB");
thellier wrote: PFNGLACTIVETEXTUREARBPROC is used to obtain the glActiveTexture() function (a gl extension) like that wglActiveTexture = (PFNGLACTIVETEXTUREARBPROC) wglGetProcAddress((LPCSTR)"glActiveTextureARB");
But glActiveTexture() is builtin minigl
wglActiveTexture=glActiveTexture;
*GetProcAddress() can also be used with MiniGL. It will simply return a pointer to the built-in function.
Thanks for the feedback. I think now it's something different. When it calls glTexImage2D it returns an Invalid Operation error. Even when I force the width and height to 256, and tell it to use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV specifically, it still returns this.
I'm suspecting MiniGL or Warp3D or something doesn't quite support what SDL expects....
Spirantho wrote: Thanks for the feedback. I think now it's something different. When it calls glTexImage2D it returns an Invalid Operation error. Even when I force the width and height to 256, and tell it to use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV specifically, it still returns this.
I'm suspecting MiniGL or Warp3D or something doesn't quite support what SDL expects....
Are you setting the internal format parameter to GL_BGRA? Or the format paramter? MiniGL doesn't support GL_BGRA for internal texture formats (textureformat.c SelectInternalFormat()), but can unpack texture data in GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV (unpack.c SelectUnpacker()). Make sure that internalformat = GL_RGBA.
I found that if I set the format to the number of bytes (3 or 4) and set the type to GL_UNSIGNED_BYTE then the glTexImage2D works, and so do the subsequent bindings (though I think the glTexSubImage2D is still failing). However, it does actually render something! Garbage, of course, but something.
I remember having the problem with text rendered as blocks when doing the Descent Rebirth port. The non-gl version would render correctly, but the gl version would render only blocks. Probably a related problem. If you find the solution, don´t hide it for yourself ;)
Spirantho wrote: Yes, the internal format is set to GL_RGBA.
I found that if I set the format to the number of bytes (3 or 4) and set the type to GL_UNSIGNED_BYTE then the glTexImage2D works, and so do the subsequent bindings (though I think the glTexSubImage2D is still failing). However, it does actually render something! Garbage, of course, but something.
Setting the format to 3 or 4 makes absolutely no sense, so I don't know why that's even working. However, I was wrong about GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV being supported as a source format. Well, it is supported, but not by glTexImage2D. To find the list of supported source formats, have a look at the SelectUnpacker() function in textureconvert.c (which is distinct from MGLSelectUnpacker() in unpack.c).
My suggestion would be to workaround this by manually converting the pixel data from ARGB to RGBA, and then call glTexImage2D() with format = GL_RGBA, and type = GL_UNSIGNED_BYTE.
Right, we're getting somewhere now. With Wazp3d it crashed for some reason, but I didn't look into why. With Warp3D though, using those changes, it worked! All the colours were wrong, of course, but it worked, and gave a hefty speed-up!
Question is what to do about it. Where can I get the source to minigl latest version? It would be better to add support rather than hacking and slowing down MAME... it may well fix Descent Rebirth too!
Spirantho wrote: What I did to make it work was to shift each int32 in the texture up by 8 bits.
This would convert ARGB into RGBA.
Are you sure that your input data is correct? It sounds much like an endianness problem because ARGB is BGRA backwards.
If you load a file which contains raw BGRA data into memory and then read 32bit words from the memory, on a little-endian machine you get BGRA words, but on a big-endian machine you get ARGB words.
This is what puzzles me too. I spent ages faffing around with reversing endianness and eventually via trial and error I found I just needed to shove the bytes up by one. It doesn't make sense, which makes me thing something somewhere is misbehaving (and the fact that Wazp3D renders differently supports this).
Hello I have tried your Mame binary with my Sam440 Got some old Mame roms but the majority dont seem to works anymore "blah blah rom xxx.xxx missing" Found arkanoid roms that wants to run : not a sexy game :-/ 1) Run will real Warp3D 2) run with Wazp3D renderer:soft to bitmap... but slowly 3) Start then freeze with Wazp3D renderer:Compositing2D ..... I am investigating
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
