Spring RTS Engine

New snow gadget; like the rain, it uses a cut-down P.O.P.S. variant, and is a lot faster than previous code.

Needs the bitmaps- put into bitmaps/snow.

See release below; short of bugs, this is the final release, with a balance between aspects of performance, compatibility and speed.

And I still see nothing
Btw, old snow was practically free for me anyway.

Edit: same with new rain.

Well, that's annoying. I'll check the shader log.

OK, the shader log is now totally empty over here... if it doesn't do anything, please find the line where it says "Snow shader log".

still nothing

Ok... did you put the file in LuaGaia/Gadgets...

And put the usual two files into LuaGaia/ ? ...see attached.

Here's another potential fix. I found a layer conflict that can cause it not to operate properly (under unusual circumstances, mind you). It does cause the "running but no errors" behavior you described, though.

gagdet in luagaia/gadgets, added main and draw to luagaia, flakes in bitmaps, and still nothing

Flakes in bitmaps/snow... but that should have caused errors.

Ok it works now.

Pops snow:
Pros:

• fast (275 fps on my testmap)
  realistic snow movement
  nice varied snowflakes

Cons:

• Wierd bout of snow at start
  snow is tied to camera, looks super fake when scrolling (rain is also tied to camera, but its much less noticeable.

trepans snow:
Pros:

• fast (285 fps)
  snow is tied to map, so its much more realistic

cons:

• snow particles sometimes float on water for a while before disappearing, i should fix that
  particles close to camera arent culled, can be annoying when zoomed out alot.

OK, here's another potential cause of problems- apparently, under some weird circumstances (I caught this running both snow and rain simultaneously) you can cause a matrix problem, which means the snow doesn't get translated correctly.

This fixes that problem (now I see rain, snow and regular P.O.P.S. stuff all behaving correctly at the same time).

As for pros / cons:

1. I didn't have the same performance you're reporting- this is faster on my hardware (I've finally ordered a new motherboard, but for now I'm still stuck on the old rig). This is due to the size of the display lists, basically. The tradeoffs are that it eats a teeny bit more CPU doing events.

2. Fixing the snow on water's easy enough- if gl_Position.y <= 1, just give it a new gl_Position way up in the sky.

3. Yeah, I tied it to the camera, because I wanted to keep performance up. I really don't think it's that bad if you aren't looking for it. The only really practical way to remove that is to go back to the Giant Display List of Dewm, which I'd really like to avoid.

4. Most importantly... even after I spent time debugging that version I posted awhile ago, trepan's shader still borks on a lot of hardware. Since P.O.P.S. has already been tested and found to be working on most hardware, and since people have said that they can't see the trepan snow, I thought I'd give it one more shot. I think stuff like snow is really cool and adds a lot of atmosphere.

1. As usual, YMMV. I have an 8800gt, and 1 shader per map is practically free for me. Even two hardly hit performance. Mind you this gfx card and system is 3 years old now.
2. Cool, ill do that.
3. I see
4. Glad it works on most hardware, these effects are awesome.

Argh wrote:3. Yeah, I tied it to the camera, because I wanted to keep performance up. I really don't think it's that bad if you aren't looking for it. The only really practical way to remove that is to go back to the Giant Display List of Dewm, which I'd really like to avoid.

I noticed this with your earlier work on the rain effect as well.

It is really noticeable when the user scrolls to check his units. I would say that it is worth the effort to fix.

In my opinion it isnt really noticeable with rain, in fact I only noticed it after slowing down the rain a _lot_.
But with snow its hard not to notice.

I noticed it with the rain right away, but assumed arturri was using a very early version of this rain code. Cuting corners like this to get higher fps pretty much defeats the purpose of such an effect.

Another bug: seems like the shader is leaking somewhere, the number of snowflakes on screen gets smaller (down to 5 by 20 mins) and the fps drops.

Well, some good news- I think I've figured out a reasonable way to get it done.

More when I've had a little more time to polish it.

Oh, and you're quite right, the drift is causing a problem which I'll have to fix.

OK, here's a fix for the drift problem, and it's not tied to the camera's position.

It uses instancing to keep the number of particle updates really low. I'm going to try one more change, to see if it speeds it up any, but I doubt it. This is somewhere in between the performance I see with my modified version of trepan's code using point objects and the P.O.P.S. version- I don't really like it's performance, but it's probably going to run on ATi OK.

Version 0.6.

This is the final version; uses a selective instancing check to determine which systems to run, and is quite fast for overhead views (and reasonable for long views, although ymmv for long views on giant maps).

Here's a screen with reflections turned on (see source for details, and be warned that it's expensive):