A while back I made some pixely games like this and I used glRectf to do this. I'll post the exact code below, it's simple. I remember changing it to vertex arrays later and actually saw a large decrease in performance. I wasn't sure if this was because I was using FloatBuffers wrong (they were specifically what seemed the slowest to me) or if it's simply faster to a bunch of rect calls.

Since I've done almost all of my more complex OpenGL work within iPhone and have had access to C arrays, I'm a noob when it comes to leveraging float buffers the correct way.

Why not use PNG sprites and save yourself countless hours of headache?

If you are really set on software rendering pixel-by-pixel, I'd imagine you might get decent performance with a PBO. Upload pixel data to a texture which is then rendered to the screen (scaled quad with nearest-neighbour filtering). For optimization you would probably want to use multiple textures and/or texture atlases -- i.e. the pixel sword (which is repeated frequently) would be uploaded to a texture atlas, and then you would render each sword with its own textured quad (using the texcoords of the sword). The idea would be to minimize texture uploads as much as possible, only doing it for truly dynamic animations.

Also, I wouldn't rely on glRect or immediate mode, especially if you plan on rendering pixel-by-pixel...

So obviously the catch is that any object could explode into individually animated and physicsed pixels at any time, as you can see if the video I linked. Also the level can be chopped up and ruined like in Voxatron. This is voxels, which as I understand is basically just a 3D pixel. But I don't understand voxels very well.

In the video I showed you (Lego City Ransom), the characters are all textures and then their pixel data is used to generate a bunch of individually placed pixels when they die. The weapons, however, are all of the pixles drawn individually - could certainly use an FBO to be faster.

In this example thing I made: Pixel Splosion geo modding, the planet is an FBO and the pixel pieces (press P with your mouse over part of the planet) are drawn with glRect.

So anyway I see a lot of things like that may be necessary, but I'm just wondering how people did like Voxatron which is so fluid and has so much moving at once. I'll look at PBOs, I've never used them.

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.

Like others suggested... simply poke colours directly into an RGB bitmap in a ByteBuffer. If you're not intending to ever read the colours back again, use a PBO. Then render it to any size you want and let OpenGL scale the pixels appropriately.

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org