Text render problem

sanjelanka · Post by **sanjelanka** » Tue Jun 23, 2009 4:29 pm

Hi all

I've got this problem with ATI Open drivers on Ubuntu 9.04 and 8.10
I've tried both irrlicht 1.4.2 libs and 1.5 libs

The problem is that the text on the gui is unreadeable
I tested it simply running the GUI Example from the tutorial folder

The same code compiled on windows haven't any problem.

This is a screenshot

No errors reported on the console

Code: Select all

Linux 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:57:31 UTC 2009 i686
Creating X window...
Visual chosen: : 91
Using renderer: OpenGL 1.3
Mesa DRI R300 20060815 AGP 8x x86/MMX/SSE2 TCL: DRI R300 Project
OpenGL driver version is 1.2 or better.
GLSL not available.
Loaded texture: /media/sda3/orpg/Orpg/irrlicht-1.5/media/irrlichtlogo2.png

Letalis Sonus · Post by **Letalis Sonus** » Wed Aug 05, 2009 10:38 am

i am experiencing the same problem with a Radeon 7500 Mobility and i guess i know the problem:
as Irrlicht still has to use such texture fonts you always have a very large texture in your VRAM, and exactly this can cause problems. you can try installing driconf and playing around with the setting concerning the support of large textures and the amount of reserved memory for textures in the xorg.conf, and you'll notice that these settings can have huge influence on what's exactly displayed.
other example programs using fonts with a smaller texture such as the PerPixelLighting one are able to display the font correctly (at least for me).
the scrambling of the font comes from the default setting of DRI to stuff large textures into the VRAM even if there's only very few room left, it seems to use some lossy method to make it fit, if you disable it the stuff appears just white.
if you now still add more and more textures you'll sometime hit the total limit, the program will freeze and spam you with the message "[driAllocateTexture:635] unable to allocate texture". while other engines seem to have fallback methods for the allocation of VRAM (Neverwinter Nights (natively on Linux) e.g. runs very good with only having 16MB for textures) Irrlicht seems to just retry it until the user aborts.

hybrid · Post by **hybrid** » Wed Aug 05, 2009 10:49 am

The fonts are not really big, 256x256 should be handled by every driver out there. The thing with full VRAM can become a problem if you loa many things, but todays drivers usually have a swapping mechanism which pages out the unused areas (with a heavy performance drawback of course).

Letalis Sonus · Post by **Letalis Sonus** » Wed Aug 05, 2009 9:38 pm

the 'radeon' driver (latest stable) doesn't seem to have that swapping mechanism. programs/games seem to have own mechanisms, even Garry's Mod (10, as 11 doesn't like DX7 cards anymore) gets along just fine with the few MBs for textures when running within Wine, and it definitely needs more.
while developing a game on my laptop the problem of not being able to allocate space for textures got that worse that i had to increase the amount of reserved VRAM and lower the preferred bit depth to 16 via driconf, the fonts are still messy. (the old T40s don't have shared memory, only 32MB dedicated VRAM. by default the driver reserves 50% for OpenGL textures)

i wonder why the fonts are looking that messy, though. other textures affected by that lossy DRI stuff are just loosing some sharpness, Garry's Mod and Neverwinter Nights don't even seem to be affected at all. what's up with the work done on the OS font stuff (->EGFT_OS)? the possibility of using "real" fonts would eventually fix the font issue.

bitplane · Post by **bitplane** » Wed Aug 05, 2009 11:06 pm

The only ways I could think that a driver might save space like that is by not resizing to the next power of two, using less bits per pixel, refusing to generate mipmaps or scaling the image down. Texture compression doesn't work in realtime and is covered by patents, the bitmap is already a power of two, it has no mipmaps, is 16-bit and the output clearly shows single pixels on the "g"s, so isn't scaled.

My guess would be that the glTranslatef(0.375, 0.375, 0.0) in COpenGLDriver::setRenderStates2DMode causes the position to sometimes round the wrong way, probably caused by a bug in the driver. I don't have an ATI machine to test this though.

what's up with the work done on the OS font stuff (->EGFT_OS)? the possibility of using "real" fonts would eventually fix the font issue

Font factories *may* make it into Irrlicht 1.6 if there's enough time, so OS fonts might be able to be added from outside by then. It will be 1.7 at the earliest before we have built-in OS fonts (if ever)