Loading textures only when they're needed?

Member
Posts: 35
Joined: 2009.01
Post: #1
Hi,

When my game was < 50% complete, it ran at a reliable 60fps. Now it's starting to occasionally drop to 30fps... The number of sprites / particles on screen has not gone up significantly.

Up until now, I've been preloading ALL the textures in the game (with glTexParameteri). Is it possible that having all the textures in memory could be causing this difficult-to-reproduce slowdown? I have about 40 textures, on average 128x128 in size. Should they be loaded only when they are being used and disposed of otherwise?
Quote this message in a reply
Apprentice
Posts: 8
Joined: 2009.11
Post: #2
Yes, they should! Plus u should gather few textures into one (if they are used on the same scene, at the same time), this will raise productivity of app
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #3
I sort of doubt that you are running out of memory, if as you say 40*128*128*4 ~ 2.5MB of VRAM. So not very much. However, state changes such as changing the current texture IS fairly expensive. If your rendering code sets the texture every time you draw a sprite, you could really be killing your performance.

Probably a better thing to do at this point is to make sure you are drawing bunches of sprites with the same texture before changing it. As Dimka said, a good way to do that is to collect your textures into an atlas, a big texture with a bunch of smaller textures arranged inside of it. Then you can draw more things before having to change the texture state.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 35
Joined: 2009.01
Post: #4
My state engine avoids unnecessary texture changes, but what is being changed a lot is glColor4f (mainly for particles)... Perhaps I should learn to use color arrays for my particle rendering...
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #5
Does commenting out the calls to glColor*() in your particle code speed up the program much? I'd make sure it's worth the gain before embarking on a difficult change without a clear cut promise of performance.

Have you tried profiling with Shark? What does it tell you the hotspots in your program are?

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #6
Skorche Wrote:Does commenting out the calls to glColor*() in your particle code speed up the program much? I'd make sure it's worth the gain before embarking on a difficult change like that.

Have you tried profiling with Shark? What does it tell you the hotspots in your program are?

The problem is not the glColor method in itself but rather issuing glDraw calls for every quad.
If you are doing particles or any sort of quad rendering where you are rendering more than just a few quads, not using interleaved vertex arrays will always kill performance.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  OpenGL ES Loading Textures soulstorm 5 6,318 May 25, 2009 07:21 AM
Last Post: soulstorm