glshim


If texture is reversed, maybe you can flip the graphics horizontal. I know, that bmp stored in wrong order, zeo was not at top left, it was at bottom left. Or you can look, where tex coords are set, then do a 1.0 - [tex coords], this reverses the flip.

Thomas
 
I know. The weird thing is it supposedly renders properly in OpenGL and I haven't yet checked to see what's different.
 
If it's BMP it's probably some code that depends on specific Endianness of the CPU?

If that's so some better platform independent code is needed at the texture loading stage.

There are many tutorials which are specific for x86 PC and so depend on the BMP bits to be alligned a certain way.
 
If it's BMP it's probably some code that depends on specific Endianness of the CPU?
Endian wouldn't cause a vertical flip. It would either cause the colours to be "inverted" and/or the pixels in each row to be displayed in the wrong order.
Unless there's some whacky bitmap loading code...
 
Enter this by itself as an "app", or with a game, for the DragonBox competition:)

Maybe team up, and include it in the code::blocks and/or cdev PNDs?

This would be maybe the most important dev library for Pandora,

bridging the gap between PC and handheld gaming.
 
Last edited by a moderator:
Woah thats right.


i recommend you too to enter the competition.


when your lib work, so many more is popossible.


Example when your project can compiler VMGL then have we a proberitare 3D OpenGL wwithin


Qemu Guests.Then Windows95 with 3D accerleration ist possible.


With DirectGL direct3D too.


Your project is very important for many fromm us and you have good chances on the compo.


Sorry for write errors because i wrote this with my mobile phone.
 
This is pretty awesome. As someone who doesn't have the time/knowledge to sort through OpenGL API tutorials and differences, this is the answer I've always wanted. Will take a look at this after it's out of beta.
 
Oh cmon - it's a huge amount of the way there. Beta just means I need you to try it so I know what needs to be fixed.
 
Last edited by a moderator:
I tried using it to build LWJGL thinking it might improve compatibility with Minecraft but the stupid thing is still trying to create an OGLES context. Hopefully something simple I messed up and can fix.
 
If it's BMP it's probably some code that depends on specific Endianness of the CPU?
Endian wouldn't cause a vertical flip. It would either cause the colours to be "inverted" and/or the pixels in each row to be displayed in the wrong order.

Unless there's some whacky bitmap loading code...
Yes it's probably the latter then. I think there's a lot of examples that presume BMP pixel order to a certain way. I forget the details but I remember having to rotate BMPs to FIX texturing problems until I managed to find this bug and improve my texture loading code...
 
If it's BMP it's probably some code that depends on specific Endianness of the CPU?
Endian wouldn't cause a vertical flip. It would either cause the colours to be "inverted" and/or the pixels in each row to be displayed in the wrong order.

Unless there's some whacky bitmap loading code...
Yes it's probably the latter then. I think there's a lot of examples that presume BMP pixel order to a certain way. I forget the details but I remember having to rotate BMPs to FIX texturing problems until I managed to find this bug and improve my texture loading code...
Are you speaking of Jumpman?

If yes, I just want to remind you that it works properly with MesaGL...

It's the sequence used to render graphics that is in cause, and trigger something that need to be fixed in linuxbochs's opengl. I'll probably try this WE (but not before) the track down the 2 problems I have running Jumpman: the hang at the end, and the upside-down graphics. And I'll update this thread with what I'll find.

Of course, if someone find what's wrong before me, feel free to publish result earlier :) . Jumpman looks a like a good game to play on the Pandora !
 
Hum, I tried to see why Jumpman hang at the exit, but it just hang inside "SDL_Quit()"... Nothing I can do I'm afraid :(

Also, I tried to understand why he is upside down, but there is a lot of glRotatef( ... ), so I can just guess there are peharps too many? I'm not sure I can debug further... I'll try some other software.
 
Just rotate everything around before drawing the frame?
 
Hum, I tried to see why Jumpman hang at the exit, but it just hang inside "SDL_Quit()"... Nothing I can do I'm afraid :(

Also, I tried to understand why he is upside down, but there is a lot of glRotatef( ... ), so I can just guess there are peharps too many? I'm not sure I can debug further... I'll try some other software.
Do you free up all the EGL stuff before quitting SDL?
 
I can't free anything, it's all handled (both init and end) by the libGL from linixbochs. That's quite magic... But I'm not sure it is related to freeing EGL... May be it's related to the game beeing upside-down... Some memory overflow or samething. I don't know. I'll try tomorow some more experiment, adding arbitrary glRotatef as mcobit suggested, to see the effect (or not).
 
Hum, I tried to see why Jumpman hang at the exit, but it just hang inside "SDL_Quit()"... Nothing I can do I'm afraid :(

Also, I tried to understand why he is upside down, but there is a lot of glRotatef( ... ), so I can just guess there are peharps too many? I'm not sure I can debug further... I'll try some other software.
Do you free up all the EGL stuff before quitting SDL?
This isn't guaranteed. It looks like some games don't free everything properly but others do. I'll look into it.
 
Last edited by a moderator:
This is looking really great .. maybe its time to start throwing the xscreensavers collection at it and see if we can get 'em built .. ;)
 
You can already build xscreensavers with jwzgles as it was developed for this purpose. You will need to add an eglcontext though.
 
Back
Top