pouët.net

It's not ATI-only, read the thread, there are some comments that "runs slow on my GeForce FX" or so.

sadly It doesn't run on my 9700PRO and win2000 :(

"But all the features that aren't supported by G400 will be simply software emulated (brrr)."

Wrong, nothing except vertexshaders are emulated. Software rasterizer is only available in the SDK, and you must manually fallback to it.

"And that's why it's easier for programmer to use DX than OpenGL (which offers many vendor specific features)."

Funny that you wrote it like you did, since OpenGL does fallbacks on prety much everything, exept on extensions ofcourse.

"On the other hand the best new "thing" in DX9 are floating point pixel format textures. But I don't remember any demo that uses it."

Should we then really call it the best new thing? HLSL is being used in most of the new dx9 intros/demos. And there are some problems with floatingpoint textures that makes people not wanna use it... (for instance you have to take care of texturefiltering manually in shaders).


"Btw Take a look at CandyTron's glow - It's very simple and cheap when using ps2.0 but this Intro actually does it without this technology."
Wow, how can they? Ehm, hint: You dont need floatingpoint textures for such things as long as you can manually control the colors in the scene. The problem is when you want to do it with bright colors since you will then loose the details when mixing the colors...

And what about PN triangles - as far as I'm concerned they're also emulated (and because of PN triangles I've written this sentence about emulation).

Yes you are right about that software rasterizer in GL, but I meant emulation of extensions (ie PN triangles).

Don't understimate the power of floating point buffers :O ...

About that glow: Of course it can be done in register combiners or env combiners, but then You'll mostly get that square artifacts arround glowy objects.

I meant that in ps 2.0 it's a piece of cake, and with ps 1.1 (Am I wrong?) It can be done.

I'm done and I'm sorry for entering this discussion. I'm so busy nowadays, and my brain's good days have passed in august.

Bye.

"About that glow: Of course it can be done in register combiners or env combiners, but then You'll mostly get that square artifacts arround glowy objects."

What the hell?!
Anyway, I'm not even going to explain this.

bonzaj: the glow effect doesn't even need vertex or pixel shaders - completely doable with a bit of postprocessing magic and small filter kernels (which boil down to multitexturing and alphablending, available since TNT1)

As far as precision is concerned - there are like a dozen methods for determining the glow's "source image"; it's all a matter of if you concentrate on performance, image quality, versatility or whatever.

PS: the glow effects of FR-025 or 030 eg. don't even need any modifications to the engine, they're pure post-processing effects. Making them look good is just a matter of choosing the right parameters :)

KB: I'm still interested how many times do You sample the glow "source image" - which as I asume is an alpha buffer?

;P

my god, all you need is render2texture and mipmaps to do a sweet smooth glow ...

why do people insist on shaderising every single effect ...

my 5 eurocents

I'm still trying to find a way to do chroma-keying in opengl without a pixel shader (or texture shader, or register combiner). It was possible and hardware accelerated on Glide + Voodoo, but seems it's just not there for OpenGL, and as much as I struggle my head with it, can't find of a lowend-compatible way to do it :|

If anyone has gone into that (without using PS/FP or equivalents), let me know =)

Maybe DirectX has it, I dunno

Oh pleeeease. Downsample-then-upsample "blurs" look as bad as it gets. Either do it properly or don't do it at all, but not this kind of ugly fakes :)


The source image is exactly that, the normal rendered scene, processed a bit to get only the highlights (that's easy enough, just a subtract and maybe some intensity adjustment mostly).

For typical kernel sizes (i.e. 8-32 pixels in diameter), we need between 12 and 20 texture samples. In case someone wonders about the quality of this, the purplish "blob" behind Josie in the end scene of Candytron final is actually a copy of the mesh translated a bit then blurred to death - note how the shape changes a bit when she lifts her arm :)

I tried to keep it simple :)

don't give away the big secret ...

damn fr blurposers ! :)

i've explained the complete algorithm 2 times on flipcode and i'm just too lazy to find one of the urls. search for yourself.

......And still it was old before candytron :)

well, first time we used that blur routine was in fr-minus-04. :)

blurp :)

No idea when fr-minus-04 was released but i know this technique is old.

Someone please try to find the flipcode thread that Ryg mentions. I just tried and failed :/

that's because it's too blurred to see it :P

My mind is a picture
Slightly out of focus
Blurred enough to see
Life is an entity

-- Quad, 1997

pete:

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=00002053&forum=randombits&id=-1

watch out for bbcode fuckups

kb, thanks :)

I was always scared of using so much passes ...
Well and now because I'm a more graphician than a true coder I feel a bit excused of using the shaders.
Great work guys!

my new machine now plays all dx8/9 demos... strange that it didn't before, as i tried some after a reboot and no major config changes have been made. So maybe theres hope for better compatability if people can make ati compatable stuff too.

About the fr blur method, i didn't realise you could get away with that many passes either, especially as most of the demos that use it run fine on a gf4mx! Will fr be doing ps/vs stuff soon tho or will they be sticking to squeezing even more out of dx7 cardS?