Sprite fucking up

[N64vSNES]

Could it be a problem with the image height and width? - I remember a similar problem with OpenGLES, it wouldn't calculate the image size accurately which caused problems with the UV coordinate calculation. I was using integers to refer to tile number X and Y, then working out the UV coordinates from that.

I don't think I'm explaining this right :/

The potion size is 32x32.
The map tileset is 512x512.
I'm rendering the potion but the map tileset gets rendered.
However the map tileset is being rendered at 32x32.

This must mean that it was loading correctly but the wrong texture is getting selected by OpenGL when I call glBindTexture()

[Van-B]

Ahh, so it's hard-coded then? (resolutions I mean). I've only used OpenGLES on iOS, so I'm probably no help.

Incidently, how come your not using a triangle list... like adding all your items from the tile set as a single draw call?

[N64vSNES]

Ahh, so it's hard-coded then? (resolutions I mean). I've only used OpenGLES on iOS, so I'm probably no help.

Incidently, how come your not using a triangle list... like adding all your items from the tile set as a single draw call?

They can be scaled but they are assigned to their default resolution when they're loaded. Triangle list? Draw call? O_o

[TheBuzzSaw]

Incidently, how come your not using a triangle list... like adding all your items from the tile set as a single draw call?

Admittedly, I'm not too sure what you're referring to either. Elaborate?

[Van-B]

Sorry, my terminology is probably all to hell, it's been a while since I did anything with OpenGL (finalising game design before finishing it). Anyhoo, with GLES there are a few different mesh construction methods - which I'm sure your aware of. A standard sprite may use just 4 indices in a vertice, coordinate, and colour arrays. Then this sprite might set those array values as part of a draw function. Alternatively, I tend to use triangles, which have a bigger array, with enough indices for however many sprites I need. Then those sprites are created on the same 'mesh', each mesh of triangles being restricted to a single texture. I have the vertice, coordinate, and colour arrays as part of my sprite class with counter variables, so I add pairs of triangles then render the lot.

From what I gather, you are using a draw call for each sprite? - like your potion sprites would be drawn individually, no matter how many potions there are?

Because your using a tile sheet, I think it makes sense to build the triangle mesh from all the sprites that use that texture. I found massive performance increases when doing this on the iPhone. But it's probably something your already doing with the map itself, making a big mesh, or series of meshes for the map layer. I'm not sure how I would deal with characters going in front and behind items - that is always tricky, more so when trying to optimise meshes. I'm lucky in that in my project the draw order is fairly automatic - it's a puzzle bubble type game, so I draw the backdrop, then the map, then the moving pieces - but the map and moving pieces use the same texture so it's quite straightforward in my case.

The weird sizing bug, I think was due to texture.pixelsWide and texture.pixelsHigh returning the wrong values, swapped out for [ texture GetRealWidth ] etc which seems to have fixed it for some reason. OpenGLES is something I tend not to mess around with once it starts working properly.

[N64vSNES]

Sorry, my terminology is probably all to hell, it's been a while since I did anything with OpenGL (finalising game design before finishing it). Anyhoo, with GLES there are a few different mesh construction methods - which I'm sure your aware of. A standard sprite may use just 4 indices in a vertice, coordinate, and colour arrays. Then this sprite might set those array values as part of a draw function. Alternatively, I tend to use triangles, which have a bigger array, with enough indices for however many sprites I need. Then those sprites are created on the same 'mesh', each mesh of triangles being restricted to a single texture. I have the vertice, coordinate, and colour arrays as part of my sprite class with counter variables, so I add pairs of triangles then render the lot.

From what I gather, you are using a draw call for each sprite? - like your potion sprites would be drawn individually, no matter how many potions there are?

Because your using a tile sheet, I think it makes sense to build the triangle mesh from all the sprites that use that texture. I found massive performance increases when doing this on the iPhone. But it's probably something your already doing with the map itself, making a big mesh, or series of meshes for the map layer. I'm not sure how I would deal with characters going in front and behind items - that is always tricky, more so when trying to optimise meshes. I'm lucky in that in my project the draw order is fairly automatic - it's a puzzle bubble type game, so I draw the backdrop, then the map, then the moving pieces - but the map and moving pieces use the same texture so it's quite straightforward in my case.

The weird sizing bug, I think was due to texture.pixelsWide and texture.pixelsHigh returning the wrong values, swapped out for [ texture GetRealWidth ] etc which seems to have fixed it for some reason. OpenGLES is something I tend not to mess around with once it starts working properly.

Thanks for the tip, I'm going to look further into this

[Falco Girgis]

Sorry, my terminology is probably all to hell, it's been a while since I did anything with OpenGL (finalising game design before finishing it). Anyhoo, with GLES there are a few different mesh construction methods - which I'm sure your aware of. A standard sprite may use just 4 indices in a vertice, coordinate, and colour arrays. Then this sprite might set those array values as part of a draw function. Alternatively, I tend to use triangles, which have a bigger array, with enough indices for however many sprites I need. Then those sprites are created on the same 'mesh', each mesh of triangles being restricted to a single texture. I have the vertice, coordinate, and colour arrays as part of my sprite class with counter variables, so I add pairs of triangles then render the lot.

Well, goddamn! I had actually never considered that. You are most certainly gaining quite a bit of performance by NOT rendering each tile as its own individual textured quad, because you can save on the expensive operation of setting a texture. With ES, we're definitely setting the texture once during the rendering of the tile layers, but we're also rendering each individual tile as its own polygon... I had never considered rendering the tiles all as a single triangle mesh... Wow... Great idea! I have no idea what the performance increase will be, but I'm guessing it will definitely be better. Not only that... but we could just as easily try this method on the Dreamcast/PSP and see what the increase is like on those architectures... I am excite!

edit: Also, the Dreamcast (and maybe PSP?) only renders triangle strips anyway. So you really aren't even using any more space for the vertices.

I'm not sure how I would deal with characters going in front and behind items - that is always tricky, more so when trying to optimise meshes.

Even if this is an issue, tile-based engines usually have multiple tile "layers" for handling render order. Each of these layers could be a single mesh, with the objects/entities being rendered as a individual quads/polygons with their own individual render calls afterwards...

Thanks for the awesome idea, Van-B! I was actually working on optimizing a lot of the rendering on the other platforms before the next video. Perfect timing!

[N64vSNES]

Okay if you've impressed Gryo you've definitely impressed me

I've fixed this issue thanks guys, I have no idea what I did. Perhaps I just needed a reboot?

[Van-B]

WOW! - I posted something useful about OpenGLES!... it's a first for me :D - I'm actually still working on my first C++ OpenGLES project.

One thing about the maps and this technique is that you could potentially save tons of performance, because you could store the map mesh in the class array (colours, vertices etc) when switching scenes, then just redraw it without re-setting the arrays (for animated tiles, you could just sneak in there and adjust the coordinates array). That's what I intend to do on my next project, have maybe 16x16 tile meshes (themselves as a 2D array) then only draw the meshes that are visible each time. For particles, well there's too many benefits to even mention - it gets rid of so many hassles when managing particle media, I'll never use a point sprite again.... well maybe just for a starfield.

[TheBuzzSaw]

GyroVorbis, please tell me you're not using glBegin/glEnd...

[Falco Girgis]

GyroVorbis, please tell me you're not using glBegin/glEnd...

As much as I hate to admit it, we ARE.

Honestly, with ES, I'm almost NEVER screwing with OpenGL. When I got things set up and rendering (a long ass time ago), that stuff was pretty much all abstracted away from anywhere near where I've been working (in LibGyro). Combine that fact with the fact that I'm on a PSP and Dreamcast pretty much just as often as I'm screwing with OpenGL, and yeeeeeaaaah...

I definitely need to clean up some of the shit we're doing with OpenGL (immediate mode). It's super easy to get lazy, because 1) it works fine 2) we can fix it at any time without affecting anything, since it's abstracted away 3) Performance has never been an issue on Windows/OSX/Linux, so all of my time is spent optimizing other builds.

Feel free to tear me a new one for that. :D

[TheBuzzSaw]

As much as I hate to admit it, we ARE.

Honestly, with ES, I'm almost NEVER screwing with OpenGL. When I got things set up and rendering (a long ass time ago), that stuff was pretty much all abstracted away from anywhere near where I've been working (in LibGyro). Combine that fact with the fact that I'm on a PSP and Dreamcast pretty much just as often as I'm screwing with OpenGL, and yeeeeeaaaah...

I definitely need to clean up some of the shit we're doing with OpenGL (immediate mode). It's super easy to get lazy, because 1) it works fine 2) we can fix it at any time without affecting anything, since it's abstracted away 3) Performance has never been an issue on Windows/OSX/Linux, so all of my time is spent optimizing other builds.

Feel free to tear me a new one for that. :D

For shame, Falco. FOR SHAME.

At least put the static stuff into a Display List. Geeeez...

[Milch]

GyroVorbis, please tell me you're not using glBegin/glEnd...

As much as I hate to admit it, we ARE.

Shame on you! D:
(Seriously, fix that and show it in the next video!)

[Falco Girgis]

GyroVorbis, please tell me you're not using glBegin/glEnd...

As much as I hate to admit it, we ARE.

Shame on you! D:
(Seriously, fix that and show it in the next video!)

Show what? It already runs at 99999fps on any PC worth a damn. I would think assembly optimizing Dreamcast and PSP transforms and rendering to use SIMD instructions on the CPU and the vector units with a NOTICEABLE performance increase would be more worth my time... (and more fun)...

It's just one of those things I'll get around to... some day.

[N64vSNES]

GyroVorbis, please tell me you're not using glBegin/glEnd...

As much as I hate to admit it, we ARE.

Shame on you! D:
(Seriously, fix that and show it in the next video!)

Show what? It already runs at 99999fps on any PC worth a damn. I would think assembly optimizing Dreamcast and PSP transforms and rendering to use SIMD instructions on the CPU and the vector units with a NOTICEABLE performance increase would be more worth my time... (and more fun)...

It's just one of those things I'll get around to... some day.

Yeeeeeeeeeaaaaaaaaaaaaaaaah.

Some unsuccessful programmers without a regular cash income would like to play ES aswell >:[