51

Re: OpenGL ES

As long as Neverball wants to stay fixed-function, I imagine point sprites will allow for more varied particle effects without the cost associated with the one-quad-per-particle approach. If that means losing rotating stars, so be it I guess.

52 (edited by Pickle 2011-03-30 00:14:17)

Re: OpenGL ES

rlk wrote:
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.

I certainly dont and appreciate you taking to the time to entertain my suggestions.

Your right again, I double checked and glTexSubImage2D isnt going to help at all, i had it backwards in my mind thinking that you could create a texture from an existing texture, but it only allows you to change an existing texture.

If you had each tile already in separate textures (each tile would be in its own file) could you specify a specific texture per point sprite?

53

Re: OpenGL ES

rlk wrote:

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.

To be quite honest I had it coming. I am just thrilled that work has begun on GL-ES, so I may at some point in the future play handheld neverball on my GP2X Wiz!

Currently Playing:
Celeste and Electronic Super Joy

54

Re: OpenGL ES

Just another quick status update here.  All the geom.c stuff has been converted over to use the SOL renderer.  That includes the golf ball markers and the flag, the large inside-out sphere used for background gradient rendering, and the big black rectangle used to produce the fade-in effects... stuff we generally don't ever think of as being active geometry elements.

This leaves only the GUI and the particle system to be updated.  I'm working on the GUI now.  It has always been somewhat wasteful of GL resources, so this is a nice opportunity for optimization.  As with everything else, despite broad and deep changes to the core renderer, you should see absolutely no visible difference.

It's worth stressing the fact that I'm not just hacking and slashing Neverball to fit the ES API.  I'm making a very carefully thought-out refactoring of the renderer, taking advantage of every possible optimization, expunging obsolete modules, and generally tidying everything up both in terms of code layout and GL state management.  We've needed a thorough spring cleaning for a long time.

55

Re: OpenGL ES

Am I about to lose my credit for the OpenGLES port on the main neverball page ?   wink

one of the main issues I found was state management.  In the end I decided to have a base setup and then deviate and put back when necessary (as you already know rlk).  The mobile devices don't like changing state very often so I found that to be ok.  I imagine you have written your own stack functions right ?

56

Re: OpenGL ES

Lazrhog wrote:

Am I about to lose my credit for the OpenGLES port on the main neverball page ?   wink

I don't see where anyone is getting credit for GLES.  You're credited for the iPhone/iPod Touch port, which is certainly not in dispute.

Lazrhog wrote:

one of the main issues I found was state management.  In the end I decided to have a base setup and then deviate and put back when necessary (as you already know rlk).  The mobile devices don't like changing state very often so I found that to be ok.  I imagine you have written your own stack functions right ?

Your approach is a good one.  You define a "default" state and undo any divergences from it.  In the case of the SOL renderer, the mtrl application function already did a good job of comparing and minimizing state changes during display list creation.  I've let that remain, except now it runs every frame.

57

Re: OpenGL ES

In other news, the GUI rewrite is finished.  I was able to collapse all geometry down to a single VBO, using sub-data updates every time the GUI changes.  This is nice, though the actual GUI rendering process still has to use a large number of small calls to glDrawArrays, which is a bit inefficient.  Anyway, it's better than it was.

I also rewrote every mtrl file.  The flag property flags were given as an integer value, and I changed it to a list of strings.  For example, the "glass" material used to have a line that just said "10".  Now it says "environment shadowed transparent".  The idea here is that now we can add, remove, modify, or reorder the actual flag bit values without having to recompute all of the material files.

Also I added, removed, modified, and reordered some of the material flag bit values.

Now I'm gonna look into the particle system.

58

Re: OpenGL ES

Wow, we are going to have to rewrite the whole wiki for our next release. Fantastic stuff.

59

Re: OpenGL ES

rlk wrote:
Lazrhog wrote:

Am I about to lose my credit for the OpenGLES port on the main neverball page ?   wink

I don't see where anyone is getting credit for GLES.  You're credited for the iPhone/iPod Touch port


Err I was completely joking about that.  Sorry lol smile.  I have no interest in credit.  I was just implying how close you are to finishing.  Would love to see a video running if you have time.

60

Re: OpenGL ES

Lazrhog wrote:

Err I was completely joking about that.  Sorry lol smile.  I have no interest in credit.  I was just implying how close you are to finishing.  Would love to see a video running if you have time.

Oh, I know you're joking.  But I do take crediting seriously!

As of right now, the GLES branch is visually indistinguishable from the trunk.  The output is exactly the same.  That'll probably change soon though, as I try to find a more mobile-friendly way of drawing particles.

61

Re: OpenGL ES

rlk wrote:

I also rewrote every mtrl file.  The flag property flags were given as an integer value, and I changed it to a list of strings.

Great, I've wanted to do this for a while, too. Decimal bit masks are kinda hard to read...

62

Re: OpenGL ES

RLK, the screen resolution for the Wiz is only 320x240 -- are there any built in optimizations to perhaps lessen the GPU/CPU load with such, or is this handled by OpenGL? I would have thought that smaller res textures, and reduced bit accuracy would greatly enhance performance -- sorry for breaking my own ban...

Currently Playing:
Celeste and Electronic Super Joy

63

Re: OpenGL ES

themacmeister wrote:

RLK, the screen resolution for the Wiz is only 320x240 -- are there any built in optimizations to perhaps lessen the GPU/CPU load with such, or is this handled by OpenGL? I would have thought that smaller res textures, and reduced bit accuracy would greatly enhance performance -- sorry for breaking my own ban...

There's nothing built-in to the engine or the GL to take advantage of a low-res screen.  Smaller textures and lower bit depth are indeed the best bet for improvement, though we would need to know where the bottleneck is to be certain.  The first rule of GL optimization is: there's always ONE weakest link.  Do you have a sense of the balance of that device?  Do you know if it's largely CPU limited, vertex limited, or pixel limited?

64

Re: OpenGL ES

I've been working on simplifying the particle mechanism.  As part of this, a couple of things that used to be particle effects are now texture effects.  This stuff is subject to change, of course, and in fact it's all defined in terms of images and OBJs, so anyone with 3D modelling experience can now help define the look of the elements.

For now, the teleporter has a kind of random spiral thing that looks like the transporter in the new Star Trek movie.

http://snth.net/~rlk/jump.jpg

The goal has beams of light shooting out of it, slow toward the outside, faster toward the inside.

http://snth.net/~rlk/goal.jpg

As with most things, a screenshot doesn't capture the motion of it.

This is the first change I've made the the GLES branch that actually modifies the look of the game.  It's necessary under the circumstances, so to account for this, the new mechanism is much more flexible.

And now to actually work on the particle renderer...

parasti, I don't understand what the part_lerp mechanism does.

65 (edited by parasti 2011-04-01 17:53:04)

Re: OpenGL ES

rlk wrote:

parasti, I don't understand what the part_lerp mechanism does.

It implements particle interpolation, but I guess you figured as much. This is pretty much the same setup that I used for interpolating everything else but less streamlined, I guess, as I never spent much time on it other than getting it to work.

part_lerp holds interpolatable particle state for current and previous update. On each step the current state is copied into previous state and then itself is moved forward by the simulation. On rendering these two states are interpolated and result is stored ("applied") in the non-lerp part structure, which is what actually gets displayed.

The confusing thing is probably that part_lerp contains nothing BUT the interpolatable state, i.e., particle position. Angular and linear velocities and such are still in the non-lerp structure and the code cheerfully uses both structures at the same time. Also, the application happens outside of share/part.c, in ball/game_draw.c.

66

Re: OpenGL ES

parasti wrote:

It implements particle interpolation, but I guess you figured as much. This is pretty much the same setup that I used for interpolating everything else but less streamlined, I guess, as I never spent much time on it other than getting it to work.

part_lerp holds interpolatable particle state for current and previous update. On each step the current state is copied into previous state and then itself is moved forward by the simulation. On rendering these two states are interpolated and result is stored ("applied") in the non-lerp part structure, which is what actually gets displayed.

The confusing thing is probably that part_lerp contains nothing BUT the interpolatable state, i.e., particle position. Angular and linear velocities and such are still in the non-lerp structure and the code cheerfully uses both structures at the same time. Also, the application happens outside of share/part.c, in ball/game_draw.c.

So it's necessary... during replay playback?  I guess?

What I'm facing here is this: I need to put the particle position and color in a VBO, but because the contents of that VBO will change frequently I want to keep it small.  The particle's age and angular and linear velocities aren't needed for drawing, so I want to split the particle structure into _draw and _base structures.  I should be able to get that done without disturbing the lerp mechanism.

If you approve of the direction I've gone with the jump and goal particles, I'll probably just hack out all the jump and goal stuff in part.c.  What do you think?

67

Re: OpenGL ES

rlk wrote:

So it's necessary... during replay playback?

It's necessary everywhere. But yes, it is most noticeable when watching replays at half-speed.

What I'm facing here is this: I need to put the particle position and color in a VBO, but because the contents of that VBO will change frequently I want to keep it small.  The particle's age and angular and linear velocities aren't needed for drawing, so I want to split the particle structure into _draw and _base structures.  I should be able to get that done without disturbing the lerp mechanism.

This makes sense. That interpolation method I described should fit naturally in there (store the state trail in base, apply to draw).

If you approve of the direction I've gone with the jump and goal particles, I'll probably just hack out all the jump and goal stuff in part.c.  What do you think?

From what I've seen interpolation doesn't concern these, right? You're not lockstepping but using SDL_GetTicks for animation. I don't have a problem with these. Could look better, but what needs to be done, needs to be done.

68

Re: OpenGL ES

parasti wrote:
rlk wrote:

So it's necessary... during replay playback?

It's necessary everywhere. But yes, it is most noticeable when watching replays at half-speed.

Could you explain why?

69 (edited by parasti 2011-04-01 19:21:21)

Re: OpenGL ES

rlk wrote:

Could you explain why?

Why is interpolation necessary? Or particle interpolation specifically? My answer to both is pretty much the same. Stuff moving across the screen in discrete jarring steps looks terrible. Interpolation makes stuff move smoothly.

If you're looking for a demonstration of why interpolation is a good thing, try toggling it in-game. Bind a key to temporarily force lerp alpha to 1.0 in game_draw and compare the results for yourself. Spin the camera around and look at the sky or something. If that won't convince you of the usefulness of it, I really don't know what to tell you. tongue

70

Re: OpenGL ES

Oh right, I recall this now.  Some of you maniacs don't believe in vertical blanking interval synchronization.  Ok, I'll try not to break it.

71

Re: OpenGL ES

That would be great, thanks. (Also I am not one of those maniacs. Vsync is the first setting I will enable in any game, right after checking the resolution. Image tearing is unbearable otherwise. But a game running at 90 updates per second on a screen refreshing at 60 frames per second does not a smooth experience make - without interpolation at least. That is all.)

72

Re: OpenGL ES

rlk wrote:

Oh right, I recall this now.  Some of you maniacs don't believe in vertical blanking interval synchronization.  Ok, I'll try not to break it.

This discussion is unreal.

In Neverball 1.4.0, simulation updates were coupled to the screen refresh rate. Running at 60Hz meant jittery physics and unreliable replays. Turning off vertical synchronization was a way of getting around that, which is why it was preferred by some at the time. The higher the FPS, the lower the differences between adjacent fractions of the displayed image, minimizing the effect of image tearing.

Compared to 1.4.0 running at 60Hz, lockstep reduced the jitter somewhat and (eventually) allowed for robust replays. From day one, though, it had stuttering graphics, regardless of the vsync setting. While an NVIDIA driver issue added to the judder, the core problem was the lack of interpolation. It quickly became clear that you have to bridge the gap between the differing screen and simulation update rates, as recommended in Glenn Fiedler's article. How anyone could claim to experience smooth movements without this is beyond me. This goes double for the arbitrary update rates of the new replay speed control feature.

And in case it's in question, this "maniac" has been running in vsync mode ever since February 2009, and it was precisely the creation of a new codebase built for interpolation that allowed me to do that.

[...] This organization dates all the way back to Super Empty Ball, the earliest versions of which had 14 lettered structures.  Recognizing this system’s growing complexity, Parasti refactored it all into subsets of structures for static level state, dynamic level state, and rendering.

I have no doubt that parasti recognizes complexity where he sees it and does the right things about it. However, it is obvious that the purpose of this specific change was to allow for the subsequent addition of game state interpolation, after suggesting it right when the fixed timestep was introduced and later describing it as something that "Neverball must do". In the end it may have taken three years for this to be fixed in the Neverball trunk, and by now it may no longer affect me personally, but I applaud parasti for doing it.

73 (edited by parasti 2011-04-02 11:09:12)

Re: OpenGL ES

Three years? Well, this is embarrassing... This means I have spent 2 years and 11 months procrastinating, and 1 month implementing it.

But this is an appropriate correction, the purpose for that change was to enable interpolation. It is worth mentioning that Elviz implemented that same mechanism in Nuncabola long before I did it in Neverball. I'll go on record admitting that I stole the "base" naming convention from Nuncabola... I didn't steal anything else, I swear. Please don't hurt me.

Ahem.

However it may have been, let's cut the off topic here.

74

Re: OpenGL ES

Hey Elviz, sorry I didn't credit you for the split-up of the data structure.  I could not have known that you did it in a fork of the project.

75

Re: OpenGL ES

Frig, frak! Looks like my Android phone does not support the ARB_multitexture extension; so I am getting a very hard crash in solid_draw line 83 which tries to manipulate glActiveTexture_ (which is never set).

Not sure if this will be accounted for in your code, rlk. Maybe a graceful exit at minimum? I'll try to implement a workaround on my end and see if that can get  accepted as a patch. Otherwise maybe I need a new testing device.