Dark Bit Factory & Gravity
PROGRAMMING => Freebasic => Topic started by: Xalthorn on July 12, 2008
-
Just messing around with an idea really, and it seems to have worked. I threw a scroller in as force of habit. The source is included so you can see what I was messing around with.
(EDIT: Oopsie, forgot to put the source in the archive)
-
I think this is the first time Ive ever seen someone code their own transparency routine, at least tranparency that is not always 100% I havent spent much with FB and the last time I used it was merely to have a look at what assembler FB would spit out, so I dont really understand how FB manages its functions. Can this work with non primary colours like orange and purple? and can the background be seen through the circles?
-
Again - nice stuff - thanks for the source - and the notation - makes it simple to find out how you do certain things.
Andy
-
I think this is the first time Ive ever seen someone code their own transparency routine, at least tranparency that is not always 100% I havent spent much with FB and the last time I used it was merely to have a look at what assembler FB would spit out, so I dont really understand how FB manages its functions. Can this work with non primary colours like orange and purple? and can the background be seen through the circles?
This is a completely cheating hack, it doesn't do any clever transparency calculations. That's my next trick (hopefully).
Also, it doesn't use any functions from FB, it's all done with buffers.
The code holds four screen buffers, one for display, one for red, one for green, and one for blue.
It loads a greyscale pattern and then strips the red, green, and blue portions out into separate patterns by ANDing the pattern with a full red, green, or blue colour value and storing them as a full colour code.. Being a greyscale pattern, these values are going to be equal.
Three of these patterns are then moved around the screen. Each one is rotated and written directly to the appropriate coloured buffer. The main display buffer is still pure black with no colour.
The three coloured buffers are then OR'd to the display buffer which nicely merges the colours as appropriate.
The reason it works so nicely is because with an RGB colour value, we have a 24 BIT value laid out as follows:
RRRRRRRRGGGGGGGGBBBBBBBB
As the colours don't overlap, and the colour buffers hold only the appropriate colours, in a 24 BIT number (okay, 32 but that's not important) doing a logical OR mixes them properly. For example, here are three sample values in the colour patterns.
R:110110100000000000000000
G:000000001110110100000000
B:000000000000000010101101
OR ing these together would give us
C:110110101110110110101101
Which is a tidy mix of the three colours. I hope that made some sense...
As it stands at the moment, this routine only mixes the three primary colours onto a black background. If they were mixed onto a background, they would overwrite the background with ugly squares. It's cute, but limited.
-
I couldn't resist having a play with a different image....
-
Rotation and transpareny fx is very well done. I prefer the
skull image for an intro! Time to compile your next complete
intro/demo ;-)
-
Skulls definately look better than the wheels, it's a nice effect :)
Nicely done Xal.