- Forum
- Windows Programming
- Memory mapped graphics
Memory mapped graphics
I'm the kind of person who likes to do everything themself...
And I want to start working with graphics. I pretty much just want to be table to write my data to an array, and copy it directly to the video memory of my application.
So I'm wondering if there are any commonplace "bare bones" graphics libraries that would do low level operations like that or if it would be worth it for me to code them myself in inline assembly (I have a good understanding of assembly, so I'd just have to look up the Interupts)
-Pseudo
And I want to start working with graphics. I pretty much just want to be table to write my data to an array, and copy it directly to the video memory of my application.
So I'm wondering if there are any commonplace "bare bones" graphics libraries that would do low level operations like that or if it would be worth it for me to code them myself in inline assembly (I have a good understanding of assembly, so I'd just have to look up the Interupts)
-Pseudo
Ok, here's a simpler question that would be just ase usefull:
How do I DIRECTY interface a Device Contex's memory? There's the SetPixel function, but I imagine using that would be exceptionaly slow.
How do I DIRECTY interface a Device Contex's memory? There's the SetPixel function, but I imagine using that would be exceptionaly slow.
Last edited on
You really have 3 choices when it comes to graphics:
* Use the DirectX libraries.
* Use the OpenGL libraries.
* Be exceptionally slow.
(There are also some newer cross-platform efforts that sit on top of these libraries). There is no simple direct access to the memory used to display the screen, as that memory is on the graphics adapter. Both of the popular graphics libraries have pixel-oriented options in 2D mode, but sending bitmap-level data to the graphics card memory is always the slow way, compared to defining textures (etc) for objects and then moving and rotating those objects.
* Use the DirectX libraries.
* Use the OpenGL libraries.
* Be exceptionally slow.
(There are also some newer cross-platform efforts that sit on top of these libraries). There is no simple direct access to the memory used to display the screen, as that memory is on the graphics adapter. Both of the popular graphics libraries have pixel-oriented options in 2D mode, but sending bitmap-level data to the graphics card memory is always the slow way, compared to defining textures (etc) for objects and then moving and rotating those objects.
To me it would seem that there must be a way to write directly to whatever video buffer you're writing to when you use SetPixel() and GetPixel()...
Is there some reason such as windows security that you can't / if there is could someone give me a vauge idea of what it is?
Is there some reason such as windows security that you can't / if there is could someone give me a vauge idea of what it is?
Well, typically that "video buffer" is usually a texture displayed as a sprite, and the memory is on the video card. I'm sure there is a way, as the video card drivers do it internally, but it's not going to be the same from video card model to model.
You'd have to jump through the hoops to create a texture, get its address in the video card's memory, tell the chipset that a certain range of addresses in main memory actually refer to a range of addresses in video card memory, etc, etc. None of which I'd expect to be able to do from user mode.
Understand that the actual scan-line buffer that the card uses to send data to the monitor is not going to be accessible. That's constructed entirely by the video card internals (at least in general), after doing stuff like oversampling for full-screen anti-aliasing.
You'd have to jump through the hoops to create a texture, get its address in the video card's memory, tell the chipset that a certain range of addresses in main memory actually refer to a range of addresses in video card memory, etc, etc. None of which I'd expect to be able to do from user mode.
Understand that the actual scan-line buffer that the card uses to send data to the monitor is not going to be accessible. That's constructed entirely by the video card internals (at least in general), after doing stuff like oversampling for full-screen anti-aliasing.
Topic archived. No new replies allowed.