Makin' Mah Mmo

[Eniko]

So. Floats and stuff. Since the game uses OpenGL I am using quite a bit of floats, for texture coordinates, colors, and vertices. Should I be worrying about a sudden drastic decrease in performance on the Pandora because I use floats? I've tried to glean the answer to this from the many other float-oriented threads, but they seem a bit too theoretical for my tastes.

 

[God Ginrai]

So. Floats and stuff. Since the game uses OpenGL I am using quite a bit of floats, for texture coordinates, colors, and vertices. Should I be worrying about a sudden drastic decrease in performance on the Pandora because I use floats? I've tried to glean the answer to this from the many other float-oriented threads, but they seem a bit too theoretical for my tastes.

Well, in general, float always tends to slow things down on an embedded device. However, I believe we have some way to handle some floating point on the Pandora at a decent speed, so it might not be too much of a slow down.

-God Ginrai

 

[Butterman]

So. Floats and stuff. Since the game uses OpenGL I am using quite a bit of floats, for texture coordinates, colors, and vertices. Should I be worrying about a sudden drastic decrease in performance on the Pandora because I use floats? I've tried to glean the answer to this from the many other float-oriented threads, but they seem a bit too theoretical for my tastes.

If you're mainly using them, say passing them to a drawing function, not actually doing any maths with them, (trigonometry, etc). You should be fine. I can't imagine why you would be doing anything like that on the client, right?

 

[Eniko]

If you're mainly using them, say passing them to a drawing function, not actually doing any maths with them, (trigonometry, etc). You should be fine. I can't imagine why you would be doing anything like that on the client, right?

There's very little floating point math, correct. I do a tiny bit of floating point math to calculate texture coordinates for sprites and another tiny bit of multiplication of alpha values in the GUI, I do a bit more math (only division and multiplication still) for moving entities in the game around, but still nothing shocking, so that's really the only thing that could slow down. And even then that routine has a variable that indicates how often movement is calculated, so if there is slowdown I guess I can set that higher for the Pandora.

Most of the time I'm only using the struct module for packing floats into binary data to pass to OpenGL as pointers.

So I guess this likely isn't of any concern to me. Thanks.

 

[Butterman]

If you're mainly using them, say passing them to a drawing function, not actually doing any maths with them, (trigonometry, etc). You should be fine. I can't imagine why you would be doing anything like that on the client, right?

There's very little floating point math, correct. I do a tiny bit of floating point math to calculate texture coordinates for sprites and another tiny bit of multiplication of alpha values in the GUI, I do a bit more math (only division and multiplication still) for moving entities in the game around, but still nothing shocking, so that's really the only thing that could slow down. And even then that routine has a variable that indicates how often movement is calculated, so if there is slowdown I guess I can set that higher for the Pandora.

Most of the time I'm only using the struct module for packing floats into binary data to pass to OpenGL as pointers.

So I guess this likely isn't of any concern to me. Thanks.

You know, you can avoid using floats for colors? If you use glColor4ub (which is available in ES), you just pass integers from 0 - 255, I don't know if this is going to hurt your colors, if you're actually using the precision or not, but it could be a good place to start cutting down, even though I'm not sure it will make a difference at all.

 

[Eniko]

I'll keep that in mind if I run into issues on the Pandora.

Another quick question... I just implemented font rendering which draws a quad per letter. Using a ~1200 characters long "lorem ipsum" string, on 3 windows (so 3600 characters or 14.4k vertices) the FPS drops from over 300 to 150 or less. So I guess I'm hitting some GPU/OpenGL wall here, but I figured I should be able to display waaaay more vertices than that before running into issues. With colors and texture coordinates that's more like 43,000 though.

Am I being naive? Or is it a result of using vertex arrays versus VBOs and having to set the pointers every frame, thus having to upload large amounts of data over CPU into the GPU? For reference my GPU is a Geforce 8800 GTS 320mb.

 

[darkblu]

I'll keep that in mind if I run into issues on the Pandora.

Another quick question... I just implemented font rendering which draws a quad per letter. Using a ~1200 characters long "lorem ipsum" string, on 3 windows (so 3600 characters or 14.4k vertices) the FPS drops from over 300 to 150 or less. So I guess I'm hitting some GPU/OpenGL wall here, but I figured I should be able to display waaaay more vertices than that before running into issues. With colors and texture coordinates that's more like 43,000 though.

Am I being naive? Or is it a result of using vertex arrays versus VBOs and having to set the pointers every frame, thus having to upload large amounts of data over CPU into the GPU? For reference my GPU is a Geforce 8800 GTS 320mb.


in brief - yes (to answer your arrays vs VBOs question, not the naive part - you don't seem naive at all : )

ps: i'm seriously considering using 'VBOs are your friend ™' as a signature on these boards. VBOs are the better transport abstraction - thay have all the power of vertex arrays and none of their weaknesses. and are darn easy to implement too.

 

[Eniko]

I guessed as much. Guess I'll have to graduate from vertex arrays and move on to VBOs sometime when I get around to optimizing the rendering system. Not for now though, early optimization being the devil and all that.

Will that amount of stuff even hold up on the Pandora though? Or should I start thinking about prerendering text into textures instead? But then that would take a lot of RAM. Plus it's icky and complex so I'd rather get away with a quad-a-letter approach.

 

[Butterman]

I guessed as much. Guess I'll have to graduate from vertex arrays and move on to VBOs sometime when I get around to optimizing the rendering system. Not for now though, early optimization being the devil and all that.

Will that amount of stuff even hold up on the Pandora though? Or should I start thinking about prerendering text into textures instead? But then that would take a lot of RAM. Plus it's icky and complex so I'd rather get away with a quad-a-letter approach.

I think if you were drawing letters with VBOs or even better, shaders, you would get pretty good performance on the Pandora. That said, if you just texture mapped a quad with a single letter, then drew this via a shader or VBOs the performance would be crazy. You would only have to load your transparent letters at load time and make sure alpha data is working properly (PNGs via SDL_Image integrate into OGL really well) then activate alpha blending. There, you've got sharp text at the cost of a few quads.

Right now in TINCS I'm just doing text by making letters in GL_LINES, It's running great on the legacy hardware I have at home for testing h34r:

 

[darkblu]

I think if you were drawing letters with VBOs or even better, shaders, you would get pretty good performance on the Pandora. That said, if you just texture mapped a quad with a single letter, then drew this via a shader or VBOs the performance would be crazy.

pardon me if i'm wrong, but i get the impression from the above that you consider VBOs and shaders as some sort of alternatives.

VBOs are nothing more than an efficient transport mechanism to get your vertex data (that includes indices too) from client's GL (read: you app) to server's GL (read: drivers) domain. that's all. whether you use shaders or not is unrelated.

 

[Eniko]

I think if you were drawing letters with VBOs or even better, shaders, you would get pretty good performance on the Pandora. That said, if you just texture mapped a quad with a single letter, then drew this via a shader or VBOs the performance would be crazy. You would only have to load your transparent letters at load time and make sure alpha data is working properly (PNGs via SDL_Image integrate into OGL really well) then activate alpha blending. There, you've got sharp text at the cost of a few quads.
Well that's what I'm already doing. I'm just wondering if that might be too many quads for the Pandora to handle? But I'm probably too worried there. If it is a problem though the first solution that comes to mind is to render all the text, character by character, into a render target texture. Then from then on it'd be a single quad to draw all the text to the screen.

Of course if the Pandora can handle the way I'm doing it now I'd much prefer to keep it that way.

 

[gahndalf]

Hey Eniko just wanted to see if you were making any headway. Looking forward to seeing this on my Pandora.

 

[lulzfish]

You could try something like this:

Have a single set of 4 vertices representing the size of one character
Write a vertex shader to automatically generate the texture coordinates for each letter [I'm assuming you have the alphabet all in one big texture?] based on a uniform variable.
Use a regular pixel shader.

I'm not sure how fast uniforms are, but if you can pass a single set of vertices to the shader with a uniform rather than a different set of vertices and texture coordinates every time, it should speed something up, since the vertex processor will be doing all the math of locating a letter within the texture, rather than the CPU.

 

[Eniko]

Hey Eniko just wanted to see if you were making any headway. Looking forward to seeing this on my Pandora.

Still making progress. Just not a whole lot of visible stuff right now.

I should point out that I mostly just make a few large updates here and talk about actual development stuff. Right now the best source of updates for my project specifically is probably my Twitter account at twitter.com/enichan since any progress I make right now can probably be summed up in less than 100 characters so I don't feel right posting about it everywhere.

Also, can vertex shaders generate vertices that weren't put there by the software?

 

[lulzfish]

no, vertex shaders can only transform vertices you've already sent to the graphics card.
Geometry shaders can add and remove vertices, but they're very advanced, mostly restricted to high-end gaming cards, and certainly way out of the Pandora's league.

EDIT:
From what I've heard, you're drawing text by making each character an individual quad and generating separate texture coordinates to change which character is drawn from a texture containing all possible characters.
If you're doing something different, then the crazy vertex shader trick below might not apply.

But I think sending the same set of vertices and changing a uniform on the vertex shader for each quad will be noticeably faster than moving texture coordinates around manually on the CPU and re-sending the vertex array / VBO each time

I'm not sure if I was clear enough the first time, here's some pseudocode:

Vertex shader:
uniform character;
texcoord_u += [crazy math to calculate X offset of that character];
texcoord_v += [crazy math to calculate Y offset of that character];
vertex = {x, y, z, w, color, texcoord_u, texcoord_v};

Pixel shader:
fragmentcolor = texturelookup (texcoord_u, texcoord_v);
// I think OpenGL has something called fixed function shader, which is basically the same as OpenGL's default shader. This would work fine too, if ES supports it. [Obviously it would still be a shader, but it's a function called fixed_fragment_shader or something like that]

game code:
VBO char_quad = {A quad of the desired size with texture coordinates equivalent to the first character in your texture map}
for each character {
set uniform character = char_array ;
draw_vbo char_quad;
}

See, this way you move all the transforming to the GPU and save the CPU from doing some useless, repetitive algebra. Also, the GPU only has to remember one set of coordinates, which I think will be a lot faster than sending different vertices for each character.

 

[Butterman]

I really cant see you having any problems with textured quads. Let's say you have like 1000 sprites being drawn at once. That's only 4000 polygons.

You should even be able to do mad float math on the Pandora without problem. It is quite slow at floating point, but that really can't apply unless you're doing a good lot of floating point trig each frame. Which I can't see you doing?

It's really a non-issue.

Also, I don't see any updates on your twitter?

EDIT: Just read about the font stuff, I see your problem

If you use SDL_ttf, it just creates one large SDL_surface out of the input text (rather than lots of small ones), it's really painless converting a SDL_surface into a gl texture.

 

[Eniko]

Oh, I see what you're getting at lulzfish. Still, it might be slow because setting the uniform (that's a shader variable right?) has to go from Python, through PyOpenGL, be converted, then pushed into the GPU as well. If done from C I'm sure this wouldn't be a problem, but from within Python it might be.

However I'll certainly keep this approach in mind when it comes time to optimize.

Butterman: It's not about polygon counts, and I'm only using SDL_ttf for generating an OpenGL texture containing the font, it's about the amount of data pushed across the CPU to the GPU. A string 500 characters long needs 500*4*3 bytes for vertices. Then it needs 500*4*2 for texture coordinates. Then it needs 500*4*4 for vertex colours. If using outter glow then you need another 500*4*4 bytes for vertex colours.

So it becomes Bytes = CharCount * 52

And uploading all that data is what's slowing things down, with large strings or multiple windows of text.

 

[lulzfish]

Well if you don't mind the effort of adding that to a vertex shader, you would only be sending the one uniform to the GPU instead of updating texture coords for each vertex.

as for Python, I think you're always going to have problems with slowness. It's inherent.

 

[Eniko]

Well I just found out that apparently OpenGL ES 1.1 only supports fixed function and no shaders whatsoever, so this means that I'll probably have to rewrite everything for OpenGL ES 2.0. Another setback, le sigh.

 

[Phawx]

I understood everything up until the last part. Is that French?