I'm very new to windows/directx programming (but not new to assembly programming) and would like to open a full-screen window and get the address to the framebuffer and draw directly to the screen. Does anyone know how to do this?

there is DDRAW in FASM\EXAMPLES

I looked over the sources and don't know at what point the address of the framebuffer is found. What function would you use to get the address, and do you need to use a selector to draw with it?

u need to LockSurface primary surface, u will receive a structure with pointer to video frame

yes, but dont forget that you should keep primary surface locked as short as possible.

you could take a look at my library,
http://board.flatassembler.net/topic.php?t=599
file src\platform\ddraw.inc, procedures tg2d.os.SetVideoMode and tg2d.os.Lock (and tg2d.os.Close to clean your mess completely)

Comrade, which structure and what variable would I find the pointer in.
vid, You have a library for directx, what does it do?

it is library for directdraw only, not for whole directX. In fact it will be multiplatform graphic library (2D).

i also answer for comrade - you create directdraw instance IDIrectDRaw with CreateDirectDraw(). Then you create primary surface IDirectDrawSurface with IDirectDraw::CreateSurface(). Then you lock surface with IDirectDrawSurface::Lock(), which takes argument pointer to the structure DDSURFACEDESC whose member 'lpSurface' is filled by IDirectDrawSurface::Lock() and holds pointer to surface. After calling IDirectDrawSurface::Unlock() pointer becomes invalid

Was browsing through the win32asm Game development forum, and found this information in one of the questions a user asked, about reading data directly from the framebuffer memory to get a copy of a dvd video that was playing. Has anyone used this method, I have directx 9.0b and Windows XP.

madmatt, this only applies if you use the DirectX8 interfaces. You can still use DX7 (and even lower) interfaces with DX8 and DX9 runtimes installed, that's the beauty of COM. If not, I'm very mistaken :p

f0dder: you can use them, but some procedures takes other number of arguements (like SetDisplayMode), it depends on directdraw interface version (version is 1 for CreateDirectDRaw or specified by GUID for CreateDirectDrawEx)

Does that contrast with anything I stated? You want to lock the framebuffer, fine, you use an older interface. If you want fancy features of newer DX features, learn to live without surface locking.

oops, sorry, that one was meant for madmatt

I wonder why getting a framebuffer address seems to be more difficult to use in later versions of directx? I want to use the direct framebuffer address for testing purposes only, not in games or anything.

vid,fodder - I'm confused, I have directx 9.0b, You can use the Directx 7 interface with easier buffer access, even tho I have dirextx 9? How would you specify the directx 7 interface in your assembly code, even tho you have a directx 9 install.

When you do a DirectDrawCreate call, you get a DirectDraw interface object - and you get a pretty old one. To use any later directdraw features, you need to QueryInterface for a later directdraw interface, like IID_IDirectDraw7.

Think about it logically - if microsoft removed frontbuffer locking from DDraw altogether, a zillion apps would break. Also, all new DirectX versions have to support old DirectX applications... this is handled by the beauty of COM and interfaces - you still have basic DDraw2 support even with a DX9.0b install.

Why is direct framebuffer access being removed? *shrug*. I guess because it's slow, especially if you try to lock the framebuffer when 3d acceleration is used - everything has to be synchronized and such. You can still lock other surfaces (for texture generation etc), so it shouldn't really be a problem.

If you need to lock the frontbuffer, you're probably doing something wrong :p - and you can always use an old DDraw interface, then.

Well, like I said, I wouldn't write a game or time critical 2d/3d Code that would lock the framebuffer . I'm still a very beginner in directx, but I have read articles and such, and I know that locking the framebuffer for direct writing is even more to be outlawed than in the past. This would be just for testing, like, PaintshopPro/GFX filters that use sse/sse2/sse3 instructions, or use your own specialized/optimized gfx and data loader, etc. and one other thing I just thought of, seeing that I ran the directx example in the FASM windows demos that, if I am correct, uses direct buffer access to load a gif image. Since I'm using windowsXP/DirectX9.0b and it does work without crashing, I shouldn't have to much to worry about. Thanks all for your help!

In my opinion, there never really was a reason to lock the frontbuffer in the DirectDraw era, except perhaps for doing screen captures. Cards have plenty of memory, so even if I drew to a system memory surface or byte array, I would always blit to a backbuffer and flip, instead of writing directly to the frontbuffer - so frontbuffer lockability isn't an issue for me.

Afaik, you can still lock backbuffers and surfaces, even with newer DX versions - as long as you create them as lockable (how else would you get data into textures? ). Creating surfaces as lockable may or may not be slower than non-lockable. So, you should be able to create a lockable backbuffer, and draw directly there if you want to.

(And of course you should still keep surfaces locked as shortly as possible. First because it's generally nice, second because of some nasty systemwide 16bit mutex on 9x.)

If you want to use filters and stuff, create the surface in system memory to avoid the slow bus transfers - or figure a way to implement the filter/effect with the use of hardware.


Exactly. Thank COM and Microsoft's foresight.

Btw, if you're aiming for 2D games with sprites with transperancy and alpha and such... even 3D cards that are lowend today have insanely fast subpixel corrected, filtered, alphablended, stretched, rotated (...) sprite capabilities.