Archived

This topic is now archived and is closed to further replies.

How do OpenGL and DX work?

This topic is 5133 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How did the writers of these programs get low level access to the hardware? For instance If I wanted to make a very simple graphics API that could go into fullscreen mode ang change the screen color how would I do it like the way OpenGL and Direct X do it. Back in the days of DOS I think people used to know the address of videomemory and from there they could minapulate it from there. I get the impression thought that in windows its not that simple. So how exactly is it done?

Share this post


Link to post
Share on other sites
The drivers I believe manage all that crap.

I guess if you wanted to to write your own API you would have to write your own driver specific to your video card?

Or you could just slap a layer on opengl or something to do 2d pixel by pixel plotting

Does this sound right you guys?

Share this post


Link to post
Share on other sites
Layers on OpenGL and such to do manual graphics would be rather slow, I believe.

Your best bet for doing manual graphics (by which I mean no hardware stuff - all software, minimal use of API) is to use some basic DirectDraw stuff (you can set up a frame you can write to directly similar to in the old dos days and flip to the screen), or use dibsections in the GDI. I personally use dibsections. It''s the same sort of idea as the as what you did in the dos days - you can get a pointer to a linear buffer which represents the video memory, and you can copy your own buffers to it. Beyond that it gets a little more complicated (such as resizing the window and making the dibsection resize with it, and changing video modes).

There is plenty of code on the internet for changing video modes in windows, and I''m sure there is code for using dibsections as well. I pieced together my knowledge and uses of dibsections and a resolution changer from the MSDN library, basically... it took a while. Maybe I should write a tutorial on it and save some people a bit of trouble.

Share this post


Link to post
Share on other sites
Coding directly to hardware is practically dead. The reason is because drivers are written to spec for DirectX and OpenGL.

Unless you could either:

a) Convince nVidia and ATI to code the drivers for your API

OR

b) Write your own drivers for those cards in order to work with your API

Than you''re pretty much outta luck =]

Share this post


Link to post
Share on other sites
I think what the original poster was thinking of (based on their description) would not really need to be an API as such. It would really be more of a wrapper for some of the functionality, like GLUT. Communicating directly with the hardware is only allowed for device drivers, and each driver will have its own mechanism for interfacing with 3D hardware. This basically means that (as previous posters have said) its just not viable. There is no uniform method of working with 3D cards via drivers.. thats why D3D and OGL exist. That being said, if you understand Win32, and either OGL or D3D well, you could make what "felt" like a new API, by cleverly wrapping all the functionality. A good example of this (or bad if you prefer ), if MFC. MFC at its underlying level is Win32 and contains considerable fucntionality regarding the shell api. At a programmers level however, it looks like a completely different API. The main thing to think about when making a wrapper of this sort, is design. You'll find a lot of the implementation details are simple, but if you don't design the system well to start with, you'll probably only end up disappointed with the results. This does however have a prerequisite of understanding Win32 and OGl/D3D coding to a reasonable level. If you think your up to it at the moment, get coding... if not, hit the tutorials. good luck .

EDIT: As for accessing video memory directly, DDraw lets you do this (essentially). You would however not get an 3D hardware acceleration. Thsi is however a very good framework in which to build a software 3D engine, which can be very cool in itself.

[edited by - dmounty on November 28, 2003 5:08:15 PM]

Share this post


Link to post
Share on other sites