   Gap between mode 13h and modern graphics libs
  Hi all!After a long time of not beeing active in this forum, I think I have now some time to go on with my hobby game programming. So, hello again...I come back with this question:I know (a little bit ;-)) about programming graphics in assembler vie mode 13h.And I know programming graphics with modern libraries (like DirectX).Butt what I am missing are some resources about the gap between these two (e.g. how to programme higher resolutions and on modern graphics cards) _directly_.Or in other words: How do modern libraries get access to the video cards?Any information or links about this would be great.Thanks in advance   
  Modern graphics APIs, like DirectX and OpenGL have a component that is provided by the drivers. The drivers, as you may have guessed, are provided by the manufactuerers, and hence they know how the card works...sometimes.Since the actual operation of the cards is usually a closely guarded secret, hidden behind several layers of security and a few barney dolls, most people can't directly access the hardware, unless they happen to have the power of Open Source, and captain planet...Direct access to the hardware doesn't provide any real advantages to you, as you would end up having to replace everything that the driver does, which means you would have to understand the card at least as good as the engineers who designed it in the first place, something akin to knowing the mind of Oluseyi...There really is no step between the two, except for SVGA, which does have a standard that is followed "somewhat" by cards, haven't seen a copy of SVGA information in a long time though...   ;Quote:Original post by WashuModern graphics APIs, like DirectX and OpenGL have a component that is provided by the drivers. The drivers, as you may have guessed, are provided by the manufactuerers, and hence they know how the card works...sometimes.Since the actual operation of the cards is usually a closely guarded secret, hidden behind several layers of security and a few barney dolls, most people can't directly access the hardware, unless they happen to have the power of Open Source, and captain planet...Direct access to the hardware doesn't provide any real advantages to you, as you would end up having to replace everything that the driver does, which means you would have to understand the card at least as good as the engineers who designed it in the first place, something akin to knowing the mind of Oluseyi...There really is no step between the two, except for SVGA, which does have a standard that is followed "somewhat" by cards, haven't seen a copy of SVGA information in a long time though...The VESA "standard" is supported by most cards, even modern ones, though modern systems won't allow you to access it. so you would need to code for an older system such as MS-DOS which may or may not make it close to impossible to run in  newer versions of windows (dosbox might be a solution but its support for VESA isn't the best (and it definitly isn't fast)finding tutorials and information about the subject is fairly easy. (just search for VESA tutorial or similar on google).as for accessing the more modern graphic card features you're out of luck, both nvidia and ati seems to be reluctant to release much information to the general public about the more specific details however there are some opensource drivers for some older ATI cards that work well enough.   ;  A short history of graphics card programming:Firstly, "VGA". What happens when you are programming mode 0x13 in DOS?You issue an interrupt which calls a VGA BIOS function to set the mode. This code writes to the hardware registers on the card, telling it (usually in complex, possibly hardware specific terms) the new screen resolution, color depth etc. Then, part of your address space (starting at 0xa0000) is mapped so that accesses to that area go directly to the graphics hardware. You write a byte, and a pixel comes up on the screen.The next step up is "SVGA" - for resolutions higher than 720x480, and color depths higher than 8-bit.The problem here is that there was initially no standard for SVGA. You basically had to know exactly what the registers were, and program these manually. There are documents available here containing register descriptions. Don't expect them to be easy to understand.With VGA, the BIOS routines mask all of this trouble for you. So, the VESA VBE (video BIOS extensions, IIRC) was created to bring about a similar interface as the VGA BIOS - an easy way to set modes etc. You can find information on that here.After (or alongside) SVGA came the "2D accelerators".Imagine the effort required to draw a large rectangle, or to perform a block copy, on a standard VGA board. A loop full of memset/memcpy calls are required. The 2d accelerators could perform simple operations like this themselves, whilst the CPU got &#111;n with more important work. You gave the video card a command (by writing to registers) and it carried it out.<br><br>A modern day graphics card is not fundamentally different - you write to the registers and it performs a task - its just that the tasks which can be performed are considerably more complex.<br><br>The difference with programming modern cards is that you cannot access the registers yourself. This is nothing to do with the video card, rather, a modern operating system prevents this in order to stop you from maliciously (or accidentally) messing up the display. Instead, you send commands (through an API such as GDI, DirectDraw or OpenGL) and your commands are sent to the video driver, which in turn sets the registers itself.<br>If you had the register descriptions (which basically means you have to work for the graphics card manufacturer) and you booted into MS-DOS (or wrote a Windows driver), there would be nothing stopping you from writing to the registers yourself and bypassing any API completely.   ;Quote:Gap between mode 13h and modern graphics libsHoly freaking crap!! No words or pictures can explain this, but perhaps this gap would give you clue..   ;  Thanks for your great replies.   ;Quote:...After (or alongside) SVGA came the "2D accelerators".Imagine the effort required to draw a large rectangle, or to perform a block copy, on a standard VGA board. A loop full of memset/memcpy calls are required. The 2d accelerators could perform simple operations like this themselves, whilst the CPU got &#111;n with more important work. You gave the video card a command (by writing to registers) and it carried it out…<br><!–QUOTE–></td></tr></table></BLOCKQUOTE><!–/QUOTE–><!–ENDQUOTE–><br><br>no, not exactly:<br>on the most recent SVGA boards supporting VESA2.0 and above (this includes your GT6600 as well) you have a linear frame buffer - but, &#111;nly in protected mode making the application incompatible with WindowsXP 's commandline/dosbox or other emulator software.<br>the website delivering VESA3.0 information (current version,IIRC) is still alive out there &#111;n the internet, just google for it.<br>and: the registers you need to activate higher resolutions with a linear framebuffer are also standarized. the full VESA spec. will tell you all this stuff.;Original post by Alex BakerQuote:and: the registers you need to activate higher resolutions with a linear framebuffer are also standarized. the full VESA spec. will tell you all this stuff.So, are all graphics cards compatible to VESA standard?;Quote:and: the registers you need to activate higher resolutions with a linear framebuffer are also standarized.No, the registers are highly hardware dependent. The VESA VBE gives you a standardised layer of abstraction above the registers.Quote:So, are all graphics cards compatible to VESA standard?Just about - even a 10 year old laptop I have here supports VESA 1.2.   ;Quote:Original post by WildWestSo, are all graphics cards compatible to VESA standard?About everything, but what use is it? 2D is much faster in 3D with modern and not-so-modern cards anyway. The OpenGL and Direct3D APIs give you a easy to use access to the GPU's rasterization capablities, which are far more powerful than directly manipulating the frame buffer.   