mattnewport: What I mean is that it''s a pity there is no standard amongst hardware for introducing features. The OS wrapper could be ignored if every graphics hardware exposed it''s features in a standard way, thus allowing you to call the same function for any piece of hardware, and not worry about whether or not it will work, etc.
I admit that you''d probably have to re-wire EVERYTHING for that to happen. But still, it would have benefits. It''ll never happen though. And if it does, well, I won''t complain.
All graphics hardware does expose it''s features in a standard way - through OpenGL extensions or through new DirectX versions. Having standardization at the API / driver level rather than at the hardware interface level is absolutely the right way to do things. If some standards body had to hammer out a standard for the hardware interface every time a manufacturer wanted to introduce a new feature it would greatly slow the pace of innovation in the industry. It would take a lot longer for new features to be introduced and it would be limiting for both software developers and IHVs.
As an example look at anti-aliasing - if developers acessed hardware directly without a driver mediating then the only way to take advantage of it in old software would be for the developers to release a patch. With an API and driver level in between it is easy to have an option in the drivers to turn anti-aliasing on for all existing software without any change to the software. As another example look at nVidia''s special stereoscopic display drivers which let you play many existing games in stereoscopic 3D with LCD shutter glasses or VR headsets without modifying the games. That would be impossible if the games were accessing hardware directly. Or how about the driver nVidia released to allow developers to emulate a GeForce FX before the actual hardware was available: how would that be possible with a direct hardware interface?
There might be some slight performance advantages to direct hardware access (though they would almost certainly be a lot less than you think) but they would be vastly outweighed by the disadvantages of having too low level standards. Higher level APIs exist because the way things used to be done (direct hardware access) proved to be a bad way of doing things.
Well then, is it possible to use OpenGL (of which I have never used) to allow me to access the graphics card''s memory directly? It is possible with DirectX (LPDIRECT3DSURFACE8), but is it with OpenGL?
I only say this because what I REALLY want to achieve is a cross-platform set of functions that I can use to make them nice gfx. And I want to do it by accessing the memory diretly, to set the pixels to the correct colour directly in the VRAM.
Please inform me if I''m gravely wrong. The lack of information about these things at school is tremendous. Although they DID teach us how to write memos. Useless school. :]
"I only say this because what I REALLY want to achieve is a cross-platform set of functions that I can use to make them nice gfx. And I want to do it by accessing the memory diretly, to set the pixels to the correct colour directly in the VRAM."
I don''t really know OpenGL so I can''t help you there but I''m sure there''s a way of doing what you want.
"I only say this because what I REALLY want to achieve is a cross-platform set of functions that I can use to make them nice gfx. And I want to do it by accessing the memory diretly, to set the pixels to the correct colour directly in the VRAM."
You''ve got some conflicting goals here. If you want cross-platform functions then you really want a higher level API than OpenGL / DX not a lower level way of accessing the hardware - like TinyPTC or SDL as suggested by jdi. Why do you think you want to do this by accessing the memory directly in VRAM? Do you think it will be faster? That''s not necessarily going to be the case, particularly if you access the pixels in a non-sequential fashion or need to read as well as write pixels. You''ll usually be better off building your image in system memory and then transferring it to VRAM in one go when it''s complete. Do you have some specific effect in mind that you want to achieve or are you just looking to play around with various ideas? If you just want to experiment go for the easiest set up that lets you try things out and don''t worry about performance until it becomes an issue. It''s extremely unlikely on a modern PC that any effect you want to do will be limited in performance by the transfer of your image to the frame buffer.
if you''re really interested in all this stuff, you should take a look at linux. admittedly, support for 3D acceleration is spotty at best, at least from within the opensource community, but you can still see "how things are done".
http://dri.sourceforge.net/
is a useful link. it''s not the best, becuase they don''t have the greatest documentation, but it''s how opensource hardware acceleration is done.
and while Yann is somewhat correct, in that you don''t neccessarily learn a lot about graphics from implementing lowlevel hardware access, you can stand to learn a lot from implementing OpenGL on top of your low level hardware access.
anyways, something interesting is that most X drivers will supply a "linear framebuffer" in unaccelerated mode, and if you got a pointer to that you can just draw your bits, as you''d like. it''s slow, though, because you do a bit of unaccelerated IO for each pixel.
1) if you want to do cross-platform graphics, use an API. if you allocate some memory and draw to it like a screen, every api will give you some way to put that on the screen, and you can do all your software stuff.
2) if you want to do "low level" then pick one of these cards that you can get docs for an play around with it in linux.
