2010-01-25, 10:03 AM
I had a chance to talk to Asus and I think what is happening in his case is he's looking thru many sheets of fire with each one filling up more or less every pixel on the entire screen. Graphics hardware has two chief limitations, 1) how many vertices it can draw, and 2) how many pixels it can fill... no hardware is really geared to redraw every pixel many times at maximum resolution. That will cripple any game platform quick. If you lower the resolution to about a quarter of your hardware's max you might get better results, but this is generally not best practice scene design.
PS: I've actually been planning to try something / may take another detour before finishing translation work involving detecting when Som flashes the screen (ie. draws a swath of pixels over the entire screen) ...I have other reasons for being interested in this, however one think I want to find out is if the rgb flash events can be made transparent. If so I'll setup an extension so you can set the transparency level. And I will also setup the first extension that accesses the counters which will let you write a colour into a counter of your choosing which will be used instead of one or all of the R G B flash events. If possible that will even let you do a cheesy mesmerizing flame effect. Somewhere down the road I will add support for any number of screen effects, like underwater and desert-like heat-wave vision and some mechanism for letting everyone devise new effects of their own. Anyway, maybe Asus can do his flame walk that way yet.
UPDATE: I was successful in this. I was wrong in remembering the flashes being just opaque. They do actually fade in/out albeit very quickly.... culminating with a fully opaque frame -- or I'm guessing it's just one. It's the non-transparent frame that is pretty jarring I think. Theoretically you could mask an object transition like this, but I wonder if the timing would be even close. The RGB flashes are blended by colour intensity rather than alpha (though that could be monkeyed with) ...it's rather fortunate I guess there are not white/black flashes because that would be hard to interpret vs the w/b fade in/out events. I don't know if you could somehow blend the RGB flashes by using different instructions simultaneously (has anyone ever tried that?)
Probably the best way to soften them if that's what you want is to just clamp them before getting to full brightness. Anything much else tends to truncate/distort the curve. A soft clamp would probably be an improvement. I also played with changing the lightning in Thedeck's area in DD to white since Todd mentioned he wanted white. That's doable anyway, but some proper settings should probably be established first. I'm thinking having a 16bit colour stored in a counter to change the effect, which would be 4bits for each channel including alpha. That will let you do black flashes also and control transparency independent of intensity.
PS: I've actually been planning to try something / may take another detour before finishing translation work involving detecting when Som flashes the screen (ie. draws a swath of pixels over the entire screen) ...I have other reasons for being interested in this, however one think I want to find out is if the rgb flash events can be made transparent. If so I'll setup an extension so you can set the transparency level. And I will also setup the first extension that accesses the counters which will let you write a colour into a counter of your choosing which will be used instead of one or all of the R G B flash events. If possible that will even let you do a cheesy mesmerizing flame effect. Somewhere down the road I will add support for any number of screen effects, like underwater and desert-like heat-wave vision and some mechanism for letting everyone devise new effects of their own. Anyway, maybe Asus can do his flame walk that way yet.
UPDATE: I was successful in this. I was wrong in remembering the flashes being just opaque. They do actually fade in/out albeit very quickly.... culminating with a fully opaque frame -- or I'm guessing it's just one. It's the non-transparent frame that is pretty jarring I think. Theoretically you could mask an object transition like this, but I wonder if the timing would be even close. The RGB flashes are blended by colour intensity rather than alpha (though that could be monkeyed with) ...it's rather fortunate I guess there are not white/black flashes because that would be hard to interpret vs the w/b fade in/out events. I don't know if you could somehow blend the RGB flashes by using different instructions simultaneously (has anyone ever tried that?)
Probably the best way to soften them if that's what you want is to just clamp them before getting to full brightness. Anything much else tends to truncate/distort the curve. A soft clamp would probably be an improvement. I also played with changing the lightning in Thedeck's area in DD to white since Todd mentioned he wanted white. That's doable anyway, but some proper settings should probably be established first. I'm thinking having a 16bit colour stored in a counter to change the effect, which would be 4bits for each channel including alpha. That will let you do black flashes also and control transparency independent of intensity.