jonas at upright.se
Wed Apr 1 00:29:53 PST 1998
Sam Lantinga wrote:
> > All these routines are plain C, and use direct
> > access to a screenbuffer. I'm thinking of making a new OS-independant
> > version of the library the runs on top of SDL. RLE-sprites are really
> > the way to go for fast blitting.
> It sounds perfect for SDL. I'm also (slowly) working on a compiled-sprite
> class on top of SDL for the Maelstrom port, and compiled sprites are, I
> think, the same as RLE-sprites. I've also gotten fast dynamic recompiling
> of the sprites to handle clipping.
Compiled sprites are pushing it I think, especially since you have to
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
> > Have you looked into DGA - something you can use under X11 for direct
> > screen access in fullscreen mode? I know UAE can use it, but I have
> > not found any documentation over this, but seems like it could be
> > usable. I'd really like to see fullscreen apps/games in X.
> Yup, it's on my list of supported interfaces for Linux/SDL, right
> after GGI support.
I tried it yesterday, it was much easier than I thought. Very nice to
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.
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
if I use DefaultDepth(), or search all visuals with XMatcvhVisualInfo().
The only thing I can come up with is check the X-process and see what
arguments it was started with (and thats NOT very nice).
More information about the SDL