Need Help Compiling - Lack Of Opengl


nsdk

Still Fresh
Joined
Jan 30, 2010
Messages
1
Hi

I am trying to compile Dungeon Crawl Stone Soup (the tile version), but I am getting some errors because of the lack of OpenGL. What could be the next step in order to try to use OpenGL ES instead? I think the game's use of opengl is very limited, so what would be the easiest way to find out if opengl ES is "good enough"?
 
Inspect all of the gl code - any and all functions starting with gl*, or egl*, and so on .. grok the code so that you understand whats needed from the perspective of OpenGL, and from there you can formulate a plan to convert it to OpenGL ES (1.1 at least..)
 
PokeParadox said:
Alex777 said:
Have you (or anyone else) had any success with this?
Yes Pickle and I had relative success with Gish.

Some quick tips:
Use GL_TRIANGLE_FAN for GL_QUADS
all glBegin s will have to become vertex arrays.

Not only that ive converted d1x/d2x(descent), ken labyrinth, prboom(doom) all from opengl to opengles. It can be done but takes time.
 
Last edited by a moderator:
Pickle - what are the chances you could post a big fat diff of, for example, the work it took on prboom .. or some such thing?

Personally, I think I would learn a lot just by reading your patch before/after the changes .. I know some folks might not be interested in this, but I am for sure.

Care to post patches of the projects you've done so far, so we can also gain wisdom?
 
torpor said:
Pickle - what are the chances you could post a big fat diff of, for example, the work it took on prboom .. or some such thing?

Personally, I think I would learn a lot just by reading your patch before/after the changes .. I know some folks might not be interested in this, but I am for sure.

Care to post patches of the projects you've done so far, so we can also gain wisdom?

I think gish might the only one that I might worked off with source control, so i could produce a patch.
If I were you I would grab the source zips I posted and get the standard source and use a application that does folder diffs. I personally use kdiff.

Also check out my kens's lab and prboom development threads, which have example where I asked how to convert certain code.

Most of the work involves converting opengl immediate mode to vertex arrays. For example:

Code:
glBegin(QUADS)
glvertex3f(x1,y1,z1)
gltexcoord(xt1,yt1)
glvertex3f(x2,y2,z2)
 gltexcoord(xt2,yt2)
glvertex3f(x3,y3,z3)
 gltexcoord(xt3,yt3)
glvertex3f(x4,y4,z4)
  gltexcoord(xt4,yt4)
glEnd()

glEnableClientState(GL_VERTEX_ARRAY)
glEnableClientState(GL_TEXTURE_COORD_ARRAY)
quad = {x1,y1,z1, x2,y2,z2, x3,y3,z3, x4,y4,z4 };
tex = {xt1,yt1, xt2,yt2, xt3,yt3, xt4,yt4 };
glVertexPointer(3, GL_FLOAT, 0, quad );
glTexCoordPointer(2, GL_FLOAT, 0, tex );
glDrawArrays(GL_TRIANGLE_FAN, 0, 4 );
glDisableClientState(GL_VERTEX_ARRAY);
 glDisableClientState(GL_TEXTURE_COORD_ARRAY);
 
Last edited by a moderator:
Cool, thanks for the tips Pickle .. I'll have to dig around and see if I can work out a patch for your mods on the mainline sources some time .. its really interesting to see all your progress, and I think I'd learn a lot from producing patches ..
 
torpor said:
Cool, thanks for the tips Pickle .. I'll have to dig around and see if I can work out a patch for your mods on the mainline sources some time .. its really interesting to see all your progress, and I think I'd learn a lot from producing patches ..

Even just looking at the ported source would be useful as I usually create defines to separate opengl from opengles, so you can see both. You know that I havnt been doing gl stuff for that long, i have just been picking applications that look like they could work. The first was ken's lab which was a good one to learn just converting gl quads to es.
 
Last edited by a moderator:
Code:
glBegin(QUADS)
glvertex3f(x1,y1,z1)
gltexcoord(xt1,yt1)
glvertex3f(x2,y2,z2)
 gltexcoord(xt2,yt2)
glvertex3f(x3,y3,z3)
 gltexcoord(xt3,yt3)
glvertex3f(x4,y4,z4)
  gltexcoord(xt4,yt4)
glEnd()

glEnableClientState(GL_VERTEX_ARRAY)
glEnableClientState(GL_TEXTURE_COORD_ARRAY)
quad = {x1,y1,z1, x2,y2,z2, x3,y3,z3, x4,y4,z4 };
tex = {xt1,yt1, xt2,yt2, xt3,yt3, xt4,yt4 };
glVertexPointer(3, GL_FLOAT, 0, quad );
glTexCoordPointer(2, GL_FLOAT, 0, tex );
glDrawArrays(GL_TRIANGLE_FAN, 0, 4 );
glDisableClientState(GL_VERTEX_ARRAY);
 glDisableClientState(GL_TEXTURE_COORD_ARRAY);

would it not be easier (not to mention more reusable) to make a small lib with glBegin(TYPE) setting up an empty vert, tex and normal array, gltexcoord glvertex3f pushing items into the arrays and finally glEnd calling glDrawArrays for the appropriate type set in glBegin...


this approach would probably not be 100% all the time, but I'd bet it would be able work in the majority of cases, the main drawback is that the arrays would have to be a fixed maximum size, but as you can only have one begin/end at a time the same set of arrays can be reused...
 
chris_c said:
would it not be easier (not to mention more reusable) to make a small lib with glBegin(TYPE) setting up an empty vert, tex and normal array, gltexcoord glvertex3f pushing items into the arrays and finally glEnd calling glDrawArrays for the appropriate type set in glBegin...


this approach would probably not be 100% all the time, but I'd bet it would be able work in the majority of cases, the main drawback is that the arrays would have to be a fixed maximum size, but as you can only have one begin/end at a time the same set of arrays can be reused...

nanogl basically does this, ive seen similar approach with ID's prboom port for the iphone
 
Last edited by a moderator:
Back
Top