Re: [M-dev]RES: Marathon-devel digest, Vol 1 #1372 - 3 msgs

[Joe A. <av...@ml...>]

On Mar 13, 2004, at 9:59 PM, Br'fin wrote:
> On Mar 13, 2004, at 6:15 PM, Dietrich Epp wrote:
>> On Mar 12, 2004, at 9:53 PM, Br'fin wrote:
>>> On Mar 12, 2004, at 11:37 PM, Daniel Monteiro wrote:
>>>> Well ...I=B4m a OpenGL programmer too =3D-)
>>>> If I were one of the devs ,I would use a pre-rendered sprite for=20
>>>> the static
>>>> efect
>>> That is possibly awkward, because of the things that can be applied=20=

>>> static. It's not just Spht death, but you can apply this to wall=20
>>> surfaces, and even marine sprites. And it's supposed to be all=20
>>> flashy and stuff over the course of several frames even if the=20
>>> sprite itself isn't changing frames during those times.
>> You can use pre-rendered static if you change the texture's <u,v>=20
>> offset to a random value every frame.
> I'm not sure this would work, even with randomly H or V flipping as an=20=

> option each frame. It might not come out well enough as static, but=20
> instead come out as jitter as the human eye picks up the repeats in=20
> the singly used texture.

So use a very, very large non-repeating texture and vary the u,v over a=20=

correspondingly large range. If you can get maybe three frames in a row=20=

without repeating areas that should be enough to break the eye's=20
ability to track it. I don't think it'll be hard to do that.

Also, OpenGL might have some really (computationally) cheap effects we=20=

can randomly apply - invert and hue-shifting would do perfectly.

Having multiple static textures, one of which would be randomly chosen=20=

for each static-textured object (but once chosen it stays the same,=20
OpenGL probably likes that better) would also help the static to look=20
less cheaply pre-rendered.

Disclaimer: IANAGP (I Am Not A Game Programmer) :)

Joe Auricchio ~ av...@ml...=