delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/05/23/09:05:03

From: "Hargreaves, Shawn" <shawnh AT probe DOT co DOT uk>
To: "'djgpp AT delorie DOT com'" <djgpp AT delorie DOT com>
Subject: Re: Translucence in SVGA Using Allegro
Date: Fri, 23 May 97 14:00:00 PDT
Message-ID: <33860582@relay.probe.co.uk>
Encoding: 36 TEXT

Alex Kain writes:
> Is using the translucence/lighting procedure in Allegro possible
> and/or practical in 640x480x256 svga?  I'd like to know how fast
> such a task would take, if it is possible.

Well, what target machine are you aiming for? On a Pentium Pro 200,
sure. On a 486 SX25, I don't think so :-)

It will also depend what you are doing with the functions. Applying
dynamic light levels to an entire 640x480 screen is going to be a
lot more expensive than just drawing a couple of translucent
explosions! You'll just have to try it and see, or you could give the
user the option of enabling these features, so people with fast
machines can glory in full translucency while others have to make
do with boring cut-out explosion sprites :-)

You can get an idea of the raw speed of the functions by running
test.exe, but you should be aware that it is drawing directly to video
memory, and they will usually be a lot faster if you are able to draw
onto memory bitmaps instead. There are a couple of things to bear
in mind:

 - lighting is usually much faster than translucency. It involves reading
  a pixel from the sprite, using it as an index into the color table, and
  writing the result, while translucency also involves reading the
  existing color value from the destination address.

 - translucent drawing is a _lot_ faster with memory bitmaps! It uses
  a read-modify-write operation, which doesn't work very well with
  video memory.

Hope that helps...


 Shawn Hargreaves.

- Raw text -


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