Hi,
OmeletHopper wrote:
I've got to thank you for your fast reply. The different font lookup table you posted seems too be working great! However, the function you posted I kept having issues with. I made a few modifications to my existing function, and you can see what I've got from the screenshot. Seriously, thanks!
Quote:
I'm not entirely sure if you're using "16 colours, 4 bits per pixel" or "65536 colours, 16 bits per pixel". For 16 colour modes the frame buffer is extremely different (arranged as four monochrome planes) and the example code in the wiki wouldn't make sense.
I honestly don't know which one I'm using.
You can't write correct code without knowing how the video card expects a pixel to be represented. How a pixel is represented includes its size (how many bits) it's location in the frame buffer (e.g. planar vs. "packed pixel") and what each bit means (e.g. if it's an index into the palette or if it's a direct RGB value, and if it is a direct RGB value which bits represent what - e.g. if the 16 bits are "rrrrrggggggbbbbb" or "bbbbbggggggrrrrr" or something else).
Trying to work backwards from the pictures, there's a few things that I've noticed.
First; both of the pieces of code you've posted have almost exactly the same calculation controlling where pixel data is stored. Specifically, these lines are identical in both versions:
Code:
void kernelDrawChar(uint32_t character, uint16_t foreground, uint16_t background) {
char *where = &Framebuffer[FramebufferPosition];
for (row = 0; row < 16; row++) {
*(uint64_t *)where = ...
where += FramebufferPitch;
}
FramebufferPosition += FontWidth;
}
However, despite using exactly the same calculation for "where", the screenshots/pictures are showing that both versions are writing data in completely different places on the screen. That doesn't make any sense (unless there's bug/s or differences somewhere else).
Second, for the first picture (I opened it in GIMP and blew it up to take a close look) characters are 5 pixels wide and look like several columns of pixels are being skipped in each character. That indicates something is wrong with the calculation of "where". Maybe "FontWidth" is 5 when it should be 8; and maybe "FontWidth" is 8 but "Framebuffer" is an array of bytes or a pointer to bytes (and not an array of "uint16_t" or pointer to "uint16_t") and you're doing "FramebufferPosition += FontWidth;" when you should be doing "FramebufferPosition += FontWidth * bytes_per_pixel;", and then doing an extra "FramebufferPosition += 2;" somewhere else (in the code that calls your "kernelDrawChar()" function?) to make it add up to 10 bytes (or 5 pixels).
Third; if you are using a "2 bytes per pixel" video mode (either 15 bits per pixel or 16 bits per pixel) there's multiple other things wrong (e.g. the shift counts in "uint64_t packed_foreground = (foreground << 24) | (foreground << 16) | (foreground <<
| foreground;").
Based on all of this (and that changing the "font_data_lookup_table" to suit 16 bits per pixel got rid of the blue/yellow colours you were getting before); I'd say that it is a 16 bit per pixel video mode, and while you were trying to fix symptoms of the "FramebufferPosition += FontWidth" bug you made everything else wrong for 16 bits per pixel (and "more right" for the 8 bits per pixel code you started with that at least gave you something that vaguely looked like characters before).
Cheers,
Brendan