I'm interested in doing some graphics programming, but I want to make sure I understand the different options available before doing some hard research. Here's what I know, and a few questions:

1) "Mode 13h"/VGA is from 16-bit DOS and basically is only good for learning or slow computers
2) SVGA/VESA 2.0 uses higher resolutions and colors
3) DirectX is for Windows-based platforms and can do 2D and/or 3D graphics
4) OpenGL can be used across different platforms and can do 2D and/or 3D graphics
5) There is no consensus on whether OpenGL or DirectX is better

Questions:
1) Does VESA 2.0 work in 16-bit or 32-bit DOS, or protected mode, or what? I'm still a bit confused on the history of DOS, 16-/32-bit, and Protected Mode.
2) Can VESA 2.0 work under Windows, or more specifically,
3) Is it possible to compile a VESA 2.0 program using Masm32?
4) Without using OpenGL or DirectX, is there a way to directly access the screen under Windows? How difficult would this be to program?

That's basically it...I might have more to ask later though.

Thanks in advance!

-- Sirchess --
Posted on 2003-04-24 17:47:06 by sirchess2
There's a lot of fuss about OGL vs D3D, but basically as I understand it, D3D is somewhat more explicit than OGL, requiring OGL drivers to be miniature pieces of AI :). Which to choose depends on a lot of things (target video cards, operating system, personal taste), but for modern cards either should be equally good.

I think OpenGL lacks native methods of getting some information like video card memory size and such? Correct me if wrong.

VESA works on real mode, however once you have set your mode with a linear framebuffer, you don't need more vesa calls. This vesa init can either be done before rm->pm switch, or in a vm86 wrappe call. If you need to use bank switching rather than LFB, VESA should offer protected mode code which you can copy to your own 32bit area. Can't remember if that was introduced in vesa 1.x or 2.0, nor whether it's required for cards to supply it.

You can compile vesa program with masm (notice masm == the assembler, masm32 is the package by hutch), but vesa programs generally don't run under windows. It's usually very easy to port them use use DirectDraw, though - a framebuffer is a framebuffer, even if the init code is different.

4) - no. No direct access. Forget about it. Bad. Fooo boy :)
Posted on 2003-04-24 18:05:51 by f0dder
Ok so if I want to do high-speed/3D graphics in Windows I probably want to go DirectDraw...

As I understand it, D3D can be used to do 3D graphics, but I suppose it's also possible to find/write your own 3D graphics routines once you get your buffer...is this advisable, or is D3D the "fastest you can get"?
Posted on 2003-04-24 18:47:07 by sirchess2
You can write your own graphics routines however you want and, yes, you can acquire a buffer to write to. Using D3D will assure you have access to whatever hardware is available on the graphics card to speed things up. But using d3d isn't always easy because there is a bit of 'setup' to use each function. It's much better than it used to be though. Therefore, using the d3d interface to hardware should be faster than writing your own except in cases where the setup takes more time than the actual writing.
Posted on 2003-04-24 19:09:56 by drhowarddrfine
Ok thanks...looks like I'll be doing some research into DirectDraw and Direct3D sometime soon :)

(P.S. - anyone else feel free to comment further...i'll still check this msg)
Posted on 2003-04-24 20:24:27 by sirchess2
By the way, do not confuse directdraw with d3d as if it was different like gdi is different. Directdraw, IIRC, was the original name for a portion of directx when it first came out. You should think of d3d as one package.
Posted on 2003-04-24 20:47:17 by drhowarddrfine
DirectX is a technology family.
DirectInput, DirectPlay (hrm, I wouldn't use this), DirectDraw (removed in DX8, now you "should" use D3D for everything), Direct3D, DirectMusic (cool dynamic music stuff).

On modern hardware, D3D will run much much faster than any 3d routines of your own, and you can do some pretty cool stuff if your hardware has vertex/pixel shaders.

For 2D-only stuff, I'd stick to the DirectX7 DirectDraw interface - all DX interfaces (I suppose) are still available when you install the newer versions; the only troublesome part might be getting the old SDKs.

OpenGL programming will typically be seen as easier than Direct3D, since OGL has standard function calls, while DX is COM based - something that until recently was very bothersome to deal with for asm programmers, and still is more bothersome than highlevel languages (though work by Ernie and others have made it lots easier).
Posted on 2003-04-25 01:48:53 by f0dder
Originally posted by f0dder
[...] DX is COM based - something that until recently was very bothersome to deal with for asm programmers, and still is more bothersome than highlevel languages (though work by Ernie and others have made it lots easier).


I would like to add my little plug here. COM was very combersome to work with, Ernie did fanstastic ground breaking work to bring it to MASM. However, i personally feel that Japheth has succeeded this work further and better by providing tools that would simplify COM calls to DirectX Interfaces into being as complicated as a standard API call.

You should really check out his COMView Tool, its been through alot of revisions to get were it is. (I have manage to pester him from revision to revision to get it here, and I have to say I think its truely quality work at its current revision ~ COM has never been so easy to work with).

:alright:
NaN
Posted on 2003-04-26 22:55:32 by NaN