Maybe I am unrealistic, but I was a bit disappointed to find out,
that on my 2.5 GHz with a Radeon 9800 XT, I could not draw more
than 2000 Sprites of size 0.1 x 0.1 at 60 Hz.
Is there a way to get more stuff on the screen using QC ? [Looking
at the profiler, OpenGL seems to spend most of the time in gl_Begin
and some flush routine.]
That makes sense: Sprite has some overhead is setting up the OpenGL
states each time and communicating with other patches. It's not
efficient at all for serious bulk drawing with thousands of instances.
My first idea was to use the "Crop" filter to create little images
for each sprite. This was a slow approach.
The reason is that it creates a new texture for each "crop" of the
original image and if you do that many many times, you end up using
most VRAM, which slows down everything.
My second try was to use the "Image Texturing Matrix". That was
pretty quick, 10 times quicker.
That's definitely the best approach as you keep using one single
texture, but shows different areas of it.
It appeared to me, that I might go even faster with a "Core Image
Kernel", but that has left me puzzled. When the kernel is running
with mostly "static" inputs, it is indeed faster than the
"Texturing Matrix", but when I hook up two more inputs it slows
down to the level of the Crop filter. Is there something that I can
do, to make the Core Image Kernel faster ? I suspect it samples its
input for every pixel, but it really only needs to do this once per
iteration. Interestingly it does notice that one of its inputs is
derived solely from iterator variables, and does not slow down on
that input.
Same comment as for Crop: you'll end up doing extra computations and
use extra VRAM.
