Has jwz solved the OpenGL problem?

[ibisum]

Some exciting news - jwz ported xscreensaver to iOS:


http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/


He did it by implementing OpenGL 1.3 calls in OpenGLES1.1.


Does this mean we now have an easier solution for doing OpenGL conversions to Pandora? Who knows? I'm about to go download the code and have a look ..


What do you guys think?

 

[crow_riot]

just looked at it ... it probably makes it easier to port existing software. but doesn't nanoGL do the same?

 

[ibisum]

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]

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]

That sounds good!


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

 

[Edglex]

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!

 

[Pickle]

interesting, I think the most useful part I think the calllists. Doing a opengl port of alpehone for example might be much easier now.

 

[Cloudef]

Has jwz solved the OpenGL problem?

What problem exactly? All I see is rambling of API changes, and some wrapper code to port ancient software instead of moving on.

 

[Pickle]

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]

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.