[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] 127.5



Practical graphical applications often use textures to store data as well. Deferred renderers store all the geometry data in a gbuffer texture for example. For screen space ambient occlusion and many other screen space lighting techniques people often render a float linear depth in one channel and the per pixel normal in the remaining channels. When you start wanting per pixel 3d vectors of any kind its nice to have 32-bit precision available.

-Devon

On Fri, Jul 30, 2010 at 9:25 AM, Luke Paireepinart <rabidpoobear@xxxxxxxxx> wrote:
On Fri, Jul 30, 2010 at 9:10 AM, Ian Mallett <geometrian@xxxxxxxxx> wrote:
> The problem:
> Because of this, I need a surface filled with the color 127.5. Obviously,
> more than 8 bits per channel are required. To update the texture, I'm using
> GL_RGBA32F_ARB, which allocates 32 bits per channel. Unfortunately, the
> base image created by PyGame has a value of 127 â -0.00196 velocity. In
> practice, this leads to "drift" in the simulation. Can something be done to
> send a 32 bit per channel surface filled with 127.5 values to the OpenGL?


Is it really 32 bits _per channel_ and not total?
I've never heard of that much bit depth before, why would that
possibly be necessary? ÂI mean for practical applications, not using
textures to store data so you can use shaders to run your sim :P
-Luke