[Resource] JonnyFive's WeatherFX (9/17/08 update)

[Unknown_Assassin]

I am using ZDoom 2.2.0 and I had an FPS of 87-92 (the 90's are mostly because of the rain).

Intel Core 2 Duo T5550 @ 1.83 GHZ. I have 2.00 GB RAM, and I am using Windows Vista. My screen resolution is 1024 X 768 in ZDoom.

[JonnyFive]

Unknown_Assassin, that's great.

I uploaded another version with a minor bug fix. The program wouldn't handle WFX_IgnorePlayer correctly because it didn't initialize the boundary position correctly. It should now work correctly.

[Enjay]

Seeing as how I have now given it a more thorough workout, here are a few comments:

I did get noticeable lagging with larger maps and high weather density. It wasn't awful. The maps remained playable, but it was definitely there. Reducing drop/flake density (sometimes lower than I would have liked) made a difference. This was particularly obvious in one map which had a very large open area, with lots of lines, slopes, some translucency, a handful of 3D floors and some fog.

I noticed that, sometimes, particularly near the start of a map, weather could appear where it shouldn't. eg, in one map, when you started the weather could spawn inside a room with a ceiling lower than the weatherspot z heights. It wasn't the entire room that was affected, just a line of rain appearing near one wall. Possibly a similar effect was noticed in another level where a slight flutter of snow (not the full storm) would appear inside a room near the player start. Interestingly, delaying the start of the weather effect by triggering it using a (void) script, seemed to get around the issue. In both maps, the player is allocated a tid buy using an enter script.

And finally, I had an odd situation that I noticed when looking at the automap. I would sometimes be getting quite a bit of rain in the void space. In particular, one map always showed it when one particular weather zone was active. It isn't something you can see unless you are on the automap and cheating, but it was there. Here's a screenshot.



The green rectangles are weather zones. The red rectangle is the main area of concern. All the items in there are raindrops in the void space. It always seems to appear in a roughly rectangular area in that part of the map. The smaller yellow one also identifies a few raindrops in the void, but this is nothing like as severe. The player is in the magenta rectangle during this screenshot.


[edit]actually, whilst I remember it, see that large green rectangle that goes off the top of the pic? See the line of things along its bottom edge? They are raindrops. That bottom edge is fine, but just below it is a solid wall and you can probably make out a door into a room. The area through that door is the room where I would get a line of rain appearing along the wall that runs parallel to the horizontal green line. ie, the rain was spawning inside a room with a lower ceiling than the weatherspots' height and, what's more, the line of rain was spawning outside a weatherbox entirely (albeit only just).

[JonnyFive]

Thanks for the testing, Enjay, I'm looking to try to improve this as much as possible.

I think the erroneous spawning might be due to a delay between the assignment of a TID to the player and the start of the weather code. I'll have to look into it more to see if it can be fixed.

I uploaded a new version that will kill rain particles after five seconds and snow after a bit more. I think the problem is that the particles spawned inside the void but the game engine didn't destroy them (because they were in the void, after all). There was no timeout for the particles, so they would remain forever. I noticed the same problem trying it out in a bigger GZDoom WAD.

I'll look this over later tonight (I have a class in ten minutes) to see if I could add in some kind of check to the spawner itself to prevent it from spawning in void space. Canning the issue with stuff spawning in the ceiling should be easy enough using a z-check in DECORATE on the spawner itself.

Is there a more solid way to check the player position besides assigning them a TID? GetActorX(0) and such only works if the player is the activator of the script, and doesn't seem to work in a function.

EDIT: Any chance you could post your example map with the version of weatherFX you have it running?

[Enjay]

I think the erroneous spawning might be due to a delay between the assignment of a TID to the player and the start of the weather code. I'll have to look into it more to see if it can be fixed.

Yeah, I was thinking that too. IIRC, there can be a noticeable difference between open scripts starting and enter ones. Which, I guess, is why starting the weather script manually later on did the trick. Perhaps simply putting a slight delay in the open script might do it?

I think the problem is that the particles spawned inside the void but the game engine didn't destroy them (because they were in the void, after all). There was no timeout for the particles, so they would remain forever. I noticed the same problem trying it out in a bigger GZDoom WAD.

I don't think that's it. Watching them in the automap when actually playing, they seem to be getting spawned and destroyed just like the ones in a valid area. Here's a gif made from a few rapid screenshots.

Is there a more solid way to check the player position besides assigning them a TID? GetActorX(0) and such only works if the player is the activator of the script, and doesn't seem to work in a function.

Not that I know of, but the likes of Hotwax would be far more likely to have a definitive answer.

EDIT: Any chance you could post your example map with the version of weatherFX you have it running?

Not easily I'm afraid. It's a bit of a mish-mash of stuff and a bunch of resources thrown together for testing etc etc. Cutting it down to an easily up loadable test map might take some time. If I can get around to it, I will do but it may not be until the weekend. [edit]Actually, I just remembered that this weekend will be very busy too, so I'm not sure how much time I will have.[/edit]

[Enjay]

I'll look this over later tonight (I have a class in ten minutes) to see if I could add in some kind of check to the spawner itself to prevent it from spawning in void space. Canning the issue with stuff spawning in the ceiling should be easy enough using a z-check in DECORATE on the spawner itself.

Question, presumably every time you add a check, it adds to the processing time for deciding whether a particle will spawn or not. Is there a danger that adding additional checks may cause more delay than leaving it alone and accepting that, occasionally, there might be some spawning in the void?

Also, any idea why the ones spawning in the void were definitely doing so in such a well defined, rectangular area - almost as if that had been set up as a weather zone? I've checked and double checked my weather spots.

[JonnyFive]

I'll look this over later tonight (I have a class in ten minutes) to see if I could add in some kind of check to the spawner itself to prevent it from spawning in void space. Canning the issue with stuff spawning in the ceiling should be easy enough using a z-check in DECORATE on the spawner itself.

Question, presumably every time you add a check, it adds to the processing time for deciding whether a particle will spawn or not. Is there a danger that adding additional checks may cause more delay than leaving it alone and accepting that, occasionally, there might be some spawning in the void?

Also, any idea why the ones spawning in the void were definitely doing so in such a well defined, rectangular area - almost as if that had been set up as a weather zone? I've checked and double checked my weather spots.

It turned out to be a peculiar bug relating to the random spawning code. Apparently the random function was occasionally returning values that were actually outside the bounds of the weather zone. It added a line of ACS to enforce the weather zone bounds and suddenly the problem disappeared on a larger test map. I'll upload the fixed version in a couple minutes and you can try it out and see.

I also added checks on the particles for water (to destroy itself when it hits water) and z-checks on the spawners for the ceiling position. If this burdens things too much, I'll pull it from the default DECORATE, but I don't think it'll be an issue.

The addition of the extra check on the bounds is trivial - just a single AND check on the spawn coordinates against the bounds before spawning each particle. It will add a little bit to the overhead, but the alternative is some really buggy spawning.

It still spawns particles in void space around the player, but that's understandable (since the spawn code doesn't care if something is in the void or not), and I don't care if it does that. The problem was the wonky spawning of stuff that should be outside the player's radius.

The upshot of all this is that the player's TID doesn't seem to be the problem. The script will check the PlayerTID variable every time it runs, so even if there's a short delay in assigning a TID to the player, it should self-correct after one iteration of the loop. With the spawning code fixed this seems to be the case.

Anyway, let me know if it's lagging significantly more now. (I've added map02 that has a big area with some rain to test out).

[Enjay]

OK, thanks. Hopefully I'll get a chance to check this when I get home.

Is it possible for you to identify and post exactly what bits of script changed/were added? It would make it easier for me to copy/paste into one of my test files. If not, I'll probably be able to track it down myself.

[JonnyFive]

OK, thanks. Hopefully I'll get a chance to check this when I get home.

Is it possible for you to identify and post exactly what bits of script changed/were added? It would make it easier for me to copy/paste into one of my test files. If not, I'll probably be able to track it down myself.

Here's the key bit:

Code: Select all • Expand view

   for (int i=0;i < Density;i++)
   {

      xSpawn=Random(xMin,xMax);
      ySpawn=Random(yMin,yMax);

      //START OF NEW CODE
      if (xSpawn <= xMax && xSpawn >= xMin && ySpawn <= yMax && ySpawn >= yMin) 
      {

         Spawn(WeatherType,(xSpawn*65536),(ySpawn*65536),(zSpawn*65536));

      }
      //END OF NEW CODE

   }

There are some other minor changes, but that's the big one that'll fix the bug. Did you make any other useful changes to the library file that I could use, or are you just sticking everything in a local script instead of using a library?

[JonnyFive]

As another performance note, with the spawn radius limit working properly, I get a pretty steady 80-90 FPS under ZDoom in the big test area (at 1024x768) and around 40-50 FPS using GZDoom at the same resolution. This is on my comp here at work that I co-opted for a stress test, which is not exactly a gaming rig.

[Enjay]

Thanks for the info. I noticed these entries seem to have changed too:

Code: Select all • Expand view

//Get default spawn x and y max/min from map spots
   xSpawnMin=GetActorX(UpperLeft)/65536;
   xSpawnMax=GetActorX(LowerRight)/65536;

   zSpawn=GetActorZ(UpperLeft)/65536;

   ySpawnMin=GetActorY(LowerRight)/65536;
   ySpawnMax=GetActorY(UpperLeft)/65536;

Previously they were:

Code: Select all • Expand view

//Get default spawn x and y max/min from map spots
   xSpawnMin=GetActorX(UpperLeft) >> 16;
   xSpawnMax=GetActorX(LowerRight) >> 16;

   zSpawn=GetActorZ(UpperLeft) >> 16;

   ySpawnMin=GetActorY(LowerRight) >> 16;
   ySpawnMax=GetActorY(UpperLeft) >> 16;

Is that one of the "minor changes"?

Anyway, yes, it is now much better. The rain does not spawn in that rectangular area in the void and the effects seem to have less of an impact on the fps too. I did still get a bit of spawning in the void, but this was in a complicated bit of map and the spawning was centred on the player rather than randomly appearing in a strange rectangle off to one side as before.

As for useful stuff... well primarily I am just loading it into a local script and pruning out the stuff that controls the player being able to switch off the effect as I don't need that for my testing. So, nothing much of use to you there.

However, one thing you may be interested in - the underwater check doesn't work. As I see it, you've used this:

Code: Select all • Expand view

RAIN A 175 A_JumpIf(waterlevel >= 1, "Death")
Stop

I think there may be 2 problems with this. I think a code pointer on the first frame of a spawn state does not get executed. Also, with the frame having a very long duration, it's not going to work. I'm pretty sure that pointers get executed at the start of a frame's duration. So, even if the pointer was being used, the particle will be spawning and executing the special immediately. Presumably at this time, the particle will be spawning above the water. By the time the particle hits the water, it has already checked whether it is below water or not and so does not disappear. It's not too obvious in your test map because of the blue underwater colour, but if you look closely, you can see raindrops under the water.

I suggest changing the code to something like this:

Code: Select all • Expand view

RAIN A 1 A_JumpIf(waterlevel >= 1, "Death")
Loop

or if you want to avoid a loop as you seem to want to, the much uglier option of

Code: Select all • Expand view

RAIN AAAAAAAAAAAAAAAAAAAAAAAAAA (etc...) 1 A_JumpIf(waterlevel >= 1, "Death")
Stop

could be considered.

[JonnyFive]

Is that one of the "minor changes"?

Yes, I just changed over from using the bit shift to using the old method of multiplying and dividing. It does the exact same thing, but I think it's more intuitive for most ZDoom modders to see exactly what is happening. Functionally it's identical.

I think there may be 2 problems with this. I think a code pointer on the first frame of a spawn state does not get executed. Also, with the frame having a very long duration, it's not going to work. I'm pretty sure that pointers get executed at the start of a frame's duration. So, even if the pointer was being used, the particle will be spawning and executing the special immediately. Presumably at this time, the particle will be spawning above the water. By the time the particle hits the water, it has already checked whether it is below water or not and so does not disappear. It's not too obvious in your test map because of the blue underwater colour, but if you look closely, you can see raindrops under the water.

I think I'll change it as you suggested. Since my main concern was particles spawning in the void, and that issue was corrected already, it shouldn't be a problem to have the loop.

EDIT: All righty, I uploaded a version with the objects set to run the check as you suggested and it works just fine. I haven't noticed any floating particles that are staying in the void or anything, so I'm not worried about killing them off after a certain time.

[DoomRater]

Code: Select all • Expand view

    RAIN AAAAAAAAAAAAAAAAAAAAAAAAAA (etc...) 1 A_JumpIf(waterlevel >= 1, "Death")
    Stop

DECORATE will not compile this, complaining that you can't have JumpIf statements on multiframe lines.

[JonnyFive]

Code: Select all • Expand view

    RAIN AAAAAAAAAAAAAAAAAAAAAAAAAA (etc...) 1 A_JumpIf(waterlevel >= 1, "Death")
    Stop

DECORATE will not compile this, complaining that you can't have JumpIf statements on multiframe lines.

I know this is kind of belated, but which version of ZDoom is this under and what specifically was the DECORATE line used? My bubble mod uses this kind of code to check to see if the bubbles have hit the surface and it works fine in GZDoom 1.1.04 and ZDoom 2.2.0, as well as the latest SVN builds.

[DoomRater]

I am suddenly wondering if the kind of jump has something to do with it... I noticed you are jumping to a state label and not a number of frames. My tests would never compile but yours does?