Is there any way to access the screen/display memory directly? In TI-89 programming, you just memcpy lines of a bitmap to LCD_MEM (0x4C00) plus the offsets; can I access the windows display memory like that, and if so, what's the base address? TIA. Win if you can, lose if you must, but always cheat. [edited by - XCaVeDoGX on October 13, 2003 7:39:26 PM]

you can get a pointer to the video buffer with DirectDraw, but this is not always the same address. You have to request the pointer everytime you want to draw a frame by locking the primary surface, and release it after that by unlocking it. you can find a documentation of directdraw in the msdn librarie

My Site

That''s not directly though, I want to do it without DirectX or other graphics library. I know they can do it, so there must be someway I can too.

With Windows that is the only way. Remeber, modern operating systems work in protected mode and use virtual paging systems to manage memory. That means you can''t just go grabbing any ol'' memory address and start reading and writting to/from it. Each process runs in its own little sandbox. That''s why if you go out of bounds on an array sometimes you will get general protection faults. Back in the DOS days you were running in real mode which meant you COULD write to any address you damn well wanted to, including the frame buffer. Those days are gone. You have to use a library such as DirectDraw, SDL, OpenGL, Allegro, GDI, or some other in order to put pixels on the screen. Sorry, but it''s for the best!

DirectDraw is very direct. You only have to do quite some initialization, but once you have the pointer, you can just write to like any other memory address. it''s a bit slower than writing to normal memory, because the data needs to go over the agp bus, but that''s something you will always have if you are writing to the video buffer.
I am sure it''s not just an offscreen buffer that''s copied to the screen once you unlock it, because if you just change one byte, the pixels on the screen changes immediately (unless you are drawing to a backbuffer)

I don''t think it''s possible to draw to the videobuffer without DirectDraw or maybe something similar, because windows runs in protected mode, and with that, memory addresses are virtual addresses. Virtual addresses don''t have to be the same as their physical address, so there''s no fixed pointer that will always point to the video memory, surely not one that will work on different video cards. The only way to get a pointer to that buffer is via the card specific drivers, and to use that, you need directdraw or so

My Site

I''ve used DirectDraw/3D/OpenGL and I know how to do this stuff in those. I know that it would be complicated, but if those libraries can do it, it''s obviously not impossible. What is it that they do to get the address and the right to access the memory?

Win if you can, lose if you must, but always cheat.

DirectDraw/3D is made by Microsoft, so it gets special access through Windows. With OpenGL, it depends on the implementation (many implementations just wrap Direct3D calls on Windows machines), but video card vendors most likely use the DDK (driver developers kit) and some hush hush info from Microsoft to get the access they need.

directdraw and similar are basically wrappers for the drivers. And the drivers are specially writtin for one type of video hardware, and they know how to interact with the hardware directly, but this differs from card to card, so you can''t make something that will work on different computer, and also, hardware vendors keep it a secret how their hardware works, so I think it''s nearly impossible to do it without directdraw or so.

My Site

The big question is WHY do you want to do this? We have gone so far to get away from needing direct access to the framebuffer that I can not image why you want to go back to the stone age. If you just want the experience of starting with nothing but an address, then writing your own putPixel, writing your own plotLine, then bitblt, then full blown software 3D then just install an old version of DOS and go nuts. Or do some homebrew developing for Dreamcast or GBA where you really have no choice but to use that sort of low level access and reinvent the wheel. Otherwise, bask in the glow of hardware acceleration, it really is your friend.

I should say "high level access to vendor independent hardware acceleration".