26

Re: OpenGL ES

I made a work-in-progress commit to the GLES branch.  It's largely broken, but it's a big step forward.  It is only tested under OSX, and I'm certain it won't build anywhere else.  I'll take care of all the remaining flaws and portability issues as the ES port shapes up.

This new code uses optimized vertex buffer objects for all SOL rendering.  All display list usage has been removed from the core renderer.  All level and ball geometry specification is compatible with OpenGL ES, though a lot of incompatible state management code remains to be updated.  DLs are still in use by the GUI renderer, as well as by goals, switches, teleporters, etc.

The shadow mechanism has been converted to multi-texture, and the renderer now executes in a single pass.  The shadow works in the traditional fashion, and I have not yet converted parasti's shadow clip mechanism.  I set the shadow material flag on pretty much all materials.  We can disable this on a per-material basis as necessary.

Some of the generated texture coordinate usage has been eliminated, most notably in the shadow renderer, but some remains, such as in the rendering of environmental textures.

Reflections work correctly, largely because changes are limited to the "share" directory.

No billboards are currently drawn, so no level backgrounds or ball insides appear.

There are new bugs.  New polygon offset issues have popped up, and some maps leak state into the GUI renderer.  These will all be tracked down in time.

27

Re: OpenGL ES

Sweet!

Need to include glext.h with GL_GLEXT_PROTOTYPES defined, then it compiles.

What is the alternative for texgen? Vertex shaders?

28

Re: OpenGL ES

parasti wrote:

What is the alternative for texgen? Vertex shaders?

In most cases, texture coordinate generation is simulated through creative use of vertex array pointers.  In the one case where this fails (environmental materials) something more creative is necessary (I don't know what).  I'm not going to jump on vertex shaders just yet, despite the fact that this would be awesome, because I want to have a pure ES 1.1 path in the game.  If there is to be any ES 2 stuff, I want it to be optional and not manditory.


Just a little progress update on the port...

I converted the billboard stuff to VBO, so the backgrounds are functioning again, as are the ball insides.  I fixed a couple bugs in the new renderer that mopped up all of the polygon offset and state leak issues that I was aware of.

I also took the first step toward converting the goal/switch/teleporter stuff from display list to VBO, doing so in such a way that continues a trend that's been building for years.  It used to be that almost everything (except the level itself) was drawn using raw GL, balls and goals included.  Then some years ago I converted the balls to SOLs, reusing the level renderer for ball rendering, and creating something far more flexible.  Later, others did the same to the coins, adding the grow and shrink coins in the form of SOLs.

So now I'm thinking about taking this a bit further by converting the goal geometry to SOL.  It seems to work well, so I'll do the same to everything in the geom.c module, including switches, teleporters, flags, and markers.  In general, modifying things to use the core renderer is a good thing, as it means that any modifications and improvements to that renderer become universal.

The remaining display list and immediate mode code lies in the GUI renderer and the particle system.  The GUI will be easy to convert to VBO, but the particle system is less clear.  The obvious approach is easy, but inelegant.  It would be nice to use point sprites, but it would be tough to reproduce the current particle system exactly in that way without the use of fragment programs.

29

Re: OpenGL ES

OMG! This stuff seems to come to RLK immediately. I would need two weeks with a GL-ES handbook, and TWO flashlights!

This is incredible, and fast progress. I would think I will be beta testing a Wiz version within a fortnight!

Brilliant work RLK (as per usual).

Currently Playing:
Celeste and Electronic Super Joy

30 (edited by gjtorikian 2011-03-28 07:37:19)

Re: OpenGL ES

I agree--amazingly quick work indeed. I've been keeping up with the diffs, and I have to ask--how are you testing the OpenGL ES stuff? Do you just search for a display list and work on converting it?

As I noted in another thread, I can provide you with a list of all the incompatible OpenGL/ES lines of code. Some of them are very simple, like GLdouble and glColor3fv (replace with float, convert to glColor4f with an extra 1.0f passed in). Or, maybe they've been kept in the latest OpenGL version, but not the ES flavor. I haven't checked.

P.S. Seems that this line in share/solid_base.c is causing a problem for me:

 for (i = 0; i < fp->ic; i++) get_index(fin, fp->iv + i);

I re-ran mapc across all of /data but I'm not sure what's causing the error in the struct.

31

Re: OpenGL ES

Kind of wish I had had the time to do this a while back.  I knew VBOs were the way to go but so much other stuff got in the way of committing more time to it. It's going to run incredibly quick on the new hardware.  Have you got the iPad 2 yet rlk ?

To answer gjtorikian, with my port, once I had determined a template for handling the display lists, yes it was just a case of going through every one and updating it.  The "clever" bit that everyone failed on in the port was the texture management bit.  I have had people begging me for that file by email before now smile

32

Re: OpenGL ES

parasti wrote:

Need to include glext.h with GL_GLEXT_PROTOTYPES defined, then it compiles.

This might compile but will not work when linking from my experience with extensions in gles. If the final solution uses ext (oes) functions then pointers need to be defined and set using eglGetProcAddress.

Also i wanted to mention to anyone testing there is a opengles emulation libraries for linux/windows by imgtec.
http://www.imgtec.com/powervr/insider/p … vframe.asp
Ive used these to develop some opengles apps before moving to the native platform.

33

Re: OpenGL ES

Oh no, I was merely documenting a quick workaround for anyone interested in testing on the desktop. I am mostly aware of the problems it would involve as a long term solution.

34

Re: OpenGL ES

gjtorikian wrote:

I agree--amazingly quick work indeed. I've been keeping up with the diffs, and I have to ask--how are you testing the OpenGL ES stuff? Do you just search for a display list and work on converting it?

Essentially, yes.  I have not yet attempted to compile the game in an ES environment.  I'm simply working off my knowledge of the game and the OpenGL ES Common Profile, Annotated Difference Specification.

gjtorikian wrote:

As I noted in another thread, I can provide you with a list of all the incompatible OpenGL/ES lines of code. Some of them are very simple, like GLdouble and glColor3fv (replace with float, convert to glColor4f with an extra 1.0f passed in). Or, maybe they've been kept in the latest OpenGL version, but not the ES flavor. I haven't checked.

Yes, I'd appreciate your list.


gjtorikian wrote:

P.S. Seems that this line in share/solid_base.c is causing a problem for me:

 for (i = 0; i < fp->ic; i++) get_index(fin, fp->iv + i);

I re-ran mapc across all of /data but I'm not sure what's causing the error in the struct.

What's the problem?

35

Re: OpenGL ES

Lazrhog wrote:

Kind of wish I had had the time to do this a while back.  I knew VBOs were the way to go but so much other stuff got in the way of committing more time to it. It's going to run incredibly quick on the new hardware.  Have you got the iPad 2 yet rlk ?

I don't feel the need for an iPad 2 yet.  It's just not enough of an upgrade for me.  I'm confident the original iPad will run Neverball at full quality, and I hope that the improvements I'm making now will help ensure that.

I did buy a Nintendo 3DS yesterday though.  I'd love to do some homebrew for that.  Real-time autostereoscopic rendering is one of my areas of research, and a field in which I've published a number of articles.

36

Re: OpenGL ES

Pickle wrote:
parasti wrote:

Need to include glext.h with GL_GLEXT_PROTOTYPES defined, then it compiles.

This might compile but will not work when linking from my experience with extensions in gles. If the final solution uses ext (oes) functions then pointers need to be defined and set using eglGetProcAddress.

Yeah, we're already neck deep in that.  I'm not worrying about it just yet, as OSX lets you get away with using extensions without GetProc-ing them.  I'll start testing under Linux soon, and I'll need to take action then.

37

Re: OpenGL ES

The Particle System

The Neverball particle system is responsible for drawing the explosion of stars that occurs when a coin is grabbed, the spinning stars in an active goal, and the squiggles in a teleporter.

The current implementation is laughably bad.  It transforms and billboards each particle individually and calls a display list for each consisting of a single textured quad.  I'd love to collapse most or all of these into vertex arrays, but that's made impossible by the need to billboard them.  The straightforward solution is to replace the tiny display list with a tiny VBO and allow the inelegance and inefficiency to remain.

One alternative to this is to adopt the standard approach to particle rendering, point sprites.  A point sprite is a textured square drawn straight to the screen, scaled for perspective.  It's essentially an automatic billboard for small things. OES_point_sprite is a mandatory extension to OpenGL ES 1.1, which means we can count on its presence on any conforming implementation.

Unfortunately, the current particles have a strange behavior: each rotates about its own center.  This is impossible to reproduce using the fixed function point sprite mechanism.  On an ES 2 system, a fragment program can rotate the texture coordinate before the texture lookup is made, but on ES 1 there's no opportunity for a texture transform because the point sprite is generated after T&L occurs.

So I propose to do the point sprite implementation anyway.  I'll do what I can to add animation and interest to the goal and teleporter particles, and I think I can create something visually appealing given the constraints.  If we really miss the original effects, it can be brought back via the (future) ES 2 path.

Comments welcome.

38

Re: OpenGL ES

I might be off on a tangent with this, but could you use a render to texture to do the rotation and then use that texture with your point sprite?

39 (edited by gjtorikian 2011-03-28 19:25:00)

Re: OpenGL ES

rlk wrote:

Yes, I'd appreciate your list.

Ok--I've attached the list to this post. Please note the following:

1. Display list code that needs to be rewritten is not included here
2. It appears that I've already gone through and converted glColor3f/glColor3fv references to their 4f counterparts.

I have not included what, exactly, is omitted in ES. I can discuss this with you in an e-mail if you prefer. Some of them are not so obvious--e.g. for

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);

Only

GL_CLAMP_TO_EDGE

exists in OpenGL ES. Often it is a single parameters, sometimes an entire method.


rlk wrote:

What's the problem?

I'm not sure--at the moment, it's a runtime segmentation fault. I'll dig a little deeper but probably not for a while. I was just wondering if you knew of a change in this area off the top of your head.

Post's attachments

unsupported_gl_list.txt 2.94 kb, 128 downloads since 2011-03-28 

40

Re: OpenGL ES

Pickle wrote:

I might be off on a tangent with this, but could you use a render to texture to do the rotation and then use that texture with your point sprite?

Well, yes, I see what you're getting at.  They would all rotate in sync that way though, which is still not as varied as the current behavior. Plus that's a somewhat heavy-handed solution to a simple problem.  Besides, we can't count on FBO support, and I'm certainly not going to incur a read-back on a mobile platform just for the sake of spinning stars.

41

Re: OpenGL ES

gjtorikian wrote:

I have not included what, exactly, is omitted in ES. I can discuss this with you in an e-mail if you prefer. Some of them are not so obvious--e.g. for

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);

Only

GL_CLAMP_TO_EDGE

exists in OpenGL ES. Often it is a single parameters, sometimes an entire method.

This list is much shorter than I expected it would be.   big_smile   Everything here is manageable.  CLAMP_TO_EDGE is not only the correct substitution in that case, it is technically more correct that CLAMP.  The use of CLAMP was probably a holdover from IRIX.

gjtorikian wrote:
rlk wrote:

What's the problem?

I'm not sure--at the moment, it's a runtime segmentation fault. I'll dig a little deeper but probably not for a while. I was just wondering if you knew of a change in this area off the top of your head.

I haven't seen anything like this, but I will be sure to do some valgrinding before I'm through.

42

Re: OpenGL ES

rlk wrote:
Pickle wrote:

I might be off on a tangent with this, but could you use a render to texture to do the rotation and then use that texture with your point sprite?

Well, yes, I see what you're getting at.  They would all rotate in sync that way though, which is still not as varied as the current behavior. Plus that's a somewhat heavy-handed solution to a simple problem.  Besides, we can't count on FBO support, and I'm certainly not going to incur a read-back on a mobile platform just for the sake of spinning stars.

simple idea, just make a tile sheet with the star rotation animation. You really would only need a few frames to make it appear animated. You would need more texture memory, but is shouldn't be too much.

43

Re: OpenGL ES

rlk wrote:

This list is much shorter than I expected it would be.   big_smile

That's very true. Everything else is tremendous display list usage; the files I identified for this were back.c, geom.c, gui.c, part.c, and solid_gl.c. By the way, these lines numbers might not exactly match up with whatever you have on disk, as I'm adding and removing lines of code for my own Android purposes.

Like Lazrhog, I went through and tried to "fake" ES usage in areas where display lists were used. I had created my own methods for IsList, CallList, e.t.c. and tried my best to draw to the screen.

44

Re: OpenGL ES

Pickle wrote:

simple idea, just make a tile sheet with the star rotation animation. You really would only need a few frames to make it appear animated. You would need more texture memory, but is shouldn't be too much.

But how do you set the texture coordinate of the point sprite to refer to the desired sub-tile of the texture?

The texture coordinate of a point sprite is generated by the GL.  It's always 0.0 to 1.0 along both axes, and the only way to specify a different texture coordinate is with a fragment program. But if you're going use a fragment program to translate and scale your coordinate into a texture atlas, then you might as well just rotate the coordinate in the first place.

(Don't worry everybody, I'm not fishing for solutions.  It's all under control.)

45 (edited by themacmeister 2011-03-29 04:24:04)

Re: OpenGL ES

rlk wrote:

but on ES 1 there's no opportunity for a texture transform because the point sprite is generated after T&L occurs.

I thought (at least with ES 1.1+) that you had ample opportunity before GLDisplayFrame (or whatever it's called). My entire experience is through a single reference book, but I will post an example of what I mean later. Please disregard this if you think I'm talking out of my @rse, which I almost certainly am -- I don't want to lock horns with RLK again big_smile

EDIT: on reflection, I think I should ban myself from this discussion... and leave it to people who know what they are doing. sorry folks

Currently Playing:
Celeste and Electronic Super Joy

46

Re: OpenGL ES

No idea is too ridiculous to be unutterable.

47

Re: OpenGL ES

gjtorikian wrote:

No idea is too ridiculous to be unutterable.

...unless you utter it to RLK :doh:

Currently Playing:
Celeste and Electronic Super Joy

48

Re: OpenGL ES

rlk wrote:
Pickle wrote:

simple idea, just make a tile sheet with the star rotation animation. You really would only need a few frames to make it appear animated. You would need more texture memory, but is shouldn't be too much.

But how do you set the texture coordinate of the point sprite to refer to the desired sub-tile of the texture?

The texture coordinate of a point sprite is generated by the GL.  It's always 0.0 to 1.0 along both axes, and the only way to specify a different texture coordinate is with a fragment program. But if you're going use a fragment program to translate and scale your coordinate into a texture atlas, then you might as well just rotate the coordinate in the first place.

(Don't worry everybody, I'm not fishing for solutions.  It's all under control.)

you can separate the main texture into sub textures using glTexSubImage2D right?

49

Re: OpenGL ES

Pickle wrote:

you can separate the main texture into sub textures using glTexSubImage2D right?

Yes, glTexSubImage2D allows an image buffer to be copied to a sub-tile of a texture.  But the creation of an atlas is not the problem.  The problem is the specification of texture coordinates.  Point sprite texture coordinates range from 0.0 to 1.0, and thus each sprite will display the entire atlas rather than one sub-tile of it.

50

Re: OpenGL ES

themacmeister wrote:

I don't want to lock horns with RLK again big_smile

I sincerely hope I'm not coming off as an asshole in this discussion.  I'm sorry if I did in a previous discussion with you, themacmeister.