Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (601)
Games in Android Showcase (171)
games submitted by our members
Games in WIP (649)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  LWJGL Updating a screen full of pixels every frame  (Read 2016 times)
0 Members and 1 Guest are viewing this topic.
Offline hvince95

Junior Devvie

Medals: 1
Projects: 2

« Posted 2012-10-31 00:37:11 »


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.

Offline princec

« JGO Spiffy Duke »

Medals: 555
Projects: 3
Exp: 16 years

Eh? Who? What? ... Me?

« Reply #1 - Posted 2012-10-31 00:45:25 »

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 Smiley

Offline davedes
« Reply #2 - Posted 2012-10-31 04:40:28 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline hvince95

Junior Devvie

Medals: 1
Projects: 2

« Reply #3 - Posted 2012-10-31 05:26:24 »

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()?
Offline princec

« JGO Spiffy Duke »

Medals: 555
Projects: 3
Exp: 16 years

Eh? Who? What? ... Me?

« Reply #4 - Posted 2012-10-31 09:21:35 »

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 Smiley

Offline hvince95

Junior Devvie

Medals: 1
Projects: 2

« Reply #5 - Posted 2012-11-01 07:44:25 »

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?
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Jesse (12 views)
2015-07-29 04:35:27

Riven (35 views)
2015-07-27 16:38:00

Riven (18 views)
2015-07-27 15:35:20

Riven (20 views)
2015-07-27 12:26:13

Riven (11 views)
2015-07-27 12:23:39

BurntPizza (30 views)
2015-07-25 00:14:37

BurntPizza (41 views)
2015-07-24 22:06:39

BurntPizza (24 views)
2015-07-24 06:06:53

NoxInc (27 views)
2015-07-22 22:16:53

NoxInc (18 views)
2015-07-22 22:13:39
List of Learning Resources
by gouessej
2015-07-09 11:29:36

How Do I Expand My Game?
by bashfrog
2015-06-14 11:34:43

List of Learning Resources
by PocketCrafter7
2015-05-31 05:37:30

Intersection Methods
by Roquen
2015-05-29 08:19:33

List of Learning Resources
by SilverTiger
2015-05-05 10:20:32

How to: JGO Wiki
by Mac70
2015-02-17 20:56:16

2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21 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‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!