LWJGL Updating a screen full of pixels every frame

[hvince95]

Hello,

For the past few weeks, on and off, I have been looking through techniques of updating and rendering a screen full of pixels every frame (approximately 900x600, ~500,000 pixels).  Over this period, I have learnt how to use Framebuffer Objects, Display Lists, and Vertex Buffer Objects - learnt quite a bit - but all of these methods seem too slow (unless I am doing it wrong).

Is there a fast way to draw this many pixels to the screen, many of which may be updated every frame?  Even a working example somewhere that just sets every pixel to a random colour and I can work from there?

The main thing that slowed down the process previously was updating all the pixels.  I figured I could make little sections, or chunks, which all have their own FBO, or VBO, and are updated and rendered seperately, but I am yet to implement this.

Thankyou.

[princec]

Allocate a framebuffer object. Map the object into address space using glMapBuffer(). Poke values directly into FBO. Unmap. That sort of thing? There is no "fast" way to do this, especially not with random access.

Cas

[davedes]

What are you trying to accomplish exactly?

The best way to modify a texture (or the screen) pixel-by-pixel is through fragment shaders.

If it needs to be done on the CPU, you'll have a harder time. The standard approach is to modify your pixel array (or ByteBuffer) and upload the new data to your full-screen FBO texture with glTexSubImage2D. This can be costly and obviously isn't something you should do many times per frame. You can optimize by uploading a smaller amount of data where possible, or not uploading any data when nothing changes.

You can also use PBO to make the data transfer asynchronous, which may increase performance.

Another optimization may be to tweak the format and internal format of your texture and pixel buffer, depending on your needs. This could result in sending less data to the GPU (i.e. RGBA = 2,160,000 bytes, LUMINANCE = 540,000 bytes).

If you don't mind losing colour information, you can specify different internalFormat sizes to reduce memory such as GL_RGB5 (5 bits per channel). You can also specify different formats to reduce bandwidth such as GL_RGB_5_6_5 (Green gets an extra bit). More info on the color space here. Some more OpenGL details on formats here and here.

Another solution would be to use a low resolution texture (i.e. half size, 450x300), then render it scaled to the screen using GL_NEAREST filtering. You can see this effect in GLSL sandbox, where selecting a different number (0.5, 1, 2) will change the resolution and thus drastically alter performance.

TL;DR - use shaders.

Games published by our own members! Check 'em out!

[hvince95]

Thankyou both for the replies,
You say use shaders, but of what I have learnt (not much!), I don't notice any performance increase when rendering to the screen.  I also have no idea how to store things on the GPU and edit them while they're there.  Maybe what cas was talking about with glMapBuffer()?

[princec]

Think of the GPU as being a remote city on the other side of a narrow bridge accessible only via a little red bus service from the CPU. Think of the little people on the bus as carrying instructions to draw pixels. Each little commuter guy has a briefcase with some instructions for the people on the other side of the bridge; for example, one guy can hold a briefcase with an instruction in it to change the colour of the pixel at (128,128) to red. Or he might have an instruction to replace the entire framebuffer with the contents of the next bus, which will be stuffed with paper.

A bit of thinking from there on will maybe get you to what you need to do.

Shaders will only work if what you are trying to achieve is procedurally applicable to large number of pixels simultaneously.

Cas

[hvince95]

Might I ask what glMapBuffer() does and how to use it?  Should I use glMapBuffer() before rendering and then glUnmapBuffer() after rendering, or should do this when editing the pixels, or both, or just have it mapped the whole time, throughout the whole game loop?