If I was to access the video memory on a graphics card without using any direct X, OpenGL etc, how would I go around doing this on Windows.
I konw doing it on DOS is easy (0B8000000H addressing etc.), but finding details on this with Windows XP, VIsta etc has been proving difficult.
I know I could use Direct X and OpenGL ... but I'm a purest. :D
Posted on 2010-01-19 05:08:42 by Grich
Well, you can use CUDA ;) Why would you want to do that? I can't see any good reason to access the VRAM without using DX/OGL/CUDA/whatever. Even "purists", who write software rendering, use DX to allocate a swap chain, lock the backbuffer and just write to it.

/edit
typos
Posted on 2010-01-19 05:40:01 by ti_mo_n
If you need to READ the screen, research how FRAPs and CamStudio do it.

If you just need to write to the screen, it's just as ti_mo_n wrote.
If you need a really quick way to start drawing 32bpp graphics:
http://www.asmcommunity.net/board/index.php?topic=24967.0
(use sdLockRect)

If you need hardware-accelerated drawing, you must use DX or OpenGL. With GL, you really can draw to the REAL front-buffer under WinXP (while it'll crash'n'burn under Vista), but know that the gpu automatically clips stuff to the window-region. You can have fun with pixels-computed-by-ASM in GL/DX, too: write shaders.
Posted on 2010-01-19 06:33:27 by Ultrano
Sadly there's no place for purists in Windows. DirectDraw was devised to allow a vendor/hardware-independent way to map the framebuffer/backbuffer (so you do get a direct pointer into videomemory, the address is just decided at runtime, unlike the fixed addresses in DOS/VGA mode). It is now superceded by DirectGraphics aka Direct3D.
Posted on 2010-01-19 07:49:31 by Scali
Sadly there's no place for purists in Windows -- I have realised that now  :sad:

Why would you want to do that? -- because I want to - and its fun  :D

So, what I gather so far is that if I am to do graphics in a windows environment, I have to use its API and DLLs, sigh, I had that feeling when I first started my quest  :sad:
Posted on 2010-01-19 16:58:23 by Grich
So, what I gather so far is that if I am to do graphics in a windows environment, I have to use its API and DLLs, sigh, I had that feeling when I first started my quest  :sad:


It's the same way with all modern OSes. Using APIs to abstract away the hardware is the only way to guarantee that a wide range of different hardware can be supported.
But as I say, you can still draw directly into the framebuffer (or backbuffer) with DirectDraw, so who cares? It's the same as in DOS, just different.

Here's an example of a plasma effect in 320x200 8 bit mode (basically mode 13h), using DirectDraw:
http://srcvault.scali.eu.org/cgi-bin/Syntax/Syntax.cgi?Ddplasma8.asm
Posted on 2010-01-20 02:44:27 by Scali
What ti_mo_n, Ultrano and Scali said.

If you want to be a "purist", play around with osdev - raw hardware access under any modern operating system is a no-go (it's possible with drivers, but generally a really bad idea).
Posted on 2010-01-20 06:15:51 by f0dder
Thanks scali for the link :)

". . . but generally a really bad idea" - yeah I was told that by another person :(

I am now appreciating the API abstracing all this for us ... with new hardware coming out all the time, you can't be stuck in the queue programming for one piece of hardware whilst newer ones are coming out.
Posted on 2010-01-20 17:53:29 by Grich
". . . but generally a really bad idea" - yeah I was told that by another person :(
I initially felt that way too, when I finally moved away from DOS and to Win95 (and for a long period, I used a version I had stripped down to around 25meg, which mostly acted as a multitasking DOS extender with better disk caching and improved stability against programming errors (even if Win9x was still super fragile :)). But these days I pretty much appreciate it, means less having to rewrite the wheel and more Get Things Done (or Focus On Interesting Code).

And as mentioned previously, you can always turn to toy hobbyist kernel development if you want to go bare-metal. It's even a lot easier these days than in the old times, because you can do a lot of testing under (pretty capable!) virtual machines... saves a lot of test machine reboots ;)

I am now appreciating the API abstracing all this for us ... with new hardware coming out all the time, you can't be stuck in the queue programming for one piece of hardware whilst newer ones are coming out.
Yup - you no longer have to stick with basically pretty dumb VESA framebuffer access, but can utilize hardware acceleration... without having to ship custom drivers with your application ;) (heck, you even had to do that in the pre-VESA days, anybody remember Borland BGI graphics? And how limited their default drivers were?).

It's possible to write code that performs pretty well and has pretty graphics and runs on just about any machine out there - if you want "really pretty" you'll narrow the supported hardware (in case of supported Shader Model) or OS (if using DX10/11) somewhat, and of course CPU/RAM hungriness has it's toll too. But it'll still run on a pretty wide range of hardware; remember the DOS days where you'd only get 3D acceleration if you had a S3 ViRGE? And then later, a Verite? Or Voodoo? And usually, games would only support one card? We're paying some performance price for the abstraction, but IMHO it's well spent :)
Posted on 2010-01-20 18:06:24 by f0dder
Thanks f0dder for the input. :)
I'm making a game engine and graphics engine for myself ... I've done one in Java but I am considering all choices for my next one, DirectX, OpenGL and a\I was thinking about building my own DLL/API .. now I'm thinking OpenGL at the moment.
Posted on 2010-01-21 02:04:43 by Grich
OpenGL is a strange choice for someone who wants direct access.
DirectDraw gives you REAL access to videomemory. Something that OpenGL cannot.
OpenGL is mainly aimed at 3D acceleration. However, Direct3D is closer to how the hardware works (and more advanced at this point, with Direct3D 11 having come out, just when OpenGL almost caught up with Direct3D 10). With OpenGL you're stuck with tons of extensions that basically copy functionality from Direct3D. OpenGL is all but dead on the Windows platform. Even professional software like Autocad and 3dsmax are recommending Direct3D over OpenGL now.
Posted on 2010-01-21 02:12:43 by Scali