| |
Blending |
| |
andreww (08:27 6/8/2001)
johnstlr (08:31 6/8/2001)
andreww (12:47 6/8/2001)
andreww (21:16 7/8/2001)
Loris (13:43 24/8/2001)
andreww (08:54 31/8/2001)
Phlamethrower (17:06 1/9/2001)
Loris (16:47 2/9/2001)
andreww (23:05 3/9/2001)
Phlamethrower (15:37 4/9/2001)
andreww (08:55 5/9/2001)
Phlamethrower (17:03 5/9/2001)
andreww (09:18 7/9/2001)
not_ginger_matt (23:35 4/2/2002)
|
| |
|
Andrew |
Message #86393, posted by andreww at 08:27, 6/8/2001 |
AA refugee
Posts: 555
|
Can anybody tell me, what would be the best way to blend a sprite onto a background in a 256 colour (old-style) mode?
One method I tried averaged the individual components of a pixel and the colour beneath it but I'm thinking there must be another way. |
| |
 [ Log in to reply ] |
| |
|
Lee Johnston |
Message #86394, posted by johnstlr at 08:31, 6/8/2001, in reply to message #86393 |
Member
Posts: 193
|
How about not plotting certain pixels in the sprite, allowing the backgound to show through? I remember an screen fader from AU's *Info column written by Mark Hobson which did something similar to fade between screens. Dunno how effective it would be (or how good it work look). |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #86395, posted by andreww at 12:47, 6/8/2001, in reply to message #86394 |
AA refugee
Posts: 555
|
Good idea. I'll try that and see. |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #86396, posted by andreww at 21:16, 7/8/2001, in reply to message #86395 |
AA refugee
Posts: 555
|
Yes, I've plotted alternate pixels and it is definitely ideal and far better Lee, thanks. |
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #86397, posted by Loris at 13:43, 24/8/2001, in reply to message #86396 |
 Ha ha, me mine, mwahahahaha
Posts: 1025
|
Hi folks. Um..
Oh yeah, plotting alternate pixels in a checkerboard-like array is a good idea, however it does mean you can't use dithering in the background sprite. I suppose you could use alternate row plotting, which would be faster too, but might look a little ugly if stationary or in low res. IIRC I read that some demo used this method..
In 256 colours I suppose the best looking method would use a look-up table for each foreground/background combination. This however would be slower (by at least another load instruction) - although faster than calculating each colour component. Also it would require quite a lot of RAM. Although if you limited either the foreground or background colour range it needn't be too prohibitive. I've not done it myself.. I'd use the checkerboard method if I were you, and stick to block-colour.
Yours,
Tony |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #86398, posted by andreww at 08:54, 31/8/2001, in reply to message #86397 |
AA refugee
Posts: 555
|
I've tried the manipulation of background and foreground bits but it doesn't always look very effective in 256 colours. I wondered what methods could be used apart from taking the average of the individual components?
How would you generate the tables entries in other words? |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #86399, posted by Phlamethrower at 17:06, 1/9/2001, in reply to message #86398 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
The way I'd make the table would be to convert each colour to 24bit, blend, then convert back into 8bit for storing. If you are doing the 24->8 conversion using your own code then be warned because the way you calculate the tint can have a large effect on how the picture comes out - I'd recommend adding the RGB tint bits together then sharing by 3. |
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #86400, posted by Loris at 16:47, 2/9/2001, in reply to message #86399 |
Ha ha, me mine, mwahahahaha
Posts: 1025
|
I agree, however, I would argue that the best automated way is situation-dependent.
What I mean is that both of the initial colours are only approximations of the shades you really want.
For example, suppose you have a black to red colour scale over 12 shades. Some of these have tint bits set, which add some green and blue. So if you knew that in your sprites all your colours were on this scale (if they had these colour values) then you could use the 'true' values to start the calculation with. Because otherwise I suspect that the amount of tint would be increased and might overflow into the lower colour bits, leading to an overall greyer colour than you wanted.
Like I said, the table method is probably only suitable if you know the range of one or other of the sprite pair, so it would presumably not be to hard to use idealised values for the inputs.
If you are dealing with whole-range sets then the table required is 256*256=64k (for max speed) although this could be (just over) halved if you were to test which colour was higher and also directly return if the colours were the same.
Finally, colours which didn't look right could be manually tweeked, although that might be a job of work!
Did I mention that the colour effect applied should be related to the nature of light? Eg a transparent (but coloured) object subtracts colour while, say, a sub-pixel line should simply mix. Probably best not, eigh :-)
Sorry for the long post.
Yours,
Tony |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #86401, posted by andreww at 23:05, 3/9/2001, in reply to message #86400 |
AA refugee
Posts: 555
|
Jeffrey - So to convert to 24-bit, you'd take each low and high-bit of the colour component and add to the low and high tint bits and multiply by 16 for red, green and blue? Then you would do this for the corresponding pixel (coincident) and take the average of both before shifting back each colour component into an 8-bit field?
Tony - yes there would be issues with the material being simulated but I think I'd try this simple blend first as I don't know a lot about the properties of light and it's interactions with matter, I'm afraid!
|
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #86402, posted by Phlamethrower at 15:37, 4/9/2001, in reply to message #86401 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Jeffrey - So to convert to 24-bit, you'd take each low and high-bit of the colour component and add to the low and high tint bits and multiply by 16 for red, green and blue? Rather than try and explain everything I'll just donate some code r = ((col AND 7) + (col AND 16)/2) * 17
g = ((col AND 3) + (col AND 96)/8) * 17
b = ((col AND 3) + (col AND 8)/2 + (col AND 128)/16) * 17 AFAIK that's the correct way of converting from the internal BGGRBRTT format to some 24bpp components. The format of each component would be: RRTTRRTT
GGTTGGTT
BBTTBBTT To convert back to 8bpp: col = ((r AND 63) + (g AND 63) + (b AND 63))/48
col = col + (r AND 64)/16 + (r AND 128)/8
col = col + (g AND 192)/2
col = col + (b AND 64)/8 + (b AND 128) [edit] Bah! invasion of the 8) smilies! Tim must get round to fixing those some time... And updating the link detection code to work with underscores and things... And fixing the smiley code again so >:( works...
[Edited by Phlamethrower at 16:45, 4/9/2001] |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #86403, posted by andreww at 08:55, 5/9/2001, in reply to message #86402 |
AA refugee
Posts: 555
|
They wouldn't be 8-bits per component if they were repeated like this then:
rrttrrttWhy the multiplies by 17?
I wish you had explained it as that would have been a lot more useful!! |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #86404, posted by Phlamethrower at 17:03, 5/9/2001, in reply to message #86403 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
They wouldn't be 8-bits per component if they were repeated like this then:
rrttrrtt Looks like 8 bits per component to me; the two red bits are stuck on the end of the tint bits to make a 4 bit number, then that's timesed by 17 to make it 8 bit (essentially copying the number onto the end of itself). This would give a full range from 0 to 255, (slightly) increasing the accuracy of the calculations compared to just timesing by 16 (0 to 240) or working with 4 bit values. I wish you had explained it as that would have been a lot more useful!! Each line of the 8-to-24 code gets the two tint bits, aligns the appropriate colour bits so they are next to them, then multiplies by 17 to bring them up to 8 bit numbers. The first line of the 24-to-8 code gets together the lower 6 bits of each component in order to calculate the tint with them, then shares them by 48 to reduce them to the 2 bit tint. The next three lines then get the appropriate high and low colour bits and shift them to the correct locations. |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #86405, posted by andreww at 09:18, 7/9/2001, in reply to message #86404 |
AA refugee
Posts: 555
|
Thanks, I didn't see how multiplying would effectively put a number onto the end of itself. That was the main problem. |
| |
[ Log in to reply ] |
| |
|
Richard Wilson |
Message #86406, posted by not_ginger_matt at 23:35, 4/2/2002, in reply to message #86405 |
Member
Posts: 63
|
The way I've always done it (Botkiller2 is an example with it's explosions) is to build a 256x256 LUT for each possible combination.
The table can be built easiest by using ColourTrans to do all the hardwork for you. Experimenting with the level of transparency should be fairly trivial as you can simply set up a program which will allow you to dynamically do this whilst plotting random sprites (I found 3:5 being quite nice if I recall correctly).
I've promised someone else that I'll dig out the BK2 and editor code, so email me if you want a copy when I find it. |
| |
[ Log in to reply ] |
| |
|
