The Place to Start for Operating System Developers
http://f.osdev.org/
I think Bresenham's books and resources might be a good recommendation as well, that is, if you can get your hands on them.Brendan wrote:Mostly, you should get acceptable results on Bochs (which is much slower than real hardware) in all video modes without any hardware acceleration; and if you don't then your code needs to be optimised more...
Thanks!quanganht wrote:You have some really good snipets, Brendan! It would definetely help me alot later. Thanks
Code: Select all
void blit_buffer_to_video(void) {
uint32_t offset = 0;
void *dest_address = video_display_memory;
void *temp_dest_address;
uint32_t next_dword;
for(y = 0; y < screen_height; y++) {
if(line_changed_flags[y] != 0) {
temp_dest_address = dest_address;
for(x = 0; x < screen_width; x += 4) {
next_dword = new_buffer[offset];
if( current_buffer[offset] != next_dword ) {
current_buffer[offset] = next_dword;
*(uint32_t *)temp_dest_address = next_dword;
}
offset++;
temp_dest_address += 4;
}
line_changed_flags[y] = 0;
} else {
offset += screen_width;
}
dest_address += bytes_per_line;
}
}You might want to start with this explanationStephanVanSchaik wrote:I think Bresenham's books and resources might be a good recommendation as well, that is, if you can get your hands on them.
Right on, Brendan, that's exactly what I'm doing (I'll be sure to change that). I do know how to implement the Bresenham line algorithm, I just haven't done it yet, as I didn't yet need it.Brendan wrote:I assume your using something like "putpixel(x, y, colour)", where every time you call putpixel it calculates the address of the pixel in display memory? That's insanely bad. You should only calculate the position of the starting pixel, and then update this address for each pixel you draw.
I get around 32 frames per second in 640x480x24 screen resolution in MS Virtual PC (the emulator I use). Emulators are always slower than real hardware, as are code interpreters and virtual machines.Brendan wrote:Mostly, you should get acceptable results on Bochs (which is much slower than real hardware) in all video modes without any hardware acceleration; and if you don't then your code needs to be optimised more...
If you have a CPU capable of Intel-VT or AMD-V, then try VMware instead. It is way more better than VirtualPC (personally, I think everything that come from MS is shitty)DavidBG wrote:I get around 32 frames per second in 640x480x24 screen resolution in MS Virtual PC (the emulator I use). Emulators are always slower than real hardware, as are code interpreters and virtual machines.
Recent versions of VirtualPC require Intel-VT or AMD-V. VirtualBox will use it if it's present but work without it. Both are free.DavidBG wrote:I looked at the VMware site but it seems VMware workstation is a trial version, and I don't want to buy a virtual machine at the moment. Correct me if I'm wrong.
24-bpp modes take some extra skill to optimise because it's harder to avoid unaligned writes. Mostly you want to write 4 pixels (3 aligned dwords) to display memory at a time. I'd be tempted to use a 32-bpp buffer (so you don't need to mess about with alignment in the routines that draw stuff in the buffer and can re-use the same code for 32-bpp), and then do some bit shifting when copying the buffer to display memory (so that writes to video display memory are still aligned properly).DavidBG wrote:I get around 32 frames per second in 640x480x24 screen resolution in MS Virtual PC (the emulator I use). Emulators are always slower than real hardware, as are code interpreters and virtual machines.