[Jblade]

EDIT: quoting Dan's post since I knocked it off page:

Trooper Dan, on 18 April 2014 - 04:16 PM, said:

Sometimes the framerate drops to 0 but things keep happening in the game. For example, the player often ends up facing the opposite direction by the time the game unfreezes, because the game continues to accept input while frozen. For me, this is an issue when my mods use the CON save command (to save the game in the middle of gameplay), or when new textures are being loaded.

Is it possible to make the game pause while it is frozen? It's a source of player death and frustration.

On a related note, when using the command save the game saves and you load it back up again, it immediately saves again because it takes you to the very moment before the save command triggers. I can imagine a con workaround easily, but that doesn't seem like intended behaviour (correct me if I'm wrong though!) since that means you couldn't really use the command without a workaround as well. I just tested it myself now to make sure I wasn't going crazy and the game definitly re-saved when I loaded up the autosaved slot. This is the code I used, the actor is coded to be deleted straight afterwards so there's no way it's looping or anything like that:

Spoiler

useractor notenemy 9412
cstat 32768

ifvare AUTOSAVE_ENABLED YES
{
ifvarn HITAGSAVED 0
	{
	checkactivatormotion HITAGSAVED
	ifvare RETURN 1
		{
		userquote 243
		save 9
		killit
		}
	}
else
	ifpdistl 1024
	{
	userquote 243
	save 9
	killit
	}
}
enda

EDIT: also a small request...could we gain access to whatever moveflag the current 'move' the actor is set to? I can't see if it's possible on the wiki, if I could gain access to that than instead of having to code case specific stuff for every actor I can just check to see if an actor is moving with a new flag and then do whatever I need to do (in this instance, move towards a target other than the player)

[Micky C]

That resave from the save point bug also occurs in WGRealms 2 in case that's significant.

[Fox]

Helixhorned, on 18 April 2014 - 02:53 AM, said:

Can't reproduce. They behave the same as if they were given a corresponding "normal" fog pal number here. As usual, posting a screenshot comparing the two (all else being equal) with cl_showcoords 2 may point out the issue.

Okay, here is an example. Notice how the shadows are fullbright:



(I checked the source, and shadows have shade 127)

[Helixhorned]

Trooper Dan, on 18 April 2014 - 04:16 PM, said:

Is it possible to make the game pause while it is frozen? It's a source of player death and frustration.

Yup, see r4450. "Paused" is a slightly wrong term here, but that's just nitpicking.

James, on 19 April 2014 - 12:01 AM, said:

EDIT: also a small request...could we gain access to whatever moveflag the current 'move' the actor is set to?

Implemented in r4448. Actually, in the non-Lua build, the current movement flags are stored in a member that you can already access, but the new 'movflags' member is preferred as it will write you code that will also run properly in the Lunatic build: there, a new member actor[].movflags is used on the C side.

Fox, on 19 April 2014 - 01:57 PM, said:

Okay, here is an example.

Thanks! I missed it because I was running Mapster32 with r_usenewshading 2. Fixed in 4452.

[TerminX]

 James, on 19 April 2014 - 12:01 AM, said:

EDIT: quoting Dan's post since I knocked it off page:


On a related note, when using the command save the game saves and you load it back up again, it immediately saves again because it takes you to the very moment before the save command triggers. I can imagine a con workaround easily, but that doesn't seem like intended behaviour (correct me if I'm wrong though!) since that means you couldn't really use the command without a workaround as well. I just tested it myself now to make sure I wasn't going crazy and the game definitly re-saved when I loaded up the autosaved slot. This is the code I used, the actor is coded to be deleted straight afterwards so there's no way it's looping or anything like that:

Spoiler

useractor notenemy 9412
cstat 32768

ifvare AUTOSAVE_ENABLED YES
{
ifvarn HITAGSAVED 0
	{
	checkactivatormotion HITAGSAVED
	ifvare RETURN 1
		{
		userquote 243
		save 9
		killit
		}
	}
else
	ifpdistl 1024
	{
	userquote 243
	save 9
	killit
	}
}
enda

EDIT: also a small request...could we gain access to whatever moveflag the current 'move' the actor is set to? I can't see if it's possible on the wiki, if I could gain access to that than instead of having to code case specific stuff for every actor I can just check to see if an actor is moving with a new flag and then do whatever I need to do (in this instance, move towards a target other than the player)

Your problem there is one of logic, not EDuke32 errors. You're saving based on a condition you don't control yourself... of course the code is going to loop if you save this condition in your state. Change it so that checkactivatormotion sets a var that triggers the save (and only modifies that var when the condition you want is true) and then change that var back to 0 immediately after checking it but before actually executing the save command. Place your checkactivatormotion AFTER this point so that it is essentially flagging it to save on the next tic. You should no longer have a problem.

[Jblade]

Alright, I thought it could be fixed with CON stuff instead of hardcoding, I'll see what I can do. Cheers!

[Helixhorned]

 Mickey C, on 22 March 2014 - 07:39 PM, said:

In the classic renderer, textures on highly sloped surfaces at a distance become (...) fullbright.

Fixed in r4453.

[Micky C]

Incredible work! Thanks!

Although there's the slight drawback that all sloped ceilings everywhere are permanently fullbright Probably just a typo somewhere.

[Helixhorned]

 Mickey C, on 21 April 2014 - 09:50 PM, said:

Incredible work! Thanks!

Although there's the slight drawback that all sloped ceilings everywhere are permanently fullbright Probably just a typo somewhere.

Embarassing... it was more of a thinko. I did notice something, but it escaped my attention because that test map had gray fog instead of darkness visibilty. Fixed for real now .

[Helixhorned]

To pick up the issue of reproducing classic shading in the OpenGL modes: here are six screenshots of the air duct leading from the restroom of E1L1 taken with different renderes and/or settings. That scene makes quite a nice test case, having both shade and visibility darkening.




All in all, I think the situation can be summarized as follows.

- Polymer with ART mapping is the closest to classic (set 2, right).
- IMO, Polymost with r_usenewshading=3 and r_usetileshades=2 comes in second (set 2, middle). Currently, r_usetileshades=1 is the default, but
- Polymost with r_usetileshades=1 (set 2, left) clearly suffers from having too little black fog here.

This leaves the Polymost modes that don't use the lookup table for shading the textures, that is, r_usetileshades=0.
- With r_usenewshading=2, the scene is too dark overall.
- With r_usenewshading=3, the scene is too bright overall.

This post is purely observational and doesn't explain why some modes exhibit such undesirable differences to classic. I'll try to address the various factors in a later post and attempt to Fox's question posed a few pages ago, but for now I'd only like to hear whether you agree with what I said above. Also, for some reason the Poymost screenshots appear brighter than in-game to me. So, in case of disagreement, I'd like to ask you to check out these modes in the actual game/editor yourself.

[Plagman]

It's weird that ART mapping even exhibits such a visible difference; it should be identical except for the smooth transitions.

[Fox]

 Helixhorned, on 24 April 2014 - 01:18 PM, said:

- With r_usenewshading=2, the scene is too dark overall.

I seems fine for me, actually it's really good.

[Helixhorned]

 Plagman, on 24 April 2014 - 01:23 PM, said:

It's weird that ART mapping even exhibits such a visible difference; it should be identical except for the smooth transitions.

I think the major factor is the different notion of fragment depth/distance in both renderers: it's "ortho" in classic but the common Euclidean distance in Polymer. This is especially noticeable where wide open maps have visibility/fog: in Polymer, a lot less of the scene is visible then.

 Fox, on 24 April 2014 - 01:32 PM, said:

I seems fine for me, actually it's really good.

I suggest running the following experiment then. First, set gamma to 1.0 or F11-brightness to 0 in the editor, to exclude one potential source for differences. Next, using the same vent scene (or any other scene containing shaded regions), bump the visibility to infinity, again to exclude its effect. Would you now agree to the statement that as far as overall brightness is concerned, classic is in between the Polymost modes with r_usetileshades=0 (both) and r_usenewshading=2 on the one and r_usenewshading=3 on the other hand?

So what basically happens is with r_usenewshading=2 is that shading is too steep, but visibility is too flat (referring to the slope of the function "darkening factor vs. shade and distance, respectively"). That the overall scene with darkness visibilty appears to match classic rather well is due to these two offsetting each other -- in that particular scene!

[Fox]

I see. The average of the gray colors is indeed darker.

Spoiler

Attached File(s)

•  shadetable.zip (4.42K)
  Number of downloads: 349

[TerminX]

I've always admitted that my particular contributions to the lighting have been more or less complete bullshit... I plug in random things until I find something that feels right to me based on almost 2 decades of Duke3D. And then you make it accurate.

[Jenz/Amaka]

Is there a way to start the game with "r_pr_lighting 0"?

[Hendricks266]

autoexec.cfg

[MetHy]

In the version of mapster I'm using (says Mapster32 2.0.0devel r4128 Compiled Nov 2 2013 21:10:46), when manually editing sprites or sectors coordinates with F7 or F8 in 2Dmode, I can't set a "minus" coordinate because it won't register the minus key. I even tried remapping the minus key to another key but that didn't help.

I wanted to check if there was a newer version of mapster (perhaps the issue got fixed) but to be honest I can't even find it here http://dukeworld.duk...ke32/synthesis/

Help please! I'm doing ants work with small sectors, so manually editing sector Z coordinates in 2D mode would be very convenient.

[Fox]

There is an old bug with fogpal, which in Classic mode the pixels are never 100% the color of the fog.

I believe this is because the game stores 32 tables each fog, while the algorithm for shading assumes you have 32+1.

[MetHy]

 MetHy, on 29 April 2014 - 07:50 AM, said:

In the version of mapster I'm using (says Mapster32 2.0.0devel r4128 Compiled Nov 2 2013 21:10:46), when manually editing sprites or sectors coordinates with F7 or F8 in 2Dmode, I can't set a "minus" coordinate because it won't register the minus key. I even tried remapping the minus key to another key but that didn't help.

I wanted to check if there was a newer version of mapster (perhaps the issue got fixed) but to be honest I can't even find it here http://dukeworld.duk...ke32/synthesis/

Help please! I'm doing ants work with small sectors, so manually editing sector Z coordinates in 2D mode would be very convenient.

I Derped. You have to hit the number and THEN hit the minus key...

[Hendricks266]

 MetHy, on 29 April 2014 - 07:50 AM, said:

I wanted to check if there was a newer version of mapster (perhaps the issue got fixed) but to be honest I can't even find it here http://dukeworld.duk...ke32/synthesis/

Every binary package contains Mapster.

[Fox]

Is it possible to make windowx-y1-2 variables not read-only? It would be usefull to edit these values.

[Helixhorned]

 Fox, on 29 April 2014 - 08:07 AM, said:

There is an old bug with fogpal, which in Classic mode the pixels are never 100% the color of the fog.

I believe this is because the game stores 32 tables each fog, while the algorithm for shading assumes you have 32+1.

That's just a consequence of how the fogpal shade tables are constructed. For the last shade index 31, the entries shtab[31][i] (for color indices i) are color indices whose colors are close to the following linear blend: 1/32 * basePaletteColor[i] + 31/32 * fogColor. Thus, the last entry isn't completely the fog color by construction. That's not so noticeable for the colored fogs because those are a lot less represented in the base palette, and the nearest neighbors of all linear blends boil down to the same color. In contrast, grays are represented by a whole 32-entry ramp in the base palette.
Anyhow, see r4456 for a workaround.

 Fox, on 29 April 2014 - 11:17 AM, said:

Is it possible to make windowx-y1-2 variables not read-only? It would be usefull to edit these values.

No, not directly. Various other internal variables have values derived from these. What you really want is an interface to the engine function setview().

[Fox]

It's not so noticeable in other colors, but it is there. Can't you extend that to all colors?

[Helixhorned]

You're right, it's there. I was only testing the ugly brown brick texture and therefore hadn't noticed it. Committed to r4457 and feeling bad spamming synthesis with such mini-changes now.

[Fox]

There is quite a problem with .fogpal, because in Duke 3D the visibility of each texture also decreases with the shade. The result is a very unrealistic and unpleasing effect if the fog is not black.



The solution I can think of would require the fog being rendered in two steps, one which darkens the textures and a second one that adds the fog as if the texture shade is ≤ 0.

Speaking mathematically:

Spoiler

How it is:

• Shade 0: adds 10% of # fog
  
• Shade 10: adds 20% of # fog
  
• Shade 20: adds 30% of # fog

How it would be:

• Shade 0: adds 10% of # fog
  
• Shade 10: adds 9.09% of black fog and 10% of # fog
  
• Shade 20: adds 18.18% of black fog and 10% of # fog

[Helixhorned]

 Fox, on 30 April 2014 - 03:37 PM, said:

There is quite a problem with .fogpal, because in Duke 3D the visibility of each texture also decreases with the shade.

Are you referring to the fact that with Polymost and r_usetileshades 1, a texture's constant darkening is also a function of its sector's visibility? (Note that there's no such thing as "a texture's visibilty". It makes only sense to speak of the sector member 'visibility', or as the per-pixel attenuation with distance from the eye.) In fact, that's my major beef with TX's original "use tile shades" mode: it just doesn't make a lot of sense to take something that's varying per-pixel and apply that uniformly to a texture.

For this reason, I propose making r_usetileshades 2 the default, which uses lookup tables for the constant darkness attenuation (i.e. shade) and models fog/visibility as linear fading with distance with a particular color. TX, I understood your last comment to mean that you're fine going forward with that?

Fox: what are the renderer settings you're using in that screenshot? Setting r_showcoords to 2 will show some of the relevant ones.

[Fox]

That just sector .filler with r_usenewshading 3 (r_usetileshades doesn't matter).

Spoiler

 Helixhorned, on 01 May 2014 - 02:10 AM, said:

models fog/visibility as linear fading with distance with a particular color. TX, I understood your last comment to mean that you're fine going forward with that?

It would be kinda of weird for me if non-black fog behavior was different, especially because you can have a fog that is 99% black yet would be different.

[Helixhorned]

OK, I went ahead and made r_usetileshades 2 the default. I'm curious how the change will be percieved in real situations. As I noted in the commit log, the new default mode

Quote

does not take a sector's visibility values into account for uniform
darkening of a texture. It is more faithful to classic with respect to
fog/visibility *distances*, but may be less so as far as the "tint" of the
texture due to visibility attenuation is concerned.

 Fox, on 01 May 2014 - 10:40 AM, said:

 Helixhorned, on 01 May 2014 - 02:10 AM, said:

models fog/visibility as linear fading with distance with a particular color. TX, I understood your last comment to mean that you're fine going forward with that?

It would be kinda of weird for me if non-black fog behavior was different, especially because you can have a fog that is 99% black yet would be different.

I should have said "models fog/visibility exclusively as linear fading with distance with a particular color." Fading with distance (i.e. using glFog()) is what the OpenGL normally do in the absence of per-pixel shade table lookups (as currently only implemented with Polymer's r_pr_artmapping). What the original r_usetileshades 1 does is that it basically splits the darkening due to a sector's visibility and puts a part of that as uniform texture attenuation, and the "remaining" part goes into the actual fragment-depth-dependent fogging. As a consequence, with r_usetileshades 1 fog can sometimes cut off much farther compared to classic, as seen on the earlier E1L1 air duct screenshots. (It still cuts off slightly farther with r_usetileshades 2, but only by a small constant factor.)

Quote

That just sector .filler with r_usenewshading 3 (r_usetileshades doesn't matter).

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.

[Fox]

Worked REALLY good, especially because you can have linear black fog using a fogpal other than zero.

Edit: Since negative shade has no effect with .filler fog, wouldn't it also make sense to remove the glow colors (or glowmaps from highres textures) in the fog?