[Fox]

It appears that SE 4 (random lights) is flickering too much compared to the DOS game.

[Daedolon]

There are also some bugs regarding it, where some walls, with no explanation, would not take the shade as pointed.

[Jblade]

Just saw that Helixhorned made a commit about the cloudy sky texture...so there was a limit to how many sectors it could be used in before errors occur? That's a pretty interesting bit of info really, it explains why the misalignment seemed to occur randomly. Thanks for the fix!

[Helixhorned]

Jblade, on 14 April 2015 - 11:04 AM, said:

The default sky tile 79 moves by default in Duke. Look at E4L1. What I'm saying is that it bugs out in usermaps and displays all fucked up at times and becomes misaligned. Is there a latent cause for this or is it just one of those 'shit happens' things?

There's an arbitrary limit of 256, formerly 128, CLOUDYSKIES parallaxed ceilings that get their x/yrepeat changed with time and according to the player viewing angle.

[Jblade]

Interesting, I assume for performance reasons back when they added it in (it makes perfect sense in retrospect now) This should fix the skies in the majority of usermaps using that sky so cheers for doing this.

[Helixhorned]

Jblade, on 18 April 2015 - 02:31 PM, said:

Interesting, I assume for performance reasons back when they added it in (it makes perfect sense in retrospect now) This should fix the skies in the majority of usermaps using that sky so cheers for doing this.

Nah, probably they just made a rough guess about the limit. On each scene display, all CLOUDYSKY sectors are updated [*], so runtime only depends on how much are actually used. Glad to make EDuke32 the ultimate usermap playing port a bit more .

[*] This is actually pretty dubious. Map structures should be updated in game state code only.

[Hendricks266]

Helixhorned, on 18 April 2015 - 02:44 PM, said:

[*] This is actually pretty dubious. Map structures should be updated in game state code only.

Interesting you should mention that, considering some the discussions Fox, TX, and I have been having about the Duke 64 mod. Don't CYCLER sprites do something similarly dubious with sector shading?

[Helixhorned]

Hendricks266, on 18 April 2015 - 03:16 PM, said:

Interesting you should mention that, considering some the discussions Fox, TX, and I have been having about the Duke 64 mod. Don't CYCLER sprites do something similarly dubious with sector shading?

Yes, but that's from G_DoMoveThings() -> A_MoveCyclers(), i.e. game state update code and thus perfectly fine. I'm complaining about the fact that CLOUDYSKIES ceiling x/ypanning is changed from display code (G_DisplayRest() -> G_MoveClouds()), which is questionable. After all, game state should at least conceptually evolve in lockstep on each peer. When it instead depends on something local (such as the time when a redraw is made), you may get inconsistencies when you examine that value from game code and do something based on it.

Edit: strictly speaking, this applies to the old netcode.

[Helixhorned]

Fox, on 16 April 2015 - 11:31 PM, said:

It appears that SE 4 (random lights) is flickering too much compared to the DOS game.

There was an issue with a maintanance rewrite of some related code, so it should be back to Duke3D behavior now, but a piece of information I found in passing is that the maximum shade of all walls in the SE sector is backed up and subsequently used. So, if you experience flickering to very dark shades, check the SE sector's walls. Also,

r5155 said:

Incidental info: the blinking of NEON* sprites can be controlled via their
lotag, similarly to how you how you give a "random flash number" as SE4 hitag.

[Fox]

Isn't it a bit weird that the .anm videos are not stretched to full width? I believe all of the animated ones are past the 16:9 aspect. The same goes for episode 1 cutscene. It looks a bit off to have black bars in both directions.

[Daedolon]

The black bars are in the actual ANM files though, so they should be played as they're made. Unless someone goes in and adds a check for the ANM files to see if there's any black bars to crop.

[Hendricks266]

Fox, on 20 April 2015 - 12:32 AM, said:

Isn't it a bit weird that the .anm videos are not stretched to full width? I believe all of the animated ones are past the 16:9 aspect. The same goes for episode 1 cutscene. It looks a bit off to have black bars in both directions.

We're planning to do this in HTTKC via def.

[Fox]

Daedolon, on 20 April 2015 - 12:35 AM, said:

The black bars are in the actual ANM files though, so they should be played as they're made. Unless someone goes in and adds a check for the ANM files to see if there's any black bars to crop.

I guess that makes sense. It could be hard-coded to stretch to full width, which would be less invasive than the code to fit HUD elements on the screen. But the problem would be TCs that use .anm files, including Sunstorm Interactive expansion packs.

[Fox]

In regards of CON mutators, this is not working for blast damage:

onevent EVENT_PREGAME
  ifactor APLAYER
    setactor[THISACTOR].htextra -1
endevent

[Hendricks266]

Now remember kids, if you don't have the talent to make something yourself, you can always claim you made someone else's work.

[Tea Monster]

As a great man once said "Rip 'em a new one".

[DavoX]

Guy deleted it, good.

[Fox]

Helixhorned, on 01 May 2014 - 02:26 PM, said:

Ah, I see. It only now dawned to me what you meant. Yes, an object's shade also determines the fog parameters, and with linear fog, in particular the far cutoff distance. This is simply due to the OpenGL modes modeling fog after classic, and is easily seen in the central palookup equation (or the inversion thereof). In r4460, I made an object's shade not contribute to fog parameters if that fog comes indeed from a sector[].fogpal -- the fog calculation is done as if the shade were 0. I'm kind of happy with this special case for 'fogpal' because it differentiates it from setting the same pal as .floorpal on the sector.

I came to realize what is the perfect method to overcome the problem with the shade contributing to the fog parameter: applying the standard black fog with the shade parameter, and on top of it the colored fog using screen blend mode.

From left to right: fullbright, normal, 50% shaded, 100% shaded.

Normal fog with shade parameters


Colored fog without shade parameters (current .fogpal)


Normal fog with shade parameters + colored fog with screen blend mode

[Mark]

Good stuff. I seem to make a lot of dark maps which makes using fog out of the question.

[Hendricks266]

Fox, on 04 May 2015 - 03:33 AM, said:

I came to realize what is the perfect method to overcome the problem with the shade contributing to the fog parameter: applying the standard black fog with the shade parameter, and on top of it the colored fog using screen blend mode.

Where exactly are you proposing to use this?

[Fox]

I just felt it's a feature that has not been perfected.

[Hendricks266]

Fox, on 04 May 2015 - 12:36 PM, said:

I just felt it's a feature that has not been perfected.

But I mean, where? What specific aspect of what feature? Applying the fogpal member in 8-bit?

[Fox]

It was suggested to replace the current .fogpal behavior, which only works on Polymer/Polymost.

[NightFright]

Can anyone confirm automap lines not being drawn in Polymer at all with r5001 and newer? I wanted to bundle the new HRP with latest snapshot, but if it's a common issue, I guess it'd better get fixed first.

[LeoD]

 NightFright, on 06 May 2015 - 01:40 PM, said:

Can anyone confirm automap lines not being drawn in Polymer at all with r5001 and newer?

Has been reported elsewhere, but I couldn't reproduce it yet on several machines/OS'es. Maybe it's configuration related. Try a clean install with EXE and GRP only.

 NightFright, on 06 May 2015 - 01:40 PM, said:

I wanted to bundle the new HRP with latest snapshot, but if it's a common issue, I guess it'd better get fixed first.

Indeed, otherwise I see no EXE candidate to be included.

[NightFright]

Well, I tried with a clean folder with only duke.rts, duke.grp and eduke32.exe inside. Nothing else, no config files, no folders. Can't get any cleaner than that. Still doesn't work with Polymer. Maybe it depends on specific hardware.

My system here is like this:
Win 7 x64 SP1
Intel Core i5 750 @2.67 GHz
4 GB RAM
nvidia GeForce 9500 GT (Forceware 341.44)

If it doesn't look right for me, I have to assume it's like that for others, too. The last snapshot where that problem didn't occur dates back to February, and quite some features would get lost if I include that with the HRP bundle. As you know, HRP only truly shines with Polymer, so there shouldn't be things like that in a public release.

[Fox]

The automap is also broken for me in Polymer. I also noticed it's being rendered below the status bar (except for the texturing).

[Fox]

[Mark]

Please explain to us common people what message are you trying to convey with those pics.

[Micky C]

Is the mirror thing a polymer effect or did you use TROR and have some code to mirror the sprites?