Best Graphics Mode
Best Graphics Mode
I recently heard that VESA is slow. What would I be recommended to use as a faster Graphics mode?? The other question is where can I find good tutorials for bitmap text, eg creating and displaying?
Gizmic OS
Currently - Busy with FAT12 driver and VFS
Currently - Busy with FAT12 driver and VFS
Re: Best Graphics Mode
Hi,
The alternative (the best/fastest you can get) is using hardware acceleration as much as possible. There's 2 parts to this - using the video card's GPU (which is designed to be extremely good at this work) to do the drawing instead of the CPU (which is designed to be "general purpose", or reasonably good at everything), so that the CPU is free to do other work. The other part is using video display memory to cache graphics data, so that it can be used again and again (by the GPU) without repeatedly dragging the data over the slow PCI bus. The disadvantage here is that it involves writing a video driver for each video card.
Unfortunately, for some video cards it's impossible to get any of the information you need to write a driver. Worse, even if you can get the information the hardware itself is complex - I'd guess that it could take a year or more to write a very good video driver for one video card (and maybe 6 months to write a crappy video driver).
Writing video drivers just isn't practical in the beginning (when you're trying your hardest just to get an OS that can do something). This is why most people end up using VBE.
However, just because you start using VBE doesn't mean you need to be stuck with VBE forever. IMHO the important thing is to design a good "video device driver interface", so that (in the future) people can write very good video drivers for specific video cards that supports all of the features these video cards provide; so that your OS isn't trapped into using a VBE framebuffer forever due to it's initial design (and later, due to backward compatibility). In this case you'd need to decide on which features a video driver must provide (e.g. 2D line drawing) and which features are optional (e.g. 3D textured polygons with shadows and lighting), and then write code to handle the minimum feature set in software (on top of VBE/framebuffer, with no hardware acceleration).
Hopefully, applications will be able to ask which features your video supports, and then use your "video device driver interface" to draw everything, so that when you do start writing video drivers none of the applications need to be re-written to support hardware acceleration.
Note: it's actually not too hard to write the code for a graphics pipeline that handles (untextured) 3D polygons...
You could probably use any good language to do this (although to my amazement, some popular languages can't handle binary for numerical constants)..
For displaying bitmaps the basic idea is: for each bit that's set in the source bitmap, set the corresponding pixel to the foreground color in the destination bitmap. You really shouldn't need a tutorial for that...
The next step up is to support anti-aliased bitmap fonts, where each byte in the source bitmap determines how much the destination pixel should be tinted towards the character's foreground color. For e.g.:
In this case, you get the current destination pixel and split it into color components (red, green and blue). Then, for each color component, do something like "dest_red = (old_dest_red * (-opacity) + char_foreground_red * opacity) / MAX_OPACITY;", where "opacity" is the value you get from the character data above.
Cheers,
Brendan
I'm not entirely sure what you mean by "VESA is slow" - I'll assume you mean using VESA's VBE (where "VESA" is a standards organization, and VBE is their Video BIOS Extensions) to set a video mode and then using this video mode as a framebuffer (IE. a simple array of pixels) is slow. In this case, you're correct - it *is* slow. The advantage of VBE is that it is a standard - code that works with VBE works with all video cards that support VBE (which is basically all video cards, especially if you're using VBE 2.0 and don't rely on VBE 3.0).System123 wrote:I recently heard that VESA is slow. What would I be recommended to use as a faster Graphics mode??
The alternative (the best/fastest you can get) is using hardware acceleration as much as possible. There's 2 parts to this - using the video card's GPU (which is designed to be extremely good at this work) to do the drawing instead of the CPU (which is designed to be "general purpose", or reasonably good at everything), so that the CPU is free to do other work. The other part is using video display memory to cache graphics data, so that it can be used again and again (by the GPU) without repeatedly dragging the data over the slow PCI bus. The disadvantage here is that it involves writing a video driver for each video card.
Unfortunately, for some video cards it's impossible to get any of the information you need to write a driver. Worse, even if you can get the information the hardware itself is complex - I'd guess that it could take a year or more to write a very good video driver for one video card (and maybe 6 months to write a crappy video driver).
Writing video drivers just isn't practical in the beginning (when you're trying your hardest just to get an OS that can do something). This is why most people end up using VBE.
However, just because you start using VBE doesn't mean you need to be stuck with VBE forever. IMHO the important thing is to design a good "video device driver interface", so that (in the future) people can write very good video drivers for specific video cards that supports all of the features these video cards provide; so that your OS isn't trapped into using a VBE framebuffer forever due to it's initial design (and later, due to backward compatibility). In this case you'd need to decide on which features a video driver must provide (e.g. 2D line drawing) and which features are optional (e.g. 3D textured polygons with shadows and lighting), and then write code to handle the minimum feature set in software (on top of VBE/framebuffer, with no hardware acceleration).
Hopefully, applications will be able to ask which features your video supports, and then use your "video device driver interface" to draw everything, so that when you do start writing video drivers none of the applications need to be re-written to support hardware acceleration.
Note: it's actually not too hard to write the code for a graphics pipeline that handles (untextured) 3D polygons...
For creating bitmaps, I find it's easy to ask the BIOS for them. Alternatively you could write a utility, or use assembly. For example:System123 wrote:The other question is where can I find good tutorials for bitmap text, eg creating and displaying?
Code: Select all
;Data for the character 'A'
db 00011000b
db 00111100b
db 01100110b
db 01111110b
db 01111110b
db 01100110b
db 01100110b
db 00000000b
;Data for the character 'B'
db 01111100b
db 01111110b
db 01100110b
db 01111100b
db 01100110b
db 01100110b
db 01111110b
db 01111100b
db 00000000b
For displaying bitmaps the basic idea is: for each bit that's set in the source bitmap, set the corresponding pixel to the foreground color in the destination bitmap. You really shouldn't need a tutorial for that...
The next step up is to support anti-aliased bitmap fonts, where each byte in the source bitmap determines how much the destination pixel should be tinted towards the character's foreground color. For e.g.:
Code: Select all
;Data for the character 'A'
db 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00
db 0x00, 0x00, 0xFF, 0xE0, 0xE0, 0xFF, 0x00, 0x00
db 0x00, 0xBF, 0xFF, 0x00, 0x00, 0xFF, 0xBF, 0x00
db 0x00, 0xFF, 0xFF, 0x7F, 0x7F, 0xFF, 0xFF, 0x00
db 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00
db 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x00
db 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0xFF, 0x00
db 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Best Graphics Mode
Brendan you were amazing as usual.
The man who follows the crowd will usually get no further than the crowd.
The man who walks alone is likely to find himself in places
no one has ever been before.
The man who walks alone is likely to find himself in places
no one has ever been before.
Re: Best Graphics Mode
Am I the only one to find this statement a bit dubious?abuashraf wrote:Brendan you were amazing as usual.
JAL
Re: Best Graphics Mode
Thanks Brendan, That is all I was looking for. Since reading your reply I have gotten my kernel to print out strings in VESA mode. All I need to know now is how to change the font.
Gizmic OS
Currently - Busy with FAT12 driver and VFS
Currently - Busy with FAT12 driver and VFS
Re: Best Graphics Mode
I agreejal wrote:Am I the only one to find this statement a bit dubious?abuashraf wrote:Brendan you were amazing as usual.
JAL
Jules
Re: Best Graphics Mode
I saw it too, but resisted a reply before (didn't want to lower the tone!). Something along the lines of "...and how was it for you"Am I the only one to find this statement a bit dubious?
Seriously, though - nice full reply from Brendan.
Re: Best Graphics Mode
No guys,I'm talking seriously,Brendan's reply was wonderful,as most of his replys
The man who follows the crowd will usually get no further than the crowd.
The man who walks alone is likely to find himself in places
no one has ever been before.
The man who walks alone is likely to find himself in places
no one has ever been before.
- Steve the Pirate
- Member
- Posts: 152
- Joined: Fri Dec 15, 2006 7:01 am
- Location: Brisbane, Australia
- Contact:
Re: Best Graphics Mode
This is something that I really want to avoid when it comes to starting my GUI - I'd prefer to portFreetype, to get nice looking fonts at any sizes.System123 wrote:The other question is where can I find good tutorials for bitmap text, eg creating and displaying?
Re: Best Graphics Mode
Agreed, but for starters, bitmapped fonts are a lot easier to implement.Steve the Pirate wrote:This is something that I really want to avoid when it comes to starting my GUI - I'd prefer to port Freetype, to get nice looking fonts at any sizes.
JAL