Optimizing Astromenace

[dbluelle]

Hello,


I've ported Astromenace to the Pandora (see https://github.com/d...ora-astromenace ).


The game basically runs with a few graphical glitches ( the starfield is not rendered correctly). B)


As it's very sloooow (5-10 fps maximum), what is the best approch to optimize it?


- I've done the port with opengl-es 1.1. Will porting to opengl-es 2.0 be better?


- Google says that converting the glVertexPointer/glTexCoordPointer calls to using GL_SHORT


increases performance on the IPhone, maybe that will help on the Pandora, too.


(Converting the calls will be a relatively big task, so I thought I'd better ask first if this will be worth a try).


- Are there any tricks in SDL which may help?


Does anyone have other suggestions?


I'm new to opengl programming, so any help is welcome.


Thanks in advance,


dbluelle

 

[slaeshjag]

If you're using 32bpp textures, converting them to 16bpp will probably give you a boost.


Make sure blending isn't enabled where you don't need it.

 

[mcobit]

This was already ported by sebt3 but his port had the same speedproblems.


You could also try to deactivate texturefiltering by setting GL_LINEAR or something for the textureloadingcommand.


Edit: or was it GL_NEAREST? I don't know anymore.


What really helped for Polly-Be-Gone was reducing the texturesize a lot.

 

[slaeshjag]

GL_NEAREST should be faster.

 

[sixtyfifthbit]

This was already ported by sebt3 but his port had the same speedproblems.
You could also try to deactivate texturefiltering by setting GL_LINEAR or something for the textureloadingcommand.


Edit: or was it GL_NEAREST? I don't know anymore.


What really helped for Polly-Be-Gone was reducing the texturesize a lot.

In a similar vein, take advantage of the fact that the display size will likely be locked at 800*480 (or, at least, be no larger than) - using high-resolution textures (especially if they're larger than the screen!) would be a waste.

Note also, the specs are for a 1 GHz Pentium - it might just have too much going on. At least, optimization may not be simple...

 

[dbluelle]

Thanks for all the tips.

I've experimented with some of the stuff, but haven't found anything that really boosts performance.

It's currently 10-15 fps while displaying around 25000 triangles per frame.

So far I've tried:

- Reducing texture width and height by 1/2 or 1/4 does lead to around 1-2 fps more.

- convert textures to RGBA4444 or RGB565 format

- use GLshort instead of GLfloat vertices in places where it was easy to apply.

- played around with neon-optimized code (see http://code.google.com/p/math-neon/ )

- tried using SDL_VIDEODRIVER=omapdss, but I couldn't get it running ("EGL Error: unable to get SDL window handle")

I still have a few questions:

- How can I check for the bottleneck methods directly on the pandora?

- The astromenace process is using about 70 to 80% of the cpu most of the time, is that "normal" or is it a sign that it is _not_ the opengl code which is the bottleneck?

- I haven't figured out how to use the opengl extensions provided by the driver (e.g. glGetString(GL_EXTENSIONS) claims it supports "GL_OES_framebuffer_object", but the method "glGenRenderbuffersOES" is not found in the library).

Thanks for any suggestions,

dbluelle

 

[mcobit]

If you have 70-80% cpuusage, it might not be cpulimited as I have seen higher usage at full load.


Notaz SDL doesn't work with gles apps.


You could try to overclock the sgx/ram and see if that makes a difference.


Good luck. I would like to see this game playable.

 

[notaz]

To measure performance you could use profiling tools like perf or oprofile.

If you are running in window, GL seems to have large overheads, it's worth to try going fullscreen.

 

[rohezal]

You can disable the rendering code and just test how fast the game runs without using the gpu. Then enable parts of the rendering code (maybe make a level just to test it). This maybe helps you to find the big calculation time takers. And maybe you find a improvement for them

 

[crow_riot]

was just looking on the code _a bit_. is the shadowmap active? if so, you could try deactivating that (within DrawAllObject3D that is) ...

the opengl specific stuff seems to be optimized quite well using buffer objects where applicable.

probably the geometry is just too detailed? it would be interesting to know how many triangles are drawn per frame.

 

[dbluelle]

is the shadowmap active? 

No, as most of the opengl extensions are not detected on initialization, the whole shadowmap stuff is not used.

the opengl specific stuff seems to be optimized quite well using buffer objects where applicable.

Yeah, but sadly buffer object support is also not detected on startup.

As I've said previously,  I haven't figured out how to use the opengl extensions provided by the driver.

probably the geometry is just too detailed? it would be interesting to know how many triangles are drawn per frame.

On the main menu screen it's normally about 20000 to 25000 triangles per frame.

Some more numbers: (just showing main menu with sound disabled)

- normal: ~ 14 fps / 23000 triangles

- without star system: ~ 18 fps / 20000 triangles

- without 3d objects : ~ 30 fps / 1600 triangles

- without 3d objects and star system: ~ 82 fps / 330 triangles

- only render fps display: 182 fps / 80 triangles

 

[notaz]

Is this on classic/rebirth or 1GHz unit?

You could try overclocking/underclocking the CPU and see how it affects things. If it has a lot effect then there is probably something slow in software, if not then it's probably GPU limited.

 

[dbluelle]

I hadn't thought of that...

The tests were done on a rebirth unit at 600 MHz.

Going to 800 MHz doesn't make any noticable difference on all of the tests.

 

[viewizard]

dbluelle, I don't have pandora (yeah, I know, this is pandora forum, don't kill me pls :lol: ), but... I have several ideas you might check.

1) Make sure that VBO supported, detected and used, or this kill your FPS by permanent system bus loading with ships geometry. (check console output for “Vertex Buffer support enabled.” line). You can test VBO work by comment “#define vbo” line in config.h file.

2) All particle systems don't use VBO feature at all. This mean, all particle systems data use system bus all the time. Play with “vw_DrawAllParticleSystems();” line in “void DrawAllObject3D(int DrawType)” function (Object3D/Object3DManager.cpp file), and see what will happen with game FPS.

3) Is FBO feature detected on pandora?(check console output for “Frame Buffer Object support enabled.” line) If yes – you can test work with libSDL framebuffer only, without FBO, by comment “#define fbo” line in config.h file.

Btw, what game options you are using (point lights, visual effects quality, etc)?

 

[dbluelle]

Well, all the needed opengl extensions are not detected :wacko:  .

 


The OpenGL extensions supported by the SGX are (according to glGetString(GL_EXTENSIONS)):

GL_OES_byte_coordinates

GL_OES_fixed_point

GL_OES_single_precision

GL_OES_matrix_get

GL_OES_read_format

GL_OES_compressed_paletted_texture

GL_OES_point_sprite

GL_OES_point_size_array

GL_OES_matrix_palette

GL_OES_draw_texture

GL_OES_query_matrix

GL_OES_texture_env_crossbar

GL_OES_texture_mirrored_repeat

GL_OES_texture_cube_map

GL_OES_blend_subtract

GL_OES_blend_func_separate

GL_OES_blend_equation_separate

GL_OES_stencil_wrap

GL_OES_extended_matrix_palette

GL_OES_framebuffer_object

GL_OES_rgb8_rgba8

GL_OES_depth24

GL_OES_stencil8

GL_OES_compressed_ETC1_RGB8_texture

GL_OES_mapbuffer

GL_OES_EGL_image

GL_EXT_multi_draw_arrays

GL_OES_required_internalformat

GL_IMG_read_format

GL_IMG_texture_compression_pvrtc

GL_IMG_texture_format_BGRA8888

GL_EXT_texture_format_BGRA8888

GL_IMG_texture_stream

GL_IMG_vertex_program

 


I've played around with "GL_OES_framebuffer_object" as a replacement for "GL_ARB_framebuffer_object",

but the methods which according to the OpenGLES 1.1 Specification should be available (e.g. "glGenRenderbuffersOES")

are not available in libGLES_CM.so, so I'm stuck here 

 

Oh, and I've set every game option (lights, etc.) to the lowest available setting.

 

 

[crow_riot]

with GLES vbo are no longer an extension but built in. so you'll never find the correct string within the extension list:

you need to replace the gl*ARB versions within OGL_VBO.cpp with the normal GLES versions - they are just the same functions but without the ARB suffix and dont need to be imported using SDL_GL_GetProcAddress.

on the other hand, all functions reported by the extension list need to be imported using eglGetProcAddress.

 

[viewizard]

dbluelle, please note, I am not strong in OpenGL ES, so, I can provide only theoretical points, and I hope pandora community will help you in your work. :rolleyes:

About "GL_OES_framebuffer_object" as a replacement for "GL_ARB_framebuffer_object" - you don't really need FBO at all. Game use FBO for anti aliasing and shadow mapping only, so, use libSDL controlled framebuffer and don't waste your time on FBO.

 

[sebt3]

a few things :

- Hi vieWizard, thanks for your awesome game (and thankks for gpl it too)

- when I tried to port astromenace, I did added fbo support which did not increase performances (which sound logical : there is no speed boost putting things in the SGX memory : it's the main memory anyway...) So follow the game author advice

- you say that the CPU used when running is 80%, so the sgx only take 1/5 of the frame time, optimizing 1/5 of the total is not the best method

If you want that game on pandora running you'll need to profile the code to find out where all this CPU time is used to. That's where I failed : the code comments did not helped me much.... but you have the Wizard here, he might help you there

 

[viewizard]

Sebt3, thanks for your kind words.

Since game have 15fps in menu and the main issue is CPU load (even without collision detection math), this could be connected to particle systems only, imo.

1) Static space stars. Turn them off fully (you need turn off rendering and updating! Not just rendering, because updating eat CPU). Open “GraphicFX/StarSystem.cpp” file, and comment “if (psSpaceStatic!=0) psSpaceStatic->Draw();” line and ”if (psSpaceStatic!=0) psSpaceStatic->Update(vw_GetTime());” line.

2) Dynamic space stars/dust. Turn them off fully. This not so easy to do, since they use common particle systems manager, so, in test proposes just change particle generation value:

“Menu/Menu.cpp” file, change “psSpace->ParticlesPerSec = 140” to 0 (or 1, for example), this mean 0 particles will be generated each second, and the same for game code - “Game/Game.cpp” file, change “psSpace->ParticlesPerSec = 100;” to 0.

In order to fully remove dynamic space stars you will need remove all connected to psSpace (eParticleSystem *psSpace) lines.

3) All other particle systems connected to 3D objects. Test the game without particle systems (so, we will see the FPS drop related to this particle systems).

“Object3D/Object3DManager.cpp” file, comment “ vw_DrawAllParticleSystems();” line, then

“Menu/Menu.cpp” file, comment “vw_UpdateAllParticleSystems(vw_GetTime());” line, and the same for game code - “Game/Game.cpp” file, comment “vw_UpdateAllParticleSystems(vw_GetTime(1));” line.

dbluelle, if my text was not clear :unsure: (English is not my native language), do not hesitate and let me know, I will try to rephrase.

 

[dbluelle]

First I thank all of you for your help and suggestions. This thread really helps me a lot in understanding how the whole opengl/es stuff works.

Okay, here's my progress so far:

- I've enabled the vbo support as suggested by row_riot.

This resulted in about 3-5 more fps and ~10% less cpu usage B)

- I've detected that the background music thread makes up for ~15% of cpu usage,

so I've disabled sound support completely for the moment ( I will take a look at the sound stuff later)

Currently the main menu is running with 14-17 fps and 45-50% cpu.

1) Static space stars. Turn them off fully (you need turn off rendering and updating! Not just rendering, because updating eat CPU). Open “GraphicFX/StarSystem.cpp” file, and comment “if (psSpaceStatic!=0) psSpaceStatic->Draw();” line and ”if (psSpaceStatic!=0) psSpaceStatic->Update(vw_GetTime());” line.

This leads to another 4~5% less cpu usage, but doesn't have a measurable affect on fps.

2) Dynamic space stars/dust. Turn them off fully. This not so easy to do, since they use common particle systems manager, so, in test proposes just change particle generation value:

“Menu/Menu.cpp” file, change “psSpace->ParticlesPerSec = 140” to 0 (or 1, for example), this mean 0 particles will be generated each second, and the same for game code - “Game/Game.cpp” file, change “psSpace->ParticlesPerSec = 100;” to 0.

In order to fully remove dynamic space stars you will need remove all connected to psSpace (eParticleSystem *psSpace) lines.

This also leads to another 4~5% less cpu usage, but doesn't have a measurable affect on fps.

3) All other particle systems connected to 3D objects. Test the game without particle systems (so, we will see the FPS drop related to this particle systems).

“Object3D/Object3DManager.cpp” file, comment “ vw_DrawAllParticleSystems();” line, then

“Menu/Menu.cpp” file, comment “vw_UpdateAllParticleSystems(vw_GetTime());” line, and the same for game code - “Game/Game.cpp” file, comment “vw_UpdateAllParticleSystems(vw_GetTime(1));” line.

Strangely this leads to similar results as the other two suggestions.

With all stuff commented out, I'm currently running the main menu with 27-33% cpu usage and 15-16 fps. :unsure: