Jump to content
  • Advertisement
Sign in to follow this  
Phynix

OpenGL Accessing video memory in c++

This topic is 3257 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

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!

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Phynix
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.
PixelToaster might be more what you are looking for - a simple framework providing pixel-access to a framebuffer.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Phynix
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.
No, 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?)

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!