Hi,
As far as I know (talking 'bout opengl), the display driver already
manages a lot of this. Means, that it lets you create textures beyond
the graphics card’s memory and the only thing the developer needs to
(can) do is:
glAreTexturesResident()
glPrioritizeTexture()
As you already said, using system memory comes with a performance
penalty. If you have a lot of textures and cannot supply your game with
your own clever(!!) texture caching algorithm, you should let the driver
manage texture caching, i think.
With glTexImage and glTexSubImage you’re right.
When doing SDL_Surface->OpenGL, think of opengl’s power-of-two
restriction of texture dimensions (opengl < 2.0) and how to solve it by
using extensions (GL_EXT_texture_rectangle,
GL_ARB_texture_non_power_of_two, …)
glTexSubImage is quite fast, but I haven’t compared to a blit.
Correct me, if i’m wrong,
Matthias
mal content schrieb:> Torsten’s question prompted me to ask this, I’ve kept the
threads seperate so as not to tread on his toes!
Am I correct in thinking that (assuming OpenGL) if you
continually upload textures to a graphics card that you
will exhaust the texture memory, that system memory
will be used instead (at a performance penalty)?
I don’t know anything about the ins and outs of graphics
hardware, but am picking things up slowly.
Unless I’m totally wrong, the OpenGL function glTexImage
uploads a texture to the card and glTexSubImage basically
replaces a given texture (so you could keep an array of
pixels in system memory, modify them and re-upload the
texture to the card). Is this correct?
I hope to start on a very small SDL_Surface -> OpenGL
texture library soon. That should open a nice can of worms…
thanks,
MC
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl