Looking for realtime Win32 pixel control.

[Niels Meijer]

Dear Reader,

I am looking for a way to accurately set pixels in a Win32 window.

I'm pretty sure you'd start thinking about SetPixel() right now, but that function takes about five seconds to fill the screen. And I was thinking about minimal 100 FPS if the pixel calculation would take no processing time.

I couldn't find any function, so I tried OpenGL. it works fine, but I think it is way too much work for what I want: after you initalized the PIXELFORMATDESCRIPTOR and the HRC and initialized OpenGL you can call OpenGL functions onto the HRC, which can be applied onto the HDC and thus the WinAPI window... (I don't know if this is correct)

Can't I just initialize a normal Win32 window and fill a bitmap pixel per pixel and than apply it to that window without all the OpenGL crap and still have a acceptable framerate? This is exactly what OpenGL does, but I just need the per pixel drawing functions (if OpenGL has those) and not all those nice OpenGL 3D-vector functions, alpha options, shading properties etc. of which OpenGL mainly consists.

I'm not sure what I want to display yet, but I think I just want to play a bit with math and RGB and other nonsense for now instead of fancy OpenGL 3D graphics if you want to know.

This just can't be impossible without any third-party libraries. I have a nice command over C++, but I thaught if myself and I have little experience. I hoped someone with good Win32 knowledge can tell me there is some bitmap-struct out there in the vast world of the Windows API with nice setBitmapPixel(x,y,RGB) and applyBitmap(Hwnd) functions.

Thanks for reading and please respond,
Niels Meijer

[Disch]

Can't I just initialize a normal Win32 window and fill a bitmap pixel per pixel and than apply it to that window without all the OpenGL crap and still have a acceptable framerate?

CreateDIBSection is as close as you're going to get.

It allows you to create an HBITMAP, but it also gives you a pointer to setting individual pixels in that bitmap. You set pixels as if it were a giant array, then you can just BitBlt it to the screen at any time. It's about as fast as software rendering can get.

I've used it in my retro-system emulator attempts, so it's easily able to draw a 512x480 image at 60 fps (and this was several years ago, so I'm sure it'll outperform that easily now).

But of course, the bigger you make the image, the worse your performance is going to get.

This is exactly what OpenGL does, but I just need the per pixel drawing functions

OpenGL does all of this in hardware, which is why it's fast. If you want pixel-level access with hardware rendering (as fast as you're going to get... period), the only way I know how to do it is with pixel shaders. Though my experience in that area is minimal... so I wouldn't be able to really advise you on that route.

[AHCFan20]

To set each and every pixel in a bitmap/window, pixel-by-pixel, once per frame is just impractical. Real-time graphical applications do not do this. But since you indicated that all you want to do is play with the pixels I don't see why this should be a real-time application.

[Disch]

Real-time graphical applications do not do this.

Retro system emulators do. But they work in low resolutions.

I agree that a full 1920x1080 display would be impractical... but a 640x480 display probably isn't that big of a deal.

[Niels Meijer]

Thanks for all the replies everyone!
I thought bitmaps would be the fastest way of doing this, but it seems I was wrong...
I actually said that because I already asked a question about graphics:

http://www.cplusplus.com/forum/general/91673/

no one ever responded to it... =(
I think that is the case because I didn't specify enough what I wanted, and so I made this thread, but I'm actually still asking the same question. I thought bitmaps were what I looked for so I asked that instead of the same question. I'm really happy you guys did respond to this thread!

@ Disch: Thanks for the CreateDIBSection! I'll certainly try that and the pixel shaders if I can't find any better solution! I guess this satisfies my needs but I'd like to see if I can find any better solution which, for example, also supports full screen at a nice FPS.

@ AHCFan20: Yeah, I did say that, but I mean for now.
I think I'd like to do some more complicated stuff in the future like primitive 3D-systems or something which do need realtime pixel rendering (I program as a hobby). But can you give me a push in the right way how real real-time graphical applications do it then? I just want to know how they get their (already calculated) frames on the screen with a high framerate. I actually like to do the technical stuff myself instead of some OpenGL calculating my desired vectors.
I know this is a rather unusual (and hopefully not a too unpractical) approach, but after the pixel playing I'd like to experiment with some serious low-level graphics calculation which take up a lot of processing power.

Please respond,
Niels Meijer

[AHCFan20]

I think the term you're looking for is rasterisation, and as far as I know that is a job of the graphics hardware. Realtime applications may have some limited control over the rasterisation process but in general they only define the 'scene' through various primitives(points, lines, polygons) and bitmaps(tiles, textures, sprite frames, fonts, etc). If you really want to go lower level than that(and get reasonable frame rates) then you're probably looking at driver development.

[Niels Meijer]

So the primitives and bitmaps get passed to the underlying system, which renders the scene, and the screen recieves the rendered scene in a bitmap? Or are the primitives and bitmaps passed to the screen, and does the OS render the result?