[fixed one]Static init and scroll problems

Bugs that have been resolved.

Moderator: Graf Zahl

User avatar
Enjay
Developer
Developer
Posts: 4753
Joined: Tue Aug 30, 2005 23:19
Location: Scotland

[fixed one]Static init and scroll problems

Post by Enjay »

I think these are known about, and may even be by design, but I thought they were worth mentioning over here because I think it was Graf who initiated at least one of the changes and the problems I have experienced are in a WAD that I cannot easily test with regular Zdoom.

Static init:
I'm not sure if this is by design, but it's screwed up some of my maps. I have a load of maps that I've been playing since way back when I used to make maps for Zdoom in Doom format. At some point, I ran them through zwadconv and line type 334 gets converted to 190 at that point. I had used 334 in quite a few places to give me coloured light - and these became 190 giving me coloured light instead.

However, now in GZdoom the sectors concerned give me coloured fog instead - which is not the desired effect and messes up maps that have had coloured lighting in them for 5 years or more!

IIRC, if you put the colour information on the upper texture of the static init line you should get coloured lighting and if you put it on the lower, I think you should get coloured fog. That's how it works in Zdoom 2.0.63a and 2.0.98 (I can test this feature easily enough) however, in GZDoom, I get coloured fog regardless of whether I put the colour information on the top or the bottom sidedef. So a feature of line type 190 seems to have been removed - it can no longer give me coloured lighting.

Scrolling:
In a DM map that I modified from one I found on the idgames archive (I have no idea what the original map was called), I have some sectors that are set to scroll and carry the player using line type 223 to do so (args are tag, 4, 1). The way these are set up in the level is a sort of double crossroads effect with 1 corridor heading towards and 1 corridor heading away from the central crossroads intersection from each of the 4 compass points. You step on the scrolling sectors and get carried along a corridor. When you get to the crossing point of the corridors, the central intersection sector cannot scroll because players could approach it from any one of 4 directions. So, the scrolling corridors have to give you enough momentum to fling you right across the central intersection and into the scrolling corridor beyond to take you out the other side of the scrolling crossroads feature. Flinging you across the central intersection has a secondary effect - there is a powerup in there and because you are flung across at some speed, unless you time it right, it's quite difficult to grab the powerup.

However, with GZdoom 0.9.16 the scrolling has changed so that a number of the desired effects no longer work as intended. Firstly, you seem to scroll quicker. This is hard to tell because the scrolling was always fast but you do seem to pick up speed instantly in a way that you didn't before. Or maybe your actual speed isn't faster but perhaps your acceleration is quicker. Anyway, that's not the real problem. The problem comes when you hit the central non scrolling intersection - you slow down far too quickly. It is now a very easy thing to stop or change direction or just grab the powerup in the central section.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany

Re: Static init and scroll problems

Post by Graf Zahl »

Enjay wrote: Scrolling:
In a DM map that I modified from one I found on the idgames archive (I have no idea what the original map was called), I have some sectors that are set to scroll and carry the player using line type 223 to do so (args are tag, 4, 1). The way these are set up in the level is a sort of double crossroads effect with 1 corridor heading towards and 1 corridor heading away from the central crossroads intersection from each of the 4 compass points. You step on the scrolling sectors and get carried along a corridor. When you get to the crossing point of the corridors, the central intersection sector cannot scroll because players could approach it from any one of 4 directions. So, the scrolling corridors have to give you enough momentum to fling you right across the central intersection and into the scrolling corridor beyond to take you out the other side of the scrolling crossroads feature. Flinging you across the central intersection has a secondary effect - there is a powerup in there and because you are flung across at some speed, unless you time it right, it's quite difficult to grab the powerup.

However, with GZdoom 0.9.16 the scrolling has changed so that a number of the desired effects no longer work as intended. Firstly, you seem to scroll quicker. This is hard to tell because the scrolling was always fast but you do seem to pick up speed instantly in a way that you didn't before. Or maybe your actual speed isn't faster but perhaps your acceleration is quicker. Anyway, that's not the real problem. The problem comes when you hit the central non scrolling intersection - you slow down far too quickly. It is now a very easy thing to stop or change direction or just grab the powerup in the central section.

That's the result of a scrolling bug fix in 2.0.97 so I won't change it.
User avatar
Enjay
Developer
Developer
Posts: 4753
Joined: Tue Aug 30, 2005 23:19
Location: Scotland

Post by Enjay »

Yeah, I thought both of these issues might be due to recent bug-fixes or intentional changes. So I wasn't sure if they'd be classed as bugs or not.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany

Post by Graf Zahl »

The first one is due to a screwed up bugfix (not the only one recently, btw.) Randy really should test the code he writes. I'm still trying to figure out what exactly is happening here. The effect is truly odd.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany

Post by Graf Zahl »

Fixed.

It was some bad interaction between Randy's buggy fix for Static_Init and my own color set routine which also has to handle Legacy's color format.

Return to “Closed Bugs”