Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to draw different per-pixel data on the screen, where each pixel has a specific value according to my needs. An example may be a random noise pattern where each pixel is randomly generated.

I'm not sure what is the correct and fastest way to do this. Locking a texture/surface and manipulating the raw pixel data? How is this done in modern graphics programming?

I'm currently trying to do this in Pygame but realized I will face the same problem if I go for C/SDL or OpenGL/DirectX.

share|improve this question
What are you actually trying to do? The only answer possible here is like one line long and the only good answer would be "it depends." – Sean Middleditch Jun 11 '13 at 0:54
I'm trying to draw and array of heights from their height to the bottom of the screen, while changing the color of every pixel on the way down (creating some retro ground-like effect). I've just tried SDL 2 and streaming textures and it seems to be working nicely. – Amir Eldor Jun 11 '13 at 1:05
@stas - this doesnt seem like premature optimization, it seems more a case of doing things the sensible way to begin with. – Le Comte du Merde-fou Jun 11 '13 at 8:04
You want to change the texture each frame? Then the fastest version might be compute shaders that manipulate the texture directly on the graphics card without the need of uploading the texture each frame from the cpu to gpu. However, you might still have to upload some state data to the compute shader each frame, i.e. the noise generator state or whatever, but this might be significantally less than uploading the entire texture, plus compute is able to manipulate the texture much faster in parallel than a single cpu thread can. – Maik Semder Jun 11 '13 at 8:10
@stas - even so, it still doesn't seem like premature optimization. It was wrong to just throw the old Knuth chestnut at this question; not all performance improvements are premature optimization (even Knuth acknowledges this in the full context of the quote); some are a basic requirement of what a person is trying to do, and in this case it seems to fall squarely into that latter bracket. – Le Comte du Merde-fou Jun 11 '13 at 17:30
up vote 2 down vote accepted

I'm not sure what is the correct and fastest way to do this. Locking a texture/surface and manipulating the raw pixel data? How is this done in modern graphics programming?

If this is something to recompute each frame, if the only input you need is the pixels position, and if you only need to output this directly to the screen, I suppose the modern and fastest way to to this is to simply use a pixel shader on the GPU. Render a full-screen quad with your favorite engine, with a pixel shader that computes a color from the pixel's position. This is similar to doing a full-screen post-process.

If you only need to recompute this one in a while, or if you need to output to something else than the screen, you could render to a texture for later use.

If you need more inputs than simply a pixel's position, you'll have to find a way to pass this info to your pixel shader. You can use uniforms, textures etc. for this purpose.

There are cases where you could use the CPU for the sake of simplicity. It will be easier to handle inputs/outputs, and you could save some texture copying time in some cases, but you'll need to workaround the fact that CPUs aren't really made to work on arrays of pixels. To avoid hiccups, you'll have to do it during a loading time, on a different thread, or even offline.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.