[0815Jack]

Hi,

I like the use the upscale pack as standalone pack, so I extracted the dukeupscale.zip and duke3d.def from the erp zip (duke-erp-210701.zip). Zipped the duke3d.def to x_all.zip and put both files in the autoload folder. It works but with some noticeable flaws...




I noticed by coincidence this issue. Also visible in the stripper room in E1L2. Does anyone what's going on and how to fix it?

[Danukem]

0815Jack, on 16 February 2025 - 01:22 PM, said:

Hi,

I like the use the upscale pack as standalone pack, so I extracted the dukeupscale.zip and duke3d.def from the erp zip

I'm not gonna play "guess what the bug is from studying my screenshot" but I'd like to point out that the upscale pack already existed as its own separate mod before it was combined into the ERP:

https://www.moddb.co...upscale-pack-13

[NightFright]

Highres textures sort of need their own tiles for different palettes. (Correct me if I'm wrong here, I'm recalling decade-old knowledge from the HRP.) That means if textures use a palette deviating from the default (e.g. red instead of blue), you would have to physically provide these variants, including definitions. If you don't, you end up only seeing default palettes.

The solution is simple: Manually create color variants for all highres sprites and textures which also use non-default palettes. Quite a sophisticated task, plus it would bloat the size of the upscale pack considerably.

[0815Jack]

@danukem: yes I know that pack, but I think the ERP one does contain more replaced textures or I'm a wrong?

@NightFright: Shouldn't the ERP pack work out of the box? I did not make any modifaction to it, just removed the parts that are outdated or non-upscale related. Could it be that something in the engine was changed..


Does anyone have the same issue?

[Phredreeke]

0815Jack, on 16 February 2025 - 01:22 PM, said:

Hi,

I like the use the upscale pack as standalone pack, so I extracted the dukeupscale.zip and duke3d.def from the erp zip (duke-erp-210701.zip). Zipped the duke3d.def to x_all.zip and put both files in the autoload folder. It works but with some noticeable flaws...

duke0000.jpg
duke0001.jpg

I noticed by coincidence this issue. Also visible in the stripper room in E1L2. Does anyone what's going on and how to fix it?

Are you using Polymer?

[0815Jack]

Phredreeke, on 17 February 2025 - 10:08 AM, said:

Are you using Polymer?

no

[Phredreeke]

Ok. What version of EDuke32 are you using? Have you set any particular CVARs? (for example r_useindexedcolortextures 0 will break the upscale due to the same shader being used to recolor tiles)
Does the ERP work as intended with the included exe and folders? (To rule out any possible driver bug being the culprit)

[0815Jack]

Phredreeke, on 17 February 2025 - 04:16 PM, said:

Ok. What version of EDuke32 are you using? Have you set any particular CVARs? (for example r_useindexedcolortextures 0 will break the upscale due to the same shader being used to recolor tiles)
Does the ERP work as intended with the included exe and folders? (To rule out any possible driver bug being the culprit)

I'm using lastest version from http://dukeworld.duk...ke32/synthesis/ and I've done the setup like discribed in my first post.

Yes the orginal ERP package works..

[Phredreeke]

Ok. I figured it out after looking closer at your screenshots. You have texture filtering turned on

[0815Jack]

Phredreeke, on 18 February 2025 - 05:46 PM, said:

Ok. I figured it out after looking closer at your screenshots. You have texture filtering turned on

Yes I switched back to "nearest" and it looks normal again .... can you explain why filtering doesn't work with the upscale pack? Only certain areas seemed to be affected... I assume only ones with colored sector lights. I really like to understand ... thx in advance

[Phredreeke]

First, a short explanation on how colors on Duke3D and most DOS FPS worked. Unlike a modern computer game, where the framebuffer is stored with separate red green and blue channels, the framebuffer instead contained indices into a 256 color palette. This allows some neat tricks such as tinting the entire screen by just updating those 256 entries, rather than 64 000 or more pixels. Another trick is shading. Instead of doing 3 multiplies (very expensive on the CPUs at the time, and forget about SIMD) for each pixel, you use a lookup table. Lookup tables could also be used for blending different colors (for semitransparency effects) or having different color variants of an enemy such as the liztroop.

Now fast forward twenty or so years, hardware rendering is now the norm and multiplies are cheap. But the result doesn't look the same. The solution is to store the texture in the original 256 color palette, then do the lookup in a shader as it's drawn, just like original game did on the CPU. Works great until you turn on texture filtering then it falls apart.

Why does it work when you're not using upscaled graphics? Well, EDuke32 does the lookup in advance on the CPU for the different palette variations (this was a necessity for older versions of Polymost, which were written for old fixed function hardware)