PDA

View Full Version : Multiple Textures in Opengl... Or not?



code_glitch
27-04-2011, 09:09 PM
Working on a new rendering system to render characters from TTF files to a GL texture for fast drawing brings up the following:

In terms of performance which is faster or has the lower memory usage, if there is a difference: 256 very small textures each with one character in an array (easy access via ASCII code ;)) or a very big texture with 255 characters in it and a function to calculate co-ordinates?

Just a thought... Although I might implement both if there is wither has better CPU/memory footprints. I simply can't seem to find much info on this one. ???

Bonus question: If I load a font in size 12, is that 12 pixels high? Or is there some other conversion. I think it differs by DPI but if it is not rendered and is on a gl texture in memory is that also affected?

cheers,
code_glitch

Andru
27-04-2011, 11:33 PM
256 very small textures each with one character in an array
Bad idea, if you want to render more than 1-2 words.


If I load a font in size 12, is that 12 pixels high?
No, this size is depends on DPI.

paul_nicholls
27-04-2011, 11:57 PM
Working on a new rendering system to render characters from TTF files to a GL texture for fast drawing brings up the following:

In terms of performance which is faster or has the lower memory usage, if there is a difference: 256 very small textures each with one character in an array (easy access via ASCII code ;)) or a very big texture with 255 characters in it and a function to calculate co-ordinates?

Just a thought... Although I might implement both if there is wither has better CPU/memory footprints. I simply can't seem to find much info on this one. ???

Bonus question: If I load a font in size 12, is that 12 pixels high? Or is there some other conversion. I think it differs by DPI but if it is not rendered and is on a gl texture in memory is that also affected?

cheers,
code_glitch

Hey mate :)

To get optimal OpenGL (or most graphical rendering libraries) performance, it is best to pack multiple smaller textures into one big (usually power of 2 dimemsions X & Y) texture.

Then just get the smaller rectangles, or whatever coordinates UV you are using to pull out your quads/triangles, etc. from the larger texture and render them :)

You can try my image packer program I wrote (complete program including image load/save DLLs):

http://fpc4gp2x.eonclash.com/downloads/Image%20Packer.7z

and the updated .exe file:
http://fpc4gp2x.eonclash.com/downloads/imagepacker.exe

It allows you to import and pack multiple smaller images into one big image which you can then export as a single image.

You can also save as xml or ini, the locations in the larger rectangle of all the smaller sprites for easy access later on

cheers,
Paul

code_glitch
28-04-2011, 06:27 AM
So thats the first one solved... If I wanted pixel dimensions, since I am currently using sdl_ttf for file format support I remember there being a sdl_getrenderedheight/width correct? I assume I could use that for spacing...

User137
28-04-2011, 02:31 PM
what i did was divide texture in 28 x 32 grid for each 256-32 characters (Spacebar is no character, you can manually move caret forward). You can draw each character in the middle of their cell, so you don't need to worry about spacing and relations between them.

For 256x256 texture it would mean 8x9 pixels for each character, leaving a little empty space at bottom. It is well enough for common fonts. 512x512 would allow more detail with 16x18 character size, at great cost of memory use. Still i'd rather use the memory for this rather than draw fonts geometrically. Simple quad will always be 100 times faster to render especially if you optimize it with arrays, displaylists or such.

code_glitch
28-04-2011, 05:34 PM
The idea was to fix the slowness of nice fonts from sdl_ttf. sdl_ttf is nice for loading and thats about it. Thus if we load the font with sdl and then draw a greyscale version to a texture and the free the sdl font, we can simply do a glcolor and quad draw from the texture which should be 1.5million times faster... Still, it seems my co-ord calculations are not quite up to scratch yet as I am getting bits of garbled letters everywhere ;)