Accessing video memory in c++
Author
Hey...I would like to make my own 3d graphics library (just a hobby project, so please don't tell me to use direct3d or opengl or any of those stuff). So, how would I access video memory directly in Windows, or can I only draw inside a frame? If so, how can I use the WinAPI to do this? Thanks in advice!
You can't access video memory directly. Usually the closest thing is to create a Direct3D surface/backbuffer, lock it, and write manually. Then you can flip that to screen. You could use a GDI construct like an HBITMAP instead, but it will be slower for no advantage.
Author
ok,thanks, but is it possible to draw individual pixels in the WinAPI, without having to get the DirectX sdk, wasting a bunch of RAM, etc? I'm trying to not use an existing 3d engine to make this.
Quote:Original post by PhynixPixelToaster might be more what you are looking for - a simple framework providing pixel-access to a framebuffer.
ok,thanks, but is it possible to draw individual pixels in the WinAPI, without having to get the DirectX sdk, wasting a bunch of RAM, etc? I'm trying to not use an existing 3d engine to make this.
Isn't that just a wrapper around Direct3D? Maybe that's fine for the OP's purposes, although he sounded like he didn't even want to have any sort of dependency on D3D. In which case, I'm not sure it's possible without a kernel driver and a ton of work.
Author
yeah, it would be preferable if there was no Direct3D dependancy, but if there is nothing else...which i really doubt...then, i would just have to settle with d3d. what im sort of asking is if you can draw directly to a winapi window.
Quote:Original post by PhynixNo, you can't directly access the hardware in any modern operating system. Physical access to hardware is controlled via the kernel (to understand why, just think: what would happen if two programs wanted to access the hardware at the same time?)
ok,thanks, but is it possible to draw individual pixels in the WinAPI, without having to get the DirectX sdk, wasting a bunch of RAM, etc? I'm trying to not use an existing 3d engine to make this.
You can draw bitmaps to the screen with plain old GDI/GDI+ of course (e.g. with BitBlt in GDI), but you won't be "access[ing] video memory directly". Libraries such as SDL also provide a simple API for drawing 2D images in a cross-platform way, perhaps you can start there?
In particular, if you're wanting to write your own software rasterizer, you don't actually need "direct" access to video memory, and I would say that the interface provided by SDL would be more than sufficient for your scenario.
You don't access to the hardware directly. Leave that to the driver.
Besides even if you could, each video card model is different, and you would need to code for each and every one.
Instead, there IS already an interface to the driver: it's called Direct3D.
Direct3D is a low-level API that allows you to access the video card in a generic way. It's NOT an engine.
Over time Direct3D grew and now it's bigger and contains a lot of stuff usefull for game developers, but it doesn't make it an engine. It's still a low level API.
Furthermore, everything that is not truly necessary is in the D3DX library, stay away from D3DX and it will be fine.
You can try GDI instead, which is another, older, interface.
But I don't understand why you want to stay away from D3D.
Cheers
Dark Sylinc
Besides even if you could, each video card model is different, and you would need to code for each and every one.
Instead, there IS already an interface to the driver: it's called Direct3D.
Direct3D is a low-level API that allows you to access the video card in a generic way. It's NOT an engine.
Over time Direct3D grew and now it's bigger and contains a lot of stuff usefull for game developers, but it doesn't make it an engine. It's still a low level API.
Furthermore, everything that is not truly necessary is in the D3DX library, stay away from D3DX and it will be fine.
You can try GDI instead, which is another, older, interface.
But I don't understand why you want to stay away from D3D.
Cheers
Dark Sylinc
In the old days, you could access the actual video memory directly (mode 13h FTW), but these days you can't. More importantly, you probably don't want to, because you have to play nice with your windowing environment.
What you most probably mean is that you want a single, contiguous block of memory that can be used as a suitable linear framebuffer for software rendering/rasterization.
The Win32 APIs give you enough to do just this -- in fact, its exactly the way that WinG, which was the precursor to DirectX, worked in order to entice game developers to move away from DOS. The Previously mentioned PixelToaster does exactly what you want and supports multiple platforms, IIRC.
My own software rendering system works completely independently of any OS API up until I need to get my back-buffer onto the screen, and the sum total of Windows API code, aside from window creation, involved in getting my results to the screen is about 12 lines. It supports both windowed and fullscreen rendering.
What you most probably mean is that you want a single, contiguous block of memory that can be used as a suitable linear framebuffer for software rendering/rasterization.
The Win32 APIs give you enough to do just this -- in fact, its exactly the way that WinG, which was the precursor to DirectX, worked in order to entice game developers to move away from DOS. The Previously mentioned PixelToaster does exactly what you want and supports multiple platforms, IIRC.
My own software rendering system works completely independently of any OS API up until I need to get my back-buffer onto the screen, and the sum total of Windows API code, aside from window creation, involved in getting my results to the screen is about 12 lines. It supports both windowed and fullscreen rendering.
Author
Quote:Original post by Matias Goldberg
You can try GDI instead, which is another, older, interface.
But I don't understand why you want to stay away from D3D.
OK, I will try GDI, thanks. I also found a great tutorail on the web by googling (http://www.functionx.com/win32/index.htm), and is pretty close to what I originally wanted: a method of manipulating pixels using the Win32 API.
And the reason I wanted to stay away from D3D is because it would be redundant. I don't find any point in creating D3D from D3D (creating a graphics library that has the same or less functionality than the thing it was based upon). Direct3D is already a 3D library, and it doesn't make sense to make a 3D library out of a 3D library.
So, my question is pretty much answered. Thanks Matias Goldberg and Codeka, and everyone else. (Wow, I love these forums)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement