I have written a software rasterizer (a 3D software renderer). I rasterize to an off-screen bitmap by writing to the bitmap scanlines and then blit the bitmap to the screen. The problem is that the blitting is slow because I have to set the pixel format of the bitmap to a 32 bit DIB in order to write to the scanlines - it then has to convert to the pixel format of the device (monitor) when blitting. If I set the bitmap pixel format to device dependant it will blit very quickly but then I can't write to the scanlines correctly - even if my screen colour depth settings are 32 bit. Is it possible to write to the scanlines of a device dependant bitmap without using hardware? The GDI routines in Windows are capable of doing this so how do they do it? Are they using hardware? Thanks Peter Bone

Someone must know about this. Why can't I access the raw data in a DDB when GDI can. Is it the device that does the actual drawing and GDI is just the interface between the application and the device?
Peter

The reason why the blit is slow is because you're doing a color conversion during the blit. The DDB is the same format as the primary display so the blit is fast and is basically a hardware accelerated memcpy.

The DDB is created by the display driver and its contents are opaque outside of the driver. The GDI calls made by applications, translate to DDI calls into the display driver and then the display hardware draws to the DDB.

Thanks. This is what I suspected but I'm not exactly sure what you mean by 'opaque'. Does this mean there's no way to write to the DDB data from outside of the device? I assume this means there's no way to write a software renderer that blits quickly.
Pete

I wouldn't dig up DirectDraw from the grave for this, but I would draw to a texture and draw a quad onto the screen, having the GPU do the format conversion.

This sounds like a good idea enabling me to draw to the off-screen bitmap with the CPU and use the GPU for blitting. How would I go about drawing my bitmap to a texture?