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