Author Topic: [PROCEDURAL] glsl_plasma  (Read 14204 times)

0 Members and 1 Guest are viewing this topic.

Offline Deleter

  • C= 64
  • **
  • Posts: 73
  • Karma: 11
    • View Profile
    • Deleter's Rants
Re: [PROCEDURAL] glsl_plasma
« Reply #20 on: May 08, 2008 »
Quote
Error 0:7: 'assign' : cannot convert from 'attribute 4-component vector of float' to 'varying 3-component of float'

edit: seems as if he's already figured out whats up with it ;)
« Last Edit: May 08, 2008 by Deleter »

Offline Dr_D

  • Atari ST
  • ***
  • Posts: 151
  • Karma: 29
    • View Profile
Re: [PROCEDURAL] glsl_plasma
« Reply #21 on: May 08, 2008 »
So it works for you now? Man, I really wish there was a standard. That seems so counter productive for one brand of card to support some of the funcions, and another brand to fallback on software. Especially that casting error. I wish they would at least make a standard for the type structures. You know what I mean? That's part of the language itself, which should be constant. Also, the documentation could use some work because according to the book i've been reading, it doesn't say anything about not using the built in trig functions, or the use of them bloating it. :\
The Dr. is INsane!!!

Offline hellfire

  • Sponsor
  • Pentium
  • *******
  • Posts: 1294
  • Karma: 466
    • View Profile
    • my stuff
Re: [PROCEDURAL] glsl_plasma
« Reply #22 on: May 08, 2008 »
You're probably interessted in some of these.
ShaderModel 2 is not very far from 1.1 (very limited instruction-set) except of higher precision and longer programs.
All what GLSL does is translating your commands to the available instruction-set - unluckily most of the things it does is hidden from the user...
Challenge Trophies Won:

Offline Dr_D

  • Atari ST
  • ***
  • Posts: 151
  • Karma: 29
    • View Profile
Re: [PROCEDURAL] glsl_plasma
« Reply #23 on: May 09, 2008 »
Hmm. Well, yes, I have the books from that list that were recommended to me. I didn't read anywhere suggesting not to use native trig functions or glFragCoord... which seems ridiculous to me, in the first place. If that's the case, then ATI has serious issues and is going to fail, eventually. What's next? Don't use RGBA because it falls back on software? Don't use swizzling? Don't use any of the native noise functions? That's silly. It's ok... just forget about it. I did my research, so if it doesn't compile and run properly using functions that are supposed to be part of the standard, it isn't my fault. Thanks for the advice, but I'm going to stick with what's in the books. ;)
The Dr. is INsane!!!

Offline hellfire

  • Sponsor
  • Pentium
  • *******
  • Posts: 1294
  • Karma: 466
    • View Profile
    • my stuff
Re: [PROCEDURAL] glsl_plasma
« Reply #24 on: May 09, 2008 »
The link refered to that "GLSL Validate"-Tool which checks your source for standard-compliance, so your shader won't contain "errors" your driver just doesn't tell you about.
In this case you shouldn't blame ATI - although they did (and still do) have some ridiculous bugs in their drivers (especially on the OpenGL-side), like that fragcoord-thing for example (which seems to be fixed for a while already) - however, your fragment program probably (haven't tried) would't work on ps2.0-based nvidia-cards either.
Usually ATI goes the more compatible way, giving better precision, less surprises (and bigger code) while Nvidia "optimizes" your code pretty optimistically (which can fail pretty badly, too).
I just wish that the glsl-compiler would give some more feedback about that (instead of just falling back to emulation) or shows the produced assembler-code (what Direct3D does for example)...
Challenge Trophies Won:

Offline Shockwave

  • good/evil
  • Founder Member
  • DBF Aficionado
  • ********
  • Posts: 17412
  • Karma: 498
  • evil/good
    • View Profile
    • My Homepage
Re: [PROCEDURAL] glsl_plasma
« Reply #25 on: May 09, 2008 »
Thanks Hellfire for making a compatible version of this so that finally I am able to run it. For all the effort that you put into sorting this out it deserves some good karma, especially as you're helping a fellow competitor in the competition out.

Very sporting of you.

Thank you!
Shockwave ^ Codigos
Challenge Trophies Won:

Offline benny!

  • Senior Member
  • DBF Aficionado
  • ********
  • Posts: 4384
  • Karma: 228
  • in this place forever!
    • View Profile
    • bennyschuetz.com - mycroBlog
Re: [PROCEDURAL] glsl_plasma
« Reply #26 on: May 09, 2008 »
...
For all the effort that you put into sorting this out it deserves some good karma,
especially as you're helping a fellow competitor in the competition out.

Very sporting of you.

Thank you!

I 100% second that!
K UP!
[ mycroBLOG - POUET :: whatever keeps us longing - for another breath of air - is getting rare ]

Challenge Trophies Won:

Offline Pixel_Outlaw

  • Pentium
  • *****
  • Posts: 1382
  • Karma: 83
    • View Profile
Re: [PROCEDURAL] glsl_plasma
« Reply #27 on: May 12, 2008 »
I also had problems running your demo. I have a ATI Radion Xpress 1100. The second lens demo worked fine though.

I was able to do a screen grab of my error message seconds before it exited.
Challenge Trophies Won: