Many of them use a variable called surface position, that’s picked up from an underlying vertex shader I think, so if you want to use them as a 2d shader you have to change that to reflect the screen co-ordinates divided by the resolution.
I had fun adapting some of them to my own uses and they taught me a lot about shaders too.
@solarlune yea i did notice the lag, but from observation i have a file curve file with no errors, and no bloom shader. This file ran above 30 fps with 20 curves and solid 60 with close to ten curves. the bloom shader alone drops the fps, but i was hoping it was because i hadnt tuned it yet. can u remove the 2d filter and test it plz? so i can have a true scale of the issue. also i think i have some errors like i said. i think is a simple error, but i have a few different files and i kind get confused with them.
also how did u do it without a shader. i tried get vetex and the way its arrayed seemed different from glVertex. please help, because i am going to run into an issue with collison. i was planning on using the formula of the curve to set up some custom bounds, but thats probably a headache in the making.
OK, so turning on the bloom filter actually decreases logic usage for some reason. I think you would do well to clean up that blend file and the scripts you’re using for it - it’s not helping you debug or optimize (printing out “Invalid uniform value: time”, for example).
Anyway, the glow isn’t the problem - it’s the curve shader / object. The game runs at 60 FPS, but it’s around 19% logic usage just from the one curve (and perhaps the “Invalid uniform” command line output). So actually, maybe you should clean up the scripts and see if it improves.
Pay attention to the console!
P.S. I committed an example of how I did it without a shader to my repository - just use SVN to get the example blend file and trail.py file to see it work.