||Currently there is very
lot TitaniumGL user, so if you are a game developer, its
maybee a good idea for you to check TitaniumGL. To
optimize your game to TitaniumGL, is very easy. You will
face the same cases, like you optimizing to ATi or nVidia
Dont forget: Most of TitaniumGL users are using old
graphics cards. These old graphics cards are very slow,
so if you want to create a TitaniumGL profile
optimisation, you must probably use lowest settings.
-TitaniumGL is triangle based. This means, triangle
data input will be the fastest in EVERY case. Triangle
strip, quads, quad strip, triangle-fan will be slower
than trangle-based geometry. Quad strip and triangle fan
is the slowest.
-Vertex Buffer Objects and vertey arrays are the fastest
rendering paths. But they will be only faster, if the
data is in floating point, and triangle based. The speed
will highly incrase, if the incoming geometry data is 3x3
float per triangle, the uv is 2*3 float per triangle, and
if you are also using color, 4*3 float per triangle. If
you are using texture matrix, speed will drop.
-If you can, avoid the use of drawarrays. It may will
-If you rendering with lot of glend/glend or lot
drawbuffers, will be also slow.
-If you are planning to speed up your geometry bandwith
by using chars or integers instead of floats, it will not
-Display list are the fastest, but eats a lot of RAM. A
display list contain the data and the commands
preoptimised, so sometimes, creating a display list is a
bit slow. It does not matter what kind of data type
(float, integer, short, ...) or geometry type (triangle,
quads, fans, strips, ...) you give, TitaniumGL will
internally represent them as pre-tesselated and optimised
data. With TitaniumGL, Display Lists are the fastest way
to render your geometry.
-Drawing lines and points can be buggy.
-If your engine can do it, use geometry lod.
-Currently, TitaniumGL has a big cpu-limit. With modern
computers, TitaniumGL is able to process maximum 1-6
million triangles/sec. Processing larger blocks of
geometry can be faster, than processing more smaller
-Rendering a multitextured geometry is faster, than
rendering the geometry twice.
-Three texture pipeline available.
-Switching textures rapidly, even if you switching to the
same texture, will cause speed decrase.
-Copying frame buffer to texture is slow, but can be used
with modern gpus. Older buggy GPU-s will probably produce
-Uploading texture data is slow. Fastest is RGB and RGBA
texture data uploading, and these two kind of formats
supported internally. Switch off mipmapping, if you can.
On a 1,6 ghz machine, texture uploading happends with
approx. 30 mbyte/sec. If you using float, integer, or
short textures, the upload speed will decrase even more,
resulting longer loading to your game. Buffering
subimages will be even slower. With TitaniumGL,
overwriting the textures in the memory will NOT be faster
than deleting and recreating them. TitaniumGL will accept
every size of textures, but the graphics card may will
recive a smaller image, if it does not support large
textures. This will not affect TitaniumGL's internal
texture representation, but if the graphics card does not
support them, the resolution of the image in the VGA RAM
will be downscaled.
||If your graphics card supports it, TitaniumGL
will automatically use anti-aliasing.
-Do not use stencil/alpha/lookop buffers.
-Blending on old cards are unimplemented, except
and alphablending. The best is to use this two
kind of blending.
-Material handling is not yet correctly
implemented, and light management
-TitaniumGL (like some other vendors) will NOT
lost your device, even if
you are trying it. Destroying and recreating a
context is a very bad idea
to delete your textures. Making it 10x times to
be sure, its a very very bad idea ;)
-TitaniumGL does not rely in the DirectX stack.
Unlikely with other OpenGL
to Direct3D wrapper, now DirectX is only used to
render the geometry with
hardware acceleration, its not used to implement
the whole OpenGL API.
Becouse of this, TitaniumGL will avoid the
graphics cards hardware design
flaws and driver problems, but still stays fast
becouse the 3D is accelerated.
This is, why the same features available on all
graphic cards with TitaniumGL.
Every TitaniumGL version is tested with 30-40 game
software, 10-20 feature tester miniapp, and with some
stress-test applications. TitaniumGL has
pointer-corruption detector, internal memory protection,
pointer overrunning protections, and several other
security locks. TitaniumGL has some debugging features
too, but that requies a specially compiled version.
If you send me a bugreport, its being added to my
buglist, and i will check it. This does not means that it
will be fixed in the upcoming versions, but i will try to
fix it. If you have donated, your bugreport will be
investigated with higher priority, but its still not
means that i can fix your issue, becouse a driver is
always very complicated.
Always use the newest version!
-If you are a gamer, and you found a bug, you can send
a bugreport to my email address. The bug-report must
contain the buggy game/software name, the name of your
graphics card, CPU, size of your RAM, and of couse the
bug itself. No other information needed from your
-If you are a developer, and you have found a bug, you
can send a bugreport to my email address. Mostly its much
simplyer to fix the problem in your application, by
changing the problematic parts to others. Your bug-report
must contain your stuff's name, the name of your graphics
card, and of couse the bug itself. No other information
needed from your computer. Please write, what function
did causing the bug, if it crashing, please remove other
codes and try to test the crashing codes alone. Its still
crashing? Do you use multithreading? Or is the graphics
corrupt? How do you render the corrupt parts? Its still
corrupt if you using different way to render? Its good to
send me screenshots from the bug and from the correct
image. You also can send me source code, in this case
please tell me the corresponding file and line in your