"Dmitry Olshansky" <[email protected]> wrote in message news:[email protected]... > > Mmm, am I the only one wondering where did you guys get SetPixel in OpenGL > ? It's must have been GDI. > At any rate OpenGL and DirectX is all about sending commands and data back > and forth between CPU and videocard (well, there is driver involved, > doing some translation into specific chip's commands and such). > So no, SetPixel couldn't exactly get inlined just because you can't access > video ram without jumping through some hoops: OS -> HAL-> > driver ------->PCI-E or AGP -> ... -> video RAM. OpenGL and DirectX > subsytems bypass some of these additional hoops, but still you have to > send the data down this route. That's why it's usually used for massive > asynchronous transfers. > E.g. every time you need GetPixel you send "read pixels command" and wait > utill all the data already streamed in is processed and stored in the > video RAM, then it reads framebuffer and sends you results (effectively > stalling all it's processors). > So for "straight" setpixel/putpixel drawing, software render + blit to > screen is the way > (but I doubt you need only pixels, and going futher inevitably shows why > software render sucks). >
What I was thinking of was using some set/get pixel stuff to draw to system-ram and then use OpenGL/DirectX to transfer it to video-ram when done (I have no idea which way Adam was doing it). And yea, you're right that software rendering sucks performance-wise. But the main orginal point was t have a way to just toy around with image drawing in an easy classic DOS-style. From there, my thoughts were "ok, how to make this approach as close to being efficient as it can realistically get?"
