I just wonder if i can acomplish a sort of effect in mode13h (yeah i know its dead but im making some small, fun stuff) where you can see stuff below, for example a picture...<br>
How can i plot a (fake-)semi-transparent<br>
pixel?<br>
Anyone know, or got a tut for it? PLEASE drop me a mail or an answer here please :)<br>

Oh come now... it would have been easier to think it over than to post a message.<br>
<br>
with 256 colours you can have any 16 colours on any other 16 colours without haveing to change your palette.<br>
<br>
Grab a pen and paper and work it out... <br>
<br>
then again.. youve probably already found one of the many x-fade demos or such out there...<br>



URL:members.tripod.com/cloubser

You don't have to split the palette up in 16 colour pieces. You just load your palette into an array of (256*3) bytes (1-Red, 1-Green, 1-Blue). Then you should run thru every colour and try to calculate the best matching colour. Usually the formular: Colour / 2 works, but it's NOT the ideal.<br>
<br>
If you're serious then drop by the TMB site where I have a VERY usefull section about these things. Download DirectQB which is ment to be used with QuickBasic but is written in 100% assembler. DirectQB has some VERY usefull routines to find the right transparent colour and such.<br>
<br>
<br>
Enjoy,<br>
AM<br>
TMB Lead programmer<br>
www.crosswinds.net/~tmb

Hello,<br>
<br>
First of all I want you to know something. Mode 13H is not dead !!! hehe... Well I like to code in it because it is like you said, FUN ! Plus it can lead to other things, like Hand Held Game programming or PIC programming...<br>
<br>
>>>: I just wonder if i can acomplish a sort of effect in mode13h (yeah i know its dead but im making some small, fun stuff) where you can see stuff below, for example a picture...<br>
<br>
Well, I'm not sure if this is exactly what you need but a good effect is to DEC the pixels in the box region that you wish to cover which produces a 'darker' area onto which you can then print lighter text to get a contrast. Of coarse your palette has to be organised in such a way to make this work effectivly but it can be done. You can put a simple check in to see if the color you are working on is at a certain color level and if it is then don't change that pixel.<br>
<br>
If you want a small code demo let me know,<br>
Lance

All I hear is people suggesting palette quanticization and color matching. There's another way, using lookup tables. I got the initial idea from a posting on Flipcode.com and worked out the implementation on paper during my boring classes :) My compiler's broken, so I don't know how good this'll look, but the idea is good.
Every color is composed of 3 components, RGB. Now make those XYZ and make a 3 dimensional lookup table: colortable contains a byte index into the VGA palette, which wil be set up with a formula so that the color closely approximates the color requested.
Here's the potential problem- the palette gives you 256 entries. Assuming the lookup table is a cube, you can have a max of (256)^(1/3) intensities per component. With 6 intensities you get 6^3=216 colors reserved for the lookup table, with 256-216=40 extra colors that can be modified. This gives you the color-blending capabilities of high-color mode with the palette tricks availible in mode 13. Unfortunately, if you have 6 intensities to get between 0 and 63, the values would go {0,13,25,38,50,63} That means that if you specify
RGB(6,45,60) you'll actually get RGB(0,50,63). Again, I don't know how this'll look.
This is getting long, so I'll leave the details of the pixel routines to the reader's imagination. A hint: If you're writing a "dword GetPixel(x,y)" function that returns the RGB values of a pixel in format {RRRRRRRR:GGGGGGGG:BBBBBBBB:AAAAAAAAA}
You'll want to make a dword lookup table 0..255 containing this value so you don't need to read from the palette registers every time you draw a transluscent pixel!

I just finished writing the source to do just that, and it looks fine! I just posted it, and the submission page said it'd be availble under
Graphics->GraphicsEffects:Colors->"FakeColor.zip"
in 2 weeks or less. Email me if you need it sooner.
Ignore my previous ranting- I realized as I was writing it that it *is* basically palette quanticization :)
BTW, mode 13 isn't dead! You'll never be good at DirectX or OpenGL 'til you know the *theory*, and the best way to learn that is in 13h!


: I just wonder if i can acomplish a sort of effect in mode13h (yeah i know its dead but im making some small, fun stuff) where you can see stuff below, for example a picture...
: How can i plot a (fake-)semi-transparent
: pixel?
: Anyone know, or got a tut for it? PLEASE drop me a mail or an answer here please :)

>>(yeah i know its dead but im making some small, fun stuff)

Maybe its dead, but its only real mode, those things as VESA SVGA 24-bit ultra-mega-super RGB modes are STUPID. VERY stupid. I guess the guy who started this aproach is a real asshol, and does not deserve to even touch a computer. Bank switching.. Damn.. Whats wrong with addressing whole screen via 32 bits of EDI or whatever? Noo, segments are nice things, so why not contaminate a screen with it?

(by the way, everything is in wise planing of a palette, because many things you do in 13h mode are imitations of RGB coloring)

bye