Has jwz solved the OpenGL problem?

crow_riot

Well-Known Member
Joined
Sep 21, 2009
Messages
1,763
Location
.at
just looked at it ... it probably makes it easier to port existing software. but doesn't nanoGL do the same?
 

ibisum

Well-Known Member
Joined
May 6, 2009
Messages
1,135
I don't know enough about nanoGL to understand .. but just having the hundreds of GL XScreenSavers running on my iPad right now gives me a lot of hope that it can be useful in this context.
 

crow_riot

Well-Known Member
Joined
Sep 21, 2009
Messages
1,763
Location
.at
yes, that's for sure. it implements the full opengl 1.3 API (where applicable) which nanoGL didnt. someone should give it a try (looking at you pickle ;) )
 

mcobit

Advanced Member
Joined
Jul 28, 2008
Messages
6,910
That sounds good!


Is it just a library you link against instead of libgl?
 

Edglex

Member
Joined
Oct 27, 2010
Messages
160
This sounds cool. As to what is/isn't implemented, he says in the blog post:

There are a few things I couldn't figure out how to implement:
  • Sphere-mapped textures for environmental reflection: OpenGL ES doesn't have glTexGeni GL_SPHERE_MAP, and I don't know how to fake it, so the Flying Toasters aren't shiny.
  • There's glTexImage1D and I'm not sure how to simulate that with glTexImage2D.
  • There's no glPolygonMode with GL_LINE, so I don't see an easy way to implement wireframe objects with hidden surface removal. Maybe rendering them twice with glPolygonOffset?
  • Several of the hacks used GLUtesselator to decompose complex shapes into triangles, and I didn't implement that. I could probably port the code from GLU, but it's a huge piece of code and sounds like a pain in the ass, so I punted.
He also says:

The code is in hacks/glx/jwzgles.c. If you want to use it to port your own legacy code, just include jwzgles.h. Let me know if it works!
 
Last edited by a moderator:

Pickle

Mega GP Mania
Joined
May 30, 2006
Messages
5,453
Location
Detroit, Michigan
Website
Visit site
I don't know enough about nanoGL to understand
Really all these wrappers do is track state changes (glEnable/Disable) and collect vertex info (glVertex) and issue the draw commands when needed.


For the most part its not a huge problem to convert it to ES API. In the end its just manipulation of the data and states.


But there are cases where things like call lists can be very intrusive it may not be worth the rewrite, or not the motivation. The one case I mentioned was alpehone, where i just went with the sw render since I didnt want to put in the effort of rewriting the call lists.
 

ibisum

Well-Known Member
Joined
May 6, 2009
Messages
1,135
Cloudef: It could be either a) re-write OpenGL code to use GL ES architecture, or B) Plug in jwz's shim code, and rewrite nothing in order to get it running.
 
Top