Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

semi-transparent stuff in mode13h, can it be done?

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 :)




Comments

  • Oh come now... it would have been easier to think it over than to post a message.



    with 256 colours you can have any 16 colours on any other 16 colours without haveing to change your palette.



    Grab a pen and paper and work it out...



    then again.. youve probably already found one of the many x-fade demos or such out there...




    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.



    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.





    Enjoy,

    AM

    TMB Lead programmer

    www.crosswinds.net/~tmb


  • Hello,



    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...



    >>>: 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...



    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.



    If you want a small code demo let me know,

    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[blue][green][red] 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 :)


  • CveleCvele Posts: 96Member
    >>(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

Sign In or Register to comment.