[Forge]

Then why remove tools that used to be openly available to mappers and modders?

[Gambini]

That is not an option. Even if i could compile my own version with the commands re-enabled, it would have to distribute a non official branch of the port solely for that purpose.

It is already difficult enough to make people understand they should play the released version of our mod using the build we provided back then, go figure making people use a standalone version of the port, just because this.

[Fox]

Gambini, you based the results on an unfinished renderer. The purpose has always been to have Polymost and Polymer look more like classic mode.

 Gambini, on 23 March 2018 - 01:03 PM, said:

Visibility has changed drastically and console commands like r_usetileshades, r_shadescale, r_usenewshading don´t do anything when entered on the console.

Does it works if you turn off palette emulation (Options -> Display Setup -> Polymost Setup)? A shader has been on work for GL, so some of the older features may not work in the most recent build.

 Gambini, on 23 March 2018 - 01:03 PM, said:

And this is how it looks now on 6788, almost like before but now with a parallax glitch (notice the vertical strips of misalligned sky above the buildings on the distance)

The sectors with parallaxed ceilings use different pannings. Recently we fixed the panning in Polymost mode.

Type this in Mapster console to fix the panning of all skies:

do gamevar i 0 0
do for i allsectors { ifand sector[i].ceilingstat 1 { set sector[i].ceilingxpanning 0 set sector[i].ceilingypanning 0 ifand sector[i].floorstat 1 { set sector[i].floorxpanning 0 set sector[i].floorypanning 0 } }

It would also be possible to do so via CON, if you are interested.

 Gambini, on 23 March 2018 - 01:03 PM, said:

This is what both autoexec.cfg and m32_autoexec.cfg read, at least the r_usetileshades command seems to work on the autoexec for Eduke32:

r_shadescale 0.65
r_usenewshading 2
r_novoxmips 1
r_usetileshades 2

While you could fix the shading via Mapster script / CON, it may cause issues with secotor effectors and such. So I recommend a custom shade table with 48 shades to get a result similar to 0.65.

[Hendricks266]

 Gambini, on 24 March 2018 - 07:58 AM, said:

There´s no lesson here because at the time i built the largest part of those maps, those parameters were of free use. Also, when you design a map for polymost, you can´t map on classic because many things dont work like models, skyboxes, etc.

Can you confirm r_usenewshading, r_usetileshades and r_shadescale commands are locked on the console? Is there a way I can ship a mod which overrides the default values?

I said nothing about them being locked. I said you are wrong to use them. They are for users, not for mod authors.

[Danukem]

 Fox, on 24 March 2018 - 10:56 AM, said:

Gambini, you based the results on an unfinished renderer. The purpose has always been to have Polymost and Polymer look more like classic mode.

You have been very helpful, and I will try to work with you and Gambini on implementing the suggestions in your post. However, I wish that you guys (meaning the developers) would show more respect to mappers like Gambini and think about your choice of words. Polymost has been the renderer of choice for most players and mappers for over a dozen years now. Simply saying it's an "unfinished renderer" and that maps shouldn't be calibrated to it will come as a surprise to most people, but more importantly it doesn't acknowledge the tremendous amount of work that has gone into making content for it over the years. I'm not suggesting that what you say is factually incorrect, by the way, but I am saying that this comment you make here and various other comments by Hendricks266 from time to time come off as dismissive and needlessly disrespectful.

 Fox, on 24 March 2018 - 10:56 AM, said:

Does it works if you turn off palette emulation (Options -> Display Setup -> Polymost Setup)? A shader has been on work for GL, so some of the older features may not work in the most recent build.

Will check

 Fox, on 24 March 2018 - 10:56 AM, said:

Type this in Mapster console to fix the panning of all skies:

do gamevar i 0 0
do for i allsectors { ifand sector[i].ceilingstat 1 { set sector[i].ceilingxpanning 0 set sector[i].ceilingypanning 0 ifand sector[i].floorstat 1 { set sector[i].floorxpanning 0 set sector[i].floorypanning 0 } }

Will do.

 Fox, on 24 March 2018 - 10:56 AM, said:

I recommend a custom shade table with 48 shades to get a result similar to 0.65.

Sounds good, but I don't know how to do that and I don't think Gambini does either

[Fox]

Does this TC uses the same base palette?

[Danukem]

 Fox, on 24 March 2018 - 12:23 PM, said:

Does this TC uses the same base palette?

Yes, it uses the standard Duke 3D palette.

[Gambini]

nope, we use Lezing´s Extclut palette.

Will look at those things later, now i am on a rush.

[Fox]

I meant the base palette, not the lookups.

[Gambini]

Not sure what you mean, I only added the ExtClut thing.

BTW the palette emulation thing is locked on polymost setup, but i have no idea what it does.

[Danukem]

 Gambini, on 24 March 2018 - 03:06 PM, said:

BTW the palette emulation thing is locked on polymost setup, but i have no idea what it does.

That seems to be a menu bug, but there is a workaround. Go back to display options and change filter mode from classic to filtered. Now you can go back into polymost settings and you can turn palette emulation off. Then you can go back out and put filter back to classic, but palette emulation will stay off.

[Micky C]

 Gambini, on 24 March 2018 - 03:06 PM, said:

Not sure what you mean, I only added the ExtClut thing.

BTW the palette emulation thing is locked on polymost setup, but i have no idea what it does.

ExtClut extends the palette options, but keeps the base palette the same.


Palette emulation attempts to make the colours in polymost closer to classic, by generating a new, individual texture for each shade variation of an art tile, and using that instead of simply making it darker by adding blackness, as has been done traditionally. Of course, polymost still adds blackness for visibility in the distance, so everything has to be very finely balanced for it to look close to classic. Although, by the sounds of things they're going to implement something like polymer's artmapping shader, which accounts for both shade and visibility in a classic-style through direct use of the lookup tables, potentially with some interpolation.

[Gambini]

Quote

That seems to be a menu bug, but there is a workaround. Go back to display options and change filter mode from classic to filtered. Now you can go back into polymost settings and you can turn palette emulation off. Then you can go back out and put filter back to classic, but palette emulation will stay off.

That seems to do the trick. And also proved that only the r_usetileshades 2 is the command I need.

However, It is still a problem. If I had to release the mod today players would have to deal with that workaround, which is something nobody would bother to.

What is palette emulation BTW? Is there a way to disable it through the console?

[Danukem]

 Micky C, on 24 March 2018 - 04:41 PM, said:

Palette emulation attempts to make the colours in polymost closer to classic, by generating a new, individual texture for each shade variation of an art tile

That sounds like it would use a ton of resources in a project that adds thousands of new art tiles, such as AMT TC and lots of others.

[Gambini]

 Micky C, on 24 March 2018 - 04:41 PM, said:

Palette emulation attempts to make the colours in polymost closer to classic, by generating a new, individual texture for each shade variation of an art tile, and using that instead of simply making it darker by adding blackness, as has been done traditionally. Of course, polymost still adds blackness for visibility in the distance, so everything has to be very finely balanced for it to look close to classic. Although, by the sounds of things they're going to implement something like polymer's artmapping shader, which accounts for both shade and visibility in a classic-style through direct use of the lookup tables, potentially with some interpolation.

That is what r_usetileshades do. TerminX implemented it kindof at my request in 2013 after DNF 2013 was released. Is it the same thing but with a fancy name?

There were two modes for it, and at the time i was inclined to use r_usetileshades 2 because it had a more accurate look to what i was needing. I think it would be good to have the two options, or at least a way to force the one I am using.

[Gambini]

 Trooper Dan, on 24 March 2018 - 04:46 PM, said:

That sounds like it would use a ton of resources in a project that adds thousands of new art tiles, such as AMT TC and lots of others.

I have been using it since it exists and never had performance issues, even when i always keep an eye on the fps counter. 8bit tiles are usually 128x128, with all 24 shade tables for each, it´s still as big as a single material of 627x627, much smaller than most hrp textures for example.

[Micky C]

 Gambini, on 24 March 2018 - 04:49 PM, said:

That is what r_usetileshades do. TerminX implemented it kindof at my request in 2013 after DNF 2013 was released. Is it the same thing but with a fancy name?

I'm pretty sure that's what it is. They needed a fairly simple non-technical yet descriptive name for the wider gaming community. I wouldn't be surprised if it went through some iteration since 2013, as the original implementation was quite crude.

 Trooper Dan, on 24 March 2018 - 04:46 PM, said:

That sounds like it would use a ton of resources in a project that adds thousands of new art tiles, such as AMT TC and lots of others.

I assume it'd do some kind of check and only apply the process to a subset of the textures, i.e the ones actually being used. I recall TX saying that it'd have similar performance to something like the HRP.

I haven't noticed any unusually poor performance in the AMC TC in polymost, although I use classic 99% of the time, which doesn't use the emulation.

[Danukem]

 Micky C, on 24 March 2018 - 05:05 PM, said:

I assume it'd do some kind of check and only apply the process to a subset of the textures, i.e the ones actually being used. I recall TX saying that it'd have similar performance to something like the HRP.

I haven't noticed any unusually poor performance in the AMC TC in polymost, although I use classic 99% of the time, which doesn't use the emulation.

I'll just have to keep an eye on performance when that setting is used, since in my current project I'm using all the sebabdukeboss20 characters, often with most of the different characters in a map at the same time, and they comprise thousands of tiles at about 64x128 pixels per frame. I have noticed some hitches lately.

[Hendricks266]

Palette Emulation being in the menu at all is a concession to the performance cost it had. It being locked reflects situations in which the performance concerns are solved. "On" is the correct setting. When this becomes all situations, the menu option will go away and it will again only be a cvar.

It would be a shame if a project so centered in history would say "I don't care" about actually looking accurate to the history it is imagining. I promise it won't be hard to fix your maps. Scripting is the answer here. Hopefully someone can spare the time to help. For example, a script that can apply shading modifiers to a selected group of sectors.

shade.m32:

gamevar i 0 0
gamevar j 0 0

defstate shadedown
  // handle RAlt selections
  for i selsectors
  {
    sub sector[i].floorshade 1
    sub sector[i].ceilingshade 1
    for j spritesofsector i
    {
      sub sprite[j].shade 1
    }
    for j wallsofsector i
    {
      sub wall[j].shade 1
    }
  }

  // handle RShift selections
  for j selsprites
  {
    sub sprite[j].shade 1
  }
  for j selwalls
  {
    sub wall[j].shade 1
  }
ends

console:

include shade

(select things)

do state shadedown

Repeat.

[Gambini]

The problem is the balance between shading and visibility is a math that requires an adjustment per case. You know shading affects visibility and vice-versa so finding an equation which restores the looks of distant bright constructions and at the same time dark closer ones is probably something only the engine knows.

I will be insolent and ask: What is the problem of allowing users access those commands? Come to think of it: nobody will fuck up with them, it´s improbable and your action would save us hours of work, which would be fair to spare, since we always been on the rules when building this. Polymost has been on development for 14 years, claiming we should not have relied on an unfinished renderer is not a valid point.

[Danukem]

 Fox, on 24 March 2018 - 10:56 AM, said:

I recommend a custom shade table with 48 shades to get a result similar to 0.65.

Sent you a PM asking for help on this, and yes as we said DNF 2013 uses the same base palette. Your expertise would be much appreciated.

A scripting solution could be made to work, but I'm pretty sure it will take trial and error, using different scripts on different groups of sectors and still fine tuning the result in many cases...it will probably take quite a few hours to get it perfect on all the maps, which are quite large and complex.

[Fox]

 Gambini, on 24 March 2018 - 07:08 PM, said:

The problem is the balance between shading and visibility is a math that requires an adjustment per case. You know shading affects visibility and vice-versa so finding an equation which restores the looks of distant bright constructions and at the same time dark closer ones is probably something only the engine knows.

I will be insolent and ask: What is the problem of allowing users access those commands? Come to think of it: nobody will fuck up with them, it´s improbable and your action would save us hours of work, which would be fair to spare, since we always been on the rules when building this. Polymost has been on development for 14 years, claiming we should not have relied on an unfinished renderer is not a valid point.

"Palette Emulation" is r_usetileshades. The option is acting weird because of WIP code of the shader.

The console commands were never intended to serve as tools for modders, but an interface for the user. Meaning that console commands may be changed, removed, etc with no concern for backwards compatibility.

Polymost was in development for a long time, but it was still not working as intended. The purpose has always been to look like classic. It would be equivalent of using a poorly adjusted computer.


Anyway, here is a solution. Add this to the defs:

globalflags 1
shadefactor 47

Then adjust the visibility in USER.CON to your liking:

define DEFAULTVISIBILITY        512

[Danukem]

 Fox, on 25 March 2018 - 01:21 AM, said:

Then adjust the visibility in USER.CON to your liking:

define DEFAULTVISIBILITY        512

Here's the thing I don't get, though. Even if the def commands plus changing DEFAULTVISIBILITY gets the correct result in game, how will that help in mapster? Mapster doesn't use settings in USER.CON

The mapper needs to see what the levels will look like in-game while mapping.

[Gambini]

Hello.

I haven't been following new features progress closely but i'm tempted to ask, because I know these have been subject of discussion in the past times, so they may be already available:

Are model skyboxes featured already? If so, what i have to do to get one of myself working?

Exists a way to use fog without changing the sector´s palette?

When will palette emulation apply on models and voxels?

Thanks for the response.

@Hendrics266: The sound problem I reported is fixed. If you are interested on reading what was it: it seems that (at least on my end) If sound SFX volume goes below 53% it wont work at all, and will abruptly begin to work when turned up to the next notch.

[Fox]

 Gambini, on 30 March 2018 - 07:31 PM, said:

Exists a way to use fog without changing the sector´s palette?

Yes, it's a structure called "fogpal".

[Danukem]

 Fox, on 30 March 2018 - 11:47 PM, said:

Yes, it's a structure called "fogpal".

http://wiki.eduke32.com/wiki/Fogpal

Note for Gambini:
So it would require an effect sprite similar to an SE that specifies what the fogpal is for that particular sector. For example, you could set pal 0 to cause white fog instead of the default black fog -- then you just set visibility to determine how strong the fog is.

The code would not be complicated and I could add this pretty easily. All it has to do is read values off the effect sprite at map load time and apply them to the fogpal struct. EDIT: At least that's my understanding of how it would work -- the wiki link for the sector struct actually goes to the entry for the def command...

[Striker]

Palette Emulation possibly being forced in the future is troublesome for me. I'm using a combination of true-color and stock Duke3D textures in StrikerDM for various things in maps, and the palette emulation would cause a serious clash in appearance between the two, so I recommend to play the mod with it off. (Which is why I've considered asking for a DEF token to force pal emulation off. Unless there's one that exists that I'm unaware of.)

I would prefer if the option was still there. If anything, if the shading with palette emulation off is incorrect, something should be done about it. (Ie. The shade/differences in brightness should be as if what software would pull off if it were 32-bit, rather than 8-bit paletted. In short, using the same formula but without palette restriction.)

[Fox]

globalflags 1 will force palette emulation off.

 Trooper Dan, on 30 March 2018 - 11:58 PM, said:

http://wiki.eduke32.com/wiki/Fogpal

Note for Gambini:
So it would require an effect sprite similar to an SE that specifies what the fogpal is for that particular sector. For example, you could set pal 0 to cause white fog instead of the default black fog -- then you just set visibility to determine how strong the fog is.

The code would not be complicated and I could add this pretty easily. All it has to do is read values off the effect sprite at map load time and apply them to the fogpal struct. EDIT: At least that's my understanding of how it would work -- the wiki link for the sector struct actually goes to the entry for the def command...

You can change the fogpal in the maps. I don't know if there's a command, but setting the fogpal in the console works.

[Striker]

 Fox, on 31 March 2018 - 08:59 AM, said:

globalflags 1 will force palette emulation off.

Ah, undocumented feature. I should check the source code and add some documentation on the wiki.

[Gambini]

I want to make emphasis in these two questions I asked. I'm looking forward to know the answer.

 Gambini, on 30 March 2018 - 07:31 PM, said:

Are model skyboxes featured already? If so, what i have to do to get one of myself working?

When will palette emulation apply on models and voxels?