From:	Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Allegro Translucency/Lighting tables -- Should be made separate?
Date:	Mon, 24 Feb 1997 20:35:14 +0000
Organization:	None
Distribution:	world
Message-ID:	<zhpf$FACufEzEwht@talula.demon.co.uk>
References:	<5eqklv$15gq AT elmo DOT cadvision DOT com>
NNTP-Posting-Host:	talula.demon.co.uk
MIME-Version:	1.0
Lines:	44
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Calvin French writes:
>I'm probably missing something, but why do the translucency and
>lighting draw functions use the same global table? 

Why not? :-)

The real reason for the way this works is that, as well as the
translucent and lit sprite drawing code, there is a translucent drawing
mode that affects all the geometric drawing functions (call
drawing_mode(DRAW_MODE_TRANS, NULL, 0, 0), and you can then render
translucent lines, circles, polygons, etc). There's no way to pass an
extra lookup table parameter to these functions...

I know lighting and translucency are logically different effects, but if
you twist the way you think about it slightly, you'll realise that they
are really the same! I just called them 'lighting' and 'translucent'
modes because that's what I think they will most frequently be used for,
but in fact you can make them do all sorts of different color combining
operations depending on how you construct the lookup tables. Both these
functions essentially do the same thing, which is to take two different
colors, blend them, and write the result to the destination bitmap. The
only difference is that for translucent drawing the two input colors are
the pixel from the sprite that is being drawn and the pixel already at
that location in the destination bitmap, while for lit drawing one color
comes from the source sprite and the other is a fixed 'tint' value.

>a) make 2 different global tables.

I don't see why this is a problem, Sure, if you're drawing lots of
things with different tables you'll have to keep altering the table, but
that only means altering one 32 bit variable. Hardly a major overhead,
and even if added several global tables, it wouldn't help people doing
clever things that require five or six different lighting tables :-)

>b) pass a pointer to the table you want to use as an arguement (maybe
>make a c++ default value set to one of the 2 different global tables.

Relying on a C++ feature would cause major problems for anyone who wants
to use Allegro in a C program, so that really isn't an option...

/*
 *  Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
 *  Beauty is a French phonetic corruption of a short cloth neck ornament.
 */

- Raw text -