Sprites.. X11

Compiled sprites are pushing it I think, especially since you have to
write one separate routine for each processortype. I just RLE blocks of data
first, and then unRLE it to the screen (but not on the fly).
You say you use dynamic recompiling for splitting - can this really be
quick? I’m thinking of using another routine as memcpy() in the RLE
decoder when clipping against X is necessary, which clips the actual
memcpy against the screen. Y clipping can be done before drawing the
sprite.

I think the confusion arises in that what I called compiled sprites
are actually a variant on RLE encoding which I developed myself.
(I wasn’t aware of the meanings of either terms when I spoke earlier)

I tried it yesterday, it was much easier than I thought. Very nice to
have direct access to the videomemory and being able to doublebuffer AND wait
for the VBL (Vertical Retrace). I also found a few routines for checking
available screen modes and switching.

Where did you find those? I rolled my own, but they aren’t very good.

Be careful when using DGA – you have to allow for banked mode access,
which is slightly tricky and slow.

I only got one problem - how the F**K do you find out bits_per_pixel for
the display?! I run 32bit but this is always reported as 24bits, no
matter if I use DefaultDepth(), or search all visuals with
XMatcvhVisualInfo().

heheheh. It’s a long-standing bug in the current version of Maelstrom.
SDL does it right. Take a look at SDL_VideoInit() in src/linux/x11/SDL_video.c

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/projects/SDL/