OSDev.org

Guis, I have some functions that detect video mode avaiable then you can choose like startx xxx, so my biggest problem is...

at some pc, we cannot use 32bpp then I have to use 24bpp and others one we

use 16bpp. now is the point...

for:

8bpp -> byte *screen;
16bpp -> word *screen;
24bpp -> byte *screen;
32bpp -> dword *screen;

but at all functions I have something like

putpixel(byte *screen, dword x, dword y, dword color);

at this first argument " byte *screen " how can use a functions that works

with all kinda pointers, like I wrote above?

could anyone helps me, please ?

Let's start with how putpixel knows or can know what the bitdepth is? it can't be embedded in the type since 8bpp and 24bpp are both accessed per byte...

My "put pixel" function has, effectively, the following definition (on the kernel side, if you go looking for code you won't find this line anywhere - it's modified): PixelFormat is an enum within the Graphics namespace (PedigreeGraphics for applications) and I've written code to convert to and from a variety of 16-, 24-, and 32- bit formats. Because the format is specified as an argument to the function, my code can easily determine how to access the buffer. All of my graphics routines specify a source format so that the information making it to the screen is always the screen's native format.

As an added caveat, you may need to track the number of "bytes per pixel" that the framebuffer utilises - it may not always equal the bit depth divided by 8. For example, I found the vmware graphics card likes to use 4 bytes per pixel even when the actual depth it's using is 24-bit. This obviously helps with alignment and performance, but can catch you by surprise if you're not ready for it. Same deal with the number of bytes per line.

Hi,

Drawing everything directly into display memory is slow (the CPU can access RAM much faster than it can access the video card's memory) and messy (it complicates a lot of code, and causes unwanted tearing/shearing effects). This is made even worse when you consider 24-bpp modes, where writes are often misaligned.

To avoid the tearing/shearing effects you want to draw everything in a buffer in RAM, and then copy this buffer to display memory once everything is drawn. To avoid complicating all of the routines that draw things (pixels, lines, boxes, characters, etc) you can pick a standard pixel format (e.g. 32-bpp) and use that for the buffer and all your drawing routines. This means that while you're copying from the buffer to display memory you also convert from 32-bpp to whatever the video mode wants.

The conversion isn't really too hard (it's mostly just bit-shifting and/or lookup tables), and the CPU may be able to do the conversion while waiting for writes to display memory to complete (it can be just as fast as not doing any conversion). The only real problem is planar video modes (e.g. 4-bpp) where you want to minimise I/O port writes needed to switch between planes, and may need to convert the 32-bpp data into several "1 bit per pixel" bitmaps so that you can select the first plane then send the entire bitmap for the first plane, then switch to the second plane and send it's entire bitmap, etc.

Also, for 8-bpp I cheat. I set the palette to "2 bits for blue, 3 bits for green, 3 bits for red" format, so that conversion from 32-bpp to 8-bpp is just bit shifting. There's more complex ways of doing it that give much better results (e.g. calculate the best palette to use and convert pixels to that palette, before re-programming the palette and copying the data to display memory) but that is time consuming and only works if you can still use the BIOS/VBE functions for setting the palette.

Of course this is only the beginning - once you've got the framework in place, there's no reason that you can't add support for oversampling (e.g. have a 1280 * 960 buffer that's converted down to 640 * 480 to get simple anti-aliasing), or add dithering to the conversion (to give the illusion of more colours than the video mode supports), or implement "hue shifting" (for colour-blind people), etc.


Cheers,

Brendan

Brendan wrote:only works if you can still use the BIOS/VBE functions for setting the palette.

I would assume that normal VGA-register-access palette setting would work as well with most cards in higher-resolution-than-VGA modes?

EDIT: In fact, I wouldn't be surprised if most BIOSes do not take VESA modes into account anyway.


JAL

Hi,

jal wrote:

Brendan wrote:only works if you can still use the BIOS/VBE functions for setting the palette.

I would assume that normal VGA-register-access palette setting would work as well with most cards in higher-resolution-than-VGA modes?

There's (at least) 3 cases to consider:

• 6-bit only DAC: In this case the DAC is only capable of handling 6-bits per colour component (e.g. in 8-bpp modes you get to choose 256 colours out of 262144 possible colours). This is probably very rare now (I'd assume any video card that supports 24-bpp or 32-bpp also has a better DAC).
  Dual mode DAC: In this case the DAC hardware itself supports multiple widths, and typically supports both 6-bit mode (for VGA compatibility) and 8-bit mode (e.g. in 8-bpp modes you get to choose 256 colours out of 16777216 possible colours). In this case VBE function 0x08 allows you to reconfigure the DAC hardware.
  8-bit only DAC: In this case the DAC is only capable of handling 8-bits per colour component. For compatibility, a 6-bit DAC is emulated by software (for the legacy VGA "set palette" functions, and VBE function 0x09 when VBE is the 6-bit DAC format is requested, the video card's ROM converts from 6-bit to 8-bit and loads 8-bit data into the DAC), and VBE function 0x08 only enables/disables the conversion done by software.

For a modern video card, for all of these cases there's no guarantee that the old VGA registers work in SVGA video modes. If the old VGA registers do happen to work, then you're got an extra problem if video card has an "8-bit only DAC" and you're giving it 6-bit palette data.

I guess it also depends on how good "good enough" is. If using the old VGA registers works on 51% of video cards, then you could say it works on most video cards; but for me, even if it works on 100% of current video cards it may not be "good enough", because it's still possible for a video card to be created in the future that fails...


Cheers,

Brendan

Brendan wrote:8-bit only DAC: In this case the DAC is only capable of handling 8-bits per colour component.

Just being curious, did you ever encounter a card that wasn't VGA compatible on this level? I could imagine cards that extend the 6-bit with 2 additional bits (e.g. the two upper bits of the VGA palette registers) with some "unlock" bit in some config register, but I've never heard of non-VGA (on a hardware level) compatible cards - well, safe the odd 8514/A or the like.

because it's still possible for a video card to be created in the future that fails

True, but then again, no future card is guaranteed to support VESA either :).


JAL

Several of the cards I have encountered do not have any operational VGA circuitry in their native modes, like the old Voodoo 1, also, most cards allow VGA accesses to be disabled entirely even if the palette would normally work.

Combuster wrote:Several of the cards I have encountered do not have any operational VGA circuitry in their native modes, like the old Voodoo 1, also, most cards allow VGA accesses to be disabled entirely even if the palette would normally work.

The Voodoo Graphics was always (intended, at least) to be used in combination with a separate 2D card; hence the VGA pass through.

Hi,

jal wrote:

Brendan wrote:8-bit only DAC: In this case the DAC is only capable of handling 8-bits per colour component.

Just being curious, did you ever encounter a card that wasn't VGA compatible on this level? I could imagine cards that extend the 6-bit with 2 additional bits (e.g. the two upper bits of the VGA palette registers) with some "unlock" bit in some config register, but I've never heard of non-VGA (on a hardware level) compatible cards - well, safe the odd 8514/A or the like.

My early boot code has always relied on standardised software interfaces (e.g. VBE), and I wouldn't notice if any of the video cards I've used were actually VGA compatible (at the hardware level) or not.

Of course almost all PCI video cards are capable of operating in a "non-VGA" mode, and can being installed as the second/third/fourth video card (where they can't use the VGA I/O ports, etc because they're reserved for the primary video card). The way my boot code works, there's no reason that "something" (e.g. a previous instance of the OS) couldn't tell the boot code to use a framebuffer that is on the second/third/fourth video card.

jal wrote:

because it's still possible for a video card to be created in the future that fails

True, but then again, no future card is guaranteed to support VESA either .

That's not unlikely (depending on how far into the future). Eventually, after UEFI has taken over, everyone might be able to forget about all the backward compatibility hacks in hardware (including things like the special legacy I/O port forwarding in PCI bridges, and legacy modes in video cards and disk controllers).


Cheers,

Brendan

Brendan wrote:Eventually, after UEFI has taken over, everyone might be able to forget about all the backward compatibility hacks in hardware (including things like the special legacy I/O port forwarding in PCI bridges, and legacy modes in video cards and disk controllers).

Ah, what a perfect world that would be! And in that perfect world we'd also have x86 CPUs that are native 64-bit, without any legacy support for real mode and 32-bit.


JAL

berkus wrote:And if we didn't have any x86 CPUs at all in this future, ah, what a perfectly perfect world that would be!

That I cannot tell. Never worked with ARM, PowerPC or MIPS, let alone more obscure stuff.


JAL