[Fox]

Is he not talking about a mod or something?

[Jblade]

I'm talking about the default Duke sky texture used in E4L1, the one that automatically shifts and moves in the sky. It becomes misaligned for reasons I'm not entirely sure of.

[Fox]

The x-ypanning changes. It should be easy to do with CON, and may be even possible with some Sector Effectors. Naturally it doesn't work (and probably never will) in OpenGL.

[Jblade]

....no no you don't understand what I'm talking about. 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?

http://dukerepositor...e_For_Christmas

It does it towards the end of this map, the skys are aligned properly in Build but ingame they become misaligned at the town at the end.

[Hendricks266]

Public Service Announcements

---

If you use the alpha member of sprites, ensure that you always constrain the value that you use to [0, 255]. (For those unfamiliar with math, this notation stands for an inclusive interval.)

Likewise, apply the same constraint to alpha parameter of rotatespritea and screentext, unless you are using a negative value to stand in for a blend parameter, in which case constrain it to [-255, -1].

Currently, unconstrained values are equivalent to zero, but this will change imminently when upper bits of alpha, both member and parameter, are overloaded to configure OpenGL blending modes.

---

If you use the CON commands getmusicposition or setmusicposition, first of all, you shouldn't be using them (unless you're Fox), because we have not documented them on the wiki, and the commit message that introduced them clearly stated:

Quote

Consult the devs before using these commands.

There is a high likelihood that these commands will change in the near future, breaking any scripts and savegames that use them. Consider yourselves warned.

[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.