Opengl Stability


frozen

Still Fresh
Joined
Jul 20, 2009
Messages
36
Hi

I'm working on a 2d game for the Wiz. It uses opengl (es wrapper) on windows to render sprites and tiles. Should I implement a 2d software-rendering system, or could I use opengl es on the wiz? Is the opengl driver stable enough to use it? I need very basic opengl functionality only: rendering textured, prelit 2d triangles with ortho transformation. Is there any information about the release date of a better opengl binary, or the next version at least?

Thanks in advance,
frozen
 
frozen said:
Hi

I'm working on a 2d game for the Wiz. It uses opengl (es wrapper) on windows to render sprites and tiles. Should I implement a 2d software-rendering system, or could I use opengl es on the wiz? Is the opengl driver stable enough to use it? I need very basic opengl functionality only: rendering textured, prelit 2d triangles with ortho transformation. Is there any information about the release date of a better opengl binary, or the next version at least?

Thanks in advance,
frozen

First I would keep your opengles rendering, I would only add sw rendering if theres another platform you want to support that doesnt have any opengl support.
Overall the GPH opengles driver situation hasnt been great. There have been driver releases, but not in a organized manner, theres no way to tell which driver is newer.
Also to the use the driver is also a bit odd, see my thread: http://www.gp32x.de/board/index.php?/topic/47879-howto-for-opengl-es-1-1-lite-on-the-wiz/
(The only reason it worked for me is nanogl can link using dsym at runtime.)

That said, there is a driver in the works, as said by GPH. But they are late on when they expected something to be ready and my contact has vanished. But im trying other ways to get some information. My hope is to take the work done by cpasjuste with SDL 1.3 and apply to the wiz and infact everything links and compiles, but the latest driver needs another function that I dont have in libwizGLES.

Bottom line is that GPH hasnt supported the driver very well only leaking the driver bits here and there. But once they do release a driver that can:
1. Be linked to directly (although a driver hack was foudn to get around this)
2. Supply all the extra needed source with all the needed functions (i.e port.cpp/libwizGLES)
Then we will have a nice method of accelerating applications.
 
Last edited by a moderator:
Nobody has port.cpp? If that would help, I do have a copy somewhere I could put up until GPH sort this out.
 
Orkie said:
Nobody has port.cpp? If that would help, I do have a copy somewhere I could put up until GPH sort this out.

We do have it but it is an older version. With the latest fw I think a driver was released but the matching port.cpp wasnt included. So when i link directly to one opengles lib I missing
GLESOAL_GetDisplayDirection
 
Last edited by a moderator:
This getdisplaydirection function is pretty simple. It returns a number between 0 and 3 indicating the orientation of the screen. 0 is normal. I added that to wizGLES and it works fine. I don't know what the other 3 directions are represented as, I just looked quickly at the disassembly to find the "0 degree" rotation.

Oh btw pickle, I have created a bundle with nanoGL, wizGLES, and libcastor that I want to distribute to make things easier for Allegro users. I have gotten permission from the nanoGL author and Orkie to release it under a BSD license, but so far I am lacking your permission to use said license for wizGLES (I have cut out all of the GPL kernel stuff). Would this be ok?
 
trentg said:
This getdisplaydirection function is pretty simple. It returns a number between 0 and 3 indicating the orientation of the screen. 0 is normal. I added that to wizGLES and it works fine. I don't know what the other 3 directions are represented as, I just looked quickly at the disassembly to find the "0 degree" rotation.

Ok i did see your post in the other thread but I didnt see anywhere that you tried it and worked. Thats good I will try that.
There werent any other functions missing?

Edit:
wizGLES: well technically the source is GPH's or where they got it from. My view is that the lib can be used in anything, but if used in any project the source should be provided if someone asked for it. Although it sounded like some of the commercial games are using it. So it probably could be put under the BSD license.

Ive also been thinking of putting together a devel package of all of the libs, maybe we can collaborate once I get SDL/glu 1.3 going. It be pretty nice of all the 3d goodies were in one organized package.
 
Last edited by a moderator:
Yes, that sounds good. I'm working on Allegro (it now has gp2x wiz support) and a simple package that anyone can easily get and compile is necessary. Right now I have all I need in the library but there are some things missing like touchscreen input.
 
I have been working on a mini-game using OpenGLES, and I'd love to be using the Wiz properly .. so far Wiz just isn't a target because of the setup confusion/hassle, but it could very easily be .. so maybe you guys can just put your package up somewhere and we can jump the whole from "libs hacking" to working-demo to "Just Plain Works Now" status?
 
torpor said:
I have been working on a mini-game using OpenGLES, and I'd love to be using the Wiz properly .. so far Wiz just isn't a target because of the setup confusion/hassle, but it could very easily be .. so maybe you guys can just put your package up somewhere and we can jump the whole from "libs hacking" to working-demo to "Just Plain Works Now" status?

Well if you saw my other thread SDL 1.3 is working, so now I plan to clean everything up and package it into a easy to use devel package. I might get started on it today.

If anyone can try out the nehe demos, i put them up, check my SDL 1.3 opengl es thread, please :)
 
Last edited by a moderator:
Back
Top