[Jan Satcitananda]

Plagman, on Jan 18 2011, 09:10 AM, said:

Since any memory concerns are now totally out of the equation, I think than more than ever base pals need to be collapsed with the highpalookups instead of being separate. The cost of two additional texture lookups + scale/bias for each fragment far outweighs an additional 6MB of highpals in the HRP.

Perhaps it will serve now. The highpalookups can be easily superposed with each other during the game load, can't they? The game just converts 24 images (22 lookups and 2 base pals) into 68 different color tables to work with single-stage filtering. Nevertheless, we may want to keep two-stage processing as an additional option for modders to increase overall capabilities.

DanM, on Jan 18 2011, 10:00 AM, said:

sorta but some actual commits by Craigfatman on the sourceforge page, perhaps pursue and improve a certain area of eduke like how helix bitch slaps mapster around, I know anyone can do it, its just a shame with his oodles of knowledge he hasnt started coding for the core of eduke yet, because you know he would do something crazy that breaks all the rules

I had encountered some problems when trying to work with its source code, but it's a good idea to do some fixes there. At the moment, I can't even compile a working game executable from SVN sources, despite having both Vorbis libraries and DirectX SDK properly installed (I got "LINK : fatal error LNK1181: cannot open input file 'msvcrt_winxp.obj'"). The EDukeWiki contains notes for VS2008, but I already have VS2010. Also, I've never contributed to open-source projects. Should I simply go to http://sourceforge.n...ojects/eduke32/ and ask for a developer status?

[Plagman]

I don't think we want to put even more strain on the loading process by adding some code to preprocess high palookups with high basepals. It adds no value to do it that way, it just increases loading times and puts more code in something that's already too bloated. Having more files around isn't a problem and even allows for more flexibility, maybe a modder will want a particular intersection of a given base pal and lookup to be totally different than the combination of the two for his own purposes.

As for the the sourceforge project page, that's not needed; just send any patches directly to TerminX if they touch the game code or me if they touch the engine code (or Helix if they touch the editor, since he maintains that these days). Also good to discuss any overhaul or new feature project with the appropriate party in advance instead of dumping a big patch without warning, collaborative design and review is an important part of these kinds of projects.

[Jan Satcitananda]

As I said before, combining loaded highpalookups should be faster than loading everything from disk. But considering flexibility, it would be more constraining; and it's not hard to make a script which precalculates everything as separate highpalookups. So, do you now need 64x64x64 versions of all palettes?

[Plagman]

Yep, that'd be great. I'm overhauling how base palettes work between game and engine to let people name basepals per ID in DEFs so that this will work properly.

Thanks a lot!

[Jan Satcitananda]

Ur welcome... At last, a new set of 68 highpalookups is rendered at 6-bit precision. Uploaded instead of old one here: http://lzg.duke4.net/hipals6b.rar

I've improved my script with a secondary map processor which performs trilinear interpolation to provide best quality. I used the water and NVG highpalookups as secondary maps to combine them with the look-up palettes. Also there's a procedure that automatically removes colors that get changed by a selected palette too much compared to their original luminance, so palette #23 should look much better now. Hovewer, that hack should not be used with pal #6, what can be set up by modifying the getpalcs() procedure (just nullify the 'd' variable).
The script archive has been updated as well: http://lzg.duke4.net/clutstat.zip

Press U to use the loaded tile as a secondary map (it can be any highpalookup of the same sampling rate saved previously), then hit I to turn it on/off.
The file with original lookups now contains water and NVG palettes as pals #128 and #129 respectively. Also, a corrupt 239th color was fixed (I had changed it when I was developing ExtCLUT to prevent the color from being confused with its duplicate with index number 143).

[Danukem]

Is it now possible to specify basepals in DEF? Otherwise I don't see how we can use the new water and NVG highpalookups that Craig uploaded.

[Plagman]

You're right that it's not possible at the moment.

[Danukem]

CraigFatman, on Jan 22 2011, 05:28 AM, said:

Ur welcome... At last, a new set of 68 highpalookups is rendered at 6-bit precision. Uploaded instead of old one here: http://lzg.duke4.net/hipals6b.rar

I get this type of error when trying to use those:

Error: image dimensions of 'hipal_images\pal_01.tga' must be 16384x128.

[Plagman]

Yes, because the code looks for 7 bits worth of data right now, not 6. I have to make a code change and add the scale/bias for 6:6:6 maps before these are usable.

[Plagman]

OK, using revision 1783 of EDuke32 in conjunction with revision 185 of the HRP should yield working base palettes now. Preview:






Big thanks to Lezing for the pack.

The next issue is something Helixhorned brought up about performing the highpal lookup after applying the shade color, apparently causing problems with some palettes. I still need to make this happen on my end.

[Tea Monster]

To Craig, Plagman and all of you guys who worked on this, that looks SOOOOOOOOOOOOOOO much better!

Thank you very much.

[Danukem]

Plagman, on Jan 27 2011, 12:04 AM, said:

OK, using revision 1783 of EDuke32 in conjunction with revision 185 of the HRP should yield working base palettes now.

What is the DEF syntax for that? This link no longer works for me, so I don't know where I would go to look at the source: http://eduke32.svn.sourceforge.net/

[LeoD]

http://dukeworld.duk...ke32/synthesis/
[Well, I guess you are looking for online browsing...]

[Plagman]

SourceForce must be having some issues. In any case, an example of the DEF syntax would be in the HRP revision I mentioned earlier:

http://svn.eduke32.com/filedetails.php?rep...def&rev=185

[Hendricks266]

I request that manual palswaps be removed with caution due to Polymost. They should eventually be eliminated once Polymer runs smoothly and compatibly.

[Danukem]

Hendricks266, on Jan 27 2011, 03:14 PM, said:

I request that manual palswaps be removed with caution due to Polymost. They should eventually be eliminated once Polymer runs smoothly and compatibly.

Are you talking about the pal versions of skins and models in the HRP? If so, then they would only be removed from the Polymer version of the HRP, which should not cause any problems with Polymost.

[Hendricks266]

I was under the impression that the HRPs would not be separated. If both are going to be based out of the same SVN, with a program to separate the textures, and sort out the defs, then a number of old Polymost tiles need to be readded from previous revisions, because they were overwritten. But that's off topic.

[Danukem]

Hendricks266, on Jan 27 2011, 07:56 PM, said:

I was under the impression that the HRPs would not be separated. If both are going to be based out of the same SVN, with a program to separate the textures, and sort out the defs, then a number of old Polymost tiles need to be readded from previous revisions, because they were overwritten. But that's off topic.

And here was my impression:

Polymost HRP = the last official HRP before Polymer stuff got added
No longer being developed. It has whatever alt-pal textures and skins the HRP had at that time.

Polymer HRP = the latest version that has the Polymer stuff
This is what gets updated in SVN


Are there any active HRP developers who are interested in working on the Polymost HRP?

[Hank]

definitely off-topic sorry

[Tea Monster]

Hendricks266, on Jan 27 2011, 08:56 PM, said:

I was under the impression that the HRPs would not be separated. If both are going to be based out of the same SVN, with a program to separate the textures, and sort out the defs, then a number of old Polymost tiles need to be readded from previous revisions, because they were overwritten. But that's off topic.

They can't co-exist. The Polymost tiles will use shading tricks baked into the texture that will look odd in Polymer, which has a different lighting system. They have to be separate.

@ DT - There is a chance now to re-make a lot of the stuff with Polymost and actually bake the the lights into the texture. We only did it marginally before as we were waiting for a vertex lighting solution that never came about. If you step up this effect you could make the models approximate some of the extreme lighting that was on the sprites - something that would make all those HRP havers more happy . Check out this model by NiuHaka as an example of what sort of look you can achieve. Check out the texture sheet and compare it to the models in the HRP.

You could also set it up a lot more stringently so that you get a lot more quality control than we had the first time round. Now that most of the stuff is 'done' you can be more choosey about what sort of look you want to go for and how you want to handle lighting approximation and all that other stuff. Hopefully, the next generation of the HRP will look a lot more unified. I think a lot of this stuff should be worked out and possibly even written up in a 'policy document' of some sort before you go back and start re-making stuff.

You may even want to create a separate thread for discussion of the P-HRP as otherwise there could be confusion and problems.

[Hendricks266]

Tea Monster, on Jan 28 2011, 11:49 AM, said:

They can't co-exist. The Polymost tiles will use shading tricks baked into the texture that will look odd in Polymer, which has a different lighting system. They have to be separate.

I know this full well, but it seems impractical to have two separate SVNs. Discontinuing the "Polymost HRP" seems to be an ok idea.

[Micky C]

I think I died and went to heaven.


The problem is that the NV goggles are now useless for what they were originally intended for

Edit: just to be clear it looks like the aliens are no longer fullbright when the NVG are on.

[Roma Loom]

Works fine for me, the monsters glow like hell in the dark with NV.

[Fox]

There is no reason why the monsters wouldn't glow.

It's not their <pal> structure member that makes them glow, but their <shade> value.

[Hendricks266]

Monsters are displayed with pal 6 when NVG is on, so they should show up brightly.

[Micky C]

They show up the right colour but as you can see in the pic I posted, it's pitch black except for the glowmaps of the eyes. That pic was taken is the small secret area behind the projection room in e1l1 Hollywood Holocaust.

Anyway the real reason I was posting is because I was wondering if the highpalookup feature could be extended to get a new shading system similar to that in the original renderer? Like how the colours change to darker variants as you get further away from what you're looking at. If this is possible it would help create a much smoother transition between light and dark as opposed to the rather abrupt change in the openGL modes.

[Plagman]

Now that highpal affects rotatesprite, I think the last point that needs work is the point that helix raised. The problem is the following: for classic pal 2 for example, the transition to red becomes much more saturated for darker colors. My solution to replicate this with highpal was to perform the highpal lookup _after_ the "shade offset", which is faked in GL mode by just multiplying the color with more black as needed.

For example for an E1L5 scene that relies a lot on pal 2 with various shades, here's what classic looks like:

https://lh3.googleusercontent.com/_aC29RB4F...24/duke0019.jpg

Here's highpal with the lookup performed before the shade offset:

https://lh5.googleusercontent.com/_aC29RB4F...24/duke0024.jpg

Here's highpal with the lookup performed after the shade offset:

https://lh4.googleusercontent.com/_aC29RB4F...hY/duke0026.jpg

As you can see the latter looks much closer to classic, as darker shades are much redder. HOWEVER, it doesn't work as well with other stuff. Case in point, tile 251, pal 23. Classic mode:

https://lh5.googleusercontent.com/_aC29RB4F...24/duke0048.jpg

Highpal, lookup before:

https://lh3.googleusercontent.com/_aC29RB4F...24/duke0049.jpg

Highpal, lookup after:

https://lh4.googleusercontent.com/_aC29RB4F...24/duke0047.jpg

Note how the parts that shouldn't be affected by the pal get all yellow-ish in that case. If we look at classic for pal 0 (and compare it with classic with pal 23), we see that these parts are left 100% untouched:

https://lh3.googleusercontent.com/_aC29RB4F...24/duke0050.jpg

So it seems there's a tradeoff here. One could argue that the highpal map itself should address that by not letting these not-too-blue colors go to yellow like that, or that the HRP tile itself is too blue in these other parts. Any opinions would be much appreciated!

[Hendricks266]

Ideally, the highpals should replicate the effects of the palswaps on the original 8-bit art 1:1. Pragmatically, that would take reworking of an unknown amount of HRP art.

Perhaps someone should make a map with M32script that allows examining of the lookups on every tile/texture in the game.

[Helixhorned]

Hendricks266, on Feb 28 2011, 06:05 PM, said:

Perhaps someone should make a map with M32script that allows examining of the lookups on every tile/texture in the game.

That would require access to tile data from m32script in the first place, which isn't there ATM.

Plagman: would a solution where each pal has an option that effectively says in which order to apply shading and highpal be too expensive?

[Jan Satcitananda]

The thing with pal #23 where the yellow abruptly fades into dark greenish is caused by color deficiency, not the look-up palette itself (yellows exist only for midtones and highlights in Duke3D palette). I don't think that we should replicate this way of shading; it doesn't look good and would be too difficult to simulate using highpals. Take note that the classic mode uses look-up tables for both palswaps and shades, but making all shades as highpals would be impractical.