   Faster pixel access.
  Yes, I am aware there are other threads about this, and boatloads of alternate methods. Bear with me, as none of them really helped.I'm developing a Jetmen Revival clone. JR is a particle-physics based game with a destructible landscape. Because of this, it does not use textured polygons. (I hope, o_O) Or, I believe, any 3d rendering pipeline.The solution that works for me now is glDrawPixels, but it's (as expected) abhorrently slow.I understand this forum isn't about APIs, so I'll just leave that there as information. What I want to know is this.Other applications, like JR, and Flash, obviously have some kind of efficient pixel access. In the case of JR, it seems to be very fast, even though the image itself is still software-generated. (I don't know what kinds of hardware optimizations Flash can utilize to achieve speed.)So my question is this.What is this magic bullet they're using, if any? I'm somewhat fed up having an application which uses 30 percent CPU, just drawing a white 640*480 canvas.   
  For a first attempt, try loading the pixels into a texture and then drawing a full screen quad with that texture.   ;  Thanks for responding.Isn't the cost of uploading a texture the same as sending through glDrawPixels?   ;  Probably not; texture upload is a common practise thus this is going to be a 'fast path' in the driver. glDrawPixels on the other hand is widely unused and as such won't have recieved as much optimisation.   ;  There is no magic bullet. OpenGL is not designed with direct pixel pushing in mind. As suggested, try using textures with glTexSubImage for data uploads. Pixel Buffer Objects would be even faster, but driver support is spotty.There are graphics libraries that are optimized for 2D graphics, like Allegro or Cairo, which may be faster. For example, I recall using Allegro to push a 800x600x32bit bitmap to screen at 30fps on an original 200MHz Pentium - not too shabby.In any case, the most important optimization is to minimize the data that gets pushed over the bus. For example, redraw only the regions that have actually changed, not the whole bitmap.   ;  Don't know if its fast enough, but you could try particles (or voxels?). Just draw a bitmap, load it, then create a colored particle for each pixel. A particle would be a dot or tiny quad with a single color. Easy & fast to render. When destroying something, assign physics to all particles inside a certain radius. You can move the particles around, remove them, or add new ones. No need to read and write pixels.The only problem is that you have many, many particles. But if you're aiming for old-skool gameplay, you could fix this by simply using bigger particles, and/or a lower screen resolution.Greetings,Rick   ;  phantom:I implemented the texture upload version, the performance was the same unfortunately.I used glTexImage2d though, is glTexSubImage better?Fiddler:Actually I meant any magic bullet including outside of OpenGL, but, thanks for your informed opinion. I'll most definitely look into Allegro and Cairo. If they can make this easy and painless, I'll come back here with cookies. :Dspek:Aye, I did come across that method. It doesn't really appeal to me though; I'd like to have a simple rendering system, and particles also need efficient alpha.I thought a voxel was a volumetric pixel.. .~.Thanks guys, your responses have definitely given me a warm welcome to this forum.   ;  not sure if this applies to what you are doing, but if you're in windows, you could try writing to buffer, like "UINT pixels[width*height]" and use the windows SetDIBitsToDevice to plaster the result on whatever you need to. Its really fast.   ;  Alright, I'd like to again thank everyone for helping..I think this thread has accomplished the task of making me realise that finding a faster transfer method isn't the real problem- optimising the transfer is. I was just too lazy to try..I've devised a simple method of analyzing differences in updates to the main drawing canvas, which will use glTexSubImage2d when *necessary* to update small parts of the texture being displayed. If anyone knows any caveats or pitfalls with this, please tell me.Fiddler:Tried, but the Allegro and Cairo APIs are scary. Meep.CPPNick:Trying for multiplatform code, thanks though.   ;  Well, you could try splitting up the terrain into a bunch of smaller sub-textures. Then you only have to do small updates to the parts of the terrain that actually changed that frame. (I'm not familiar with the game, but, I imagine the terrain remains relatively static on a frame-by-frame basis).The particles can be drawn with a standard-ish particle renderer that outputs vertices at the pixel locations of the particle and rendering each vertex as a pixel, which can be done much faster than modifying a texture.   