Just wondering if this is possable. I''m trying to convert a old dos 8-bit (256 color paletted) graphics game I made to windows. The DOS version uses some assembly routines to draw tiles on a block of system memory then blits the completed image to the screen (which is set at either 320 X 240 X 256 or 640 X 480 X 256). It also uses some palette functions to do fades, rotations, ect... Is it possable to do this with the Window GDI?...say create a block of memory in the system for use as a screen buffer (in the forum of a .BMP of the appropriate size & bitdepth)...do all the graphics on that...then use the GDI to refresh it? would it work with even though the palette may change from update to update? I know you can create a DDsurface to do this and all that...but I''m just wondering what the GDI limits are?

You cannot access a framebuffer with GDI directly, that''s what DirectDraw was made for.

I don''t meen a real frame buffer...as in one stored in video memory...

for example...you have your application window...inside it you load a .BMP to display from the HD...GDI works for this right?

What if you generated a .BMP in system memory, and told the GDI to display it instead...basicly it would be something like loading a .BMP into memory then telling the GDI to put it on screen (upload into video memory then do what it has to do to display it in your window)...so instead of pointing the GDI to a .BMP file I/O stream...you point it at the "virtual buffer" (a GDI friendly DIB) in system memory.

I know it would be slow...but for a 320 X 240 X 256 image...could it do say 20 FPS?

Look at the CreateDIBSection function. This creates a bitmap that you can write to directly with bit manipulation, and works with GDI. Just remember to GdiFlush() before writing to it.

Cheers, dorix