www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/06/11/10:31:23

From: D DOT J DOT Eleveld AT anest DOT azg DOT nl
Newsgroups: comp.os.msdos.djgpp
Subject: Re: [Allegro] RLE sprites and background
Date: Thu, 11 Jun 1998 13:17:47 GMT
Organization: Deja News - The Leader in Internet Discussion
Lines: 43
Message-ID: <6loldq$c2b$1@nnrp1.dejanews.com>
References: <6llq0f$363$1 AT nnrp1 DOT dejanews DOT com> <UguCyDAOUtf1EwFz AT talula DOT demon DOT co DOT uk>
NNTP-Posting-Host: 192.87.23.66
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In article <UguCyDAOUtf1EwFz AT talula DOT demon DOT co DOT uk>,
  Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk> wrote:
>
> >I have a question about RLE sprites.  I know that you can blit a RLE sprite
> >to a BITMAP and that skips the zero background, but is it there a nice trick
> >that can efficiently put a color _behind_ an RLE sprite?
>
> There's no current way to do that, but it would be a fairly simple
> modification to the RLE drawing code. Of course this would require

I took a look at the RLE code and I couldn't really figure out how to do
something like that.  I'm mostly a C++ programmer so assembly is just wierd
and wonderful (and very opaque) for me.

> special RLE-character functions for all the possible color depths, which
> is a fair amount of extra code...

Ok, would it then be more sensible to write a color depth independant routine
using lots of hline calls?  Do you think it would be too slow?	I quickly
looked at some hline code and it didn't appear to have a long startup time or
anything, in any case, not longer that putpixel.

> For drawing characters you would probably also want to replace all non-
> zero pixels with the text color, rather than just displaying them
> unchanged. That means there isn't really any point storing the pixel
> values in the sprite, so you could make a meta-RLE format, that just

Well, I was thinking that once this thing works, (possibly even before) I'd
merge it with the AllegTTF library so it could handle antialiased text too...

> encodes runs of solid or zero pixels (negative values for a zero run,
> positive ones for a solid run), which would probably be only a fraction
> the size of a normal RLE sprite, let alone an entire bitmap object...

Ok, I'll think about how I'd do something like that.  Of course, if I get it
working I'll let everyone here know.  If anybody wants to help or has any
ideas, let me know...

I just love the new >
<input type=

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019