[Hendricks266]

NightFright, on 27 September 2025 - 01:31 AM, said:

texture 2462 { pal 0 { file "highres/screen/hud/2462_statusbar_wide.png" orig_sizex 428 orig_sizey 34 artquality } }

This will do for now. But you should remove the artquality token. It is for pixel art, not true color textures, and has nothing to do with widescreen.

[NightFright]

Will do. I already noticed it doesn't do anything. I also found orig_sizex 428 is really the minimum value for width. Two pixels less and the green background tile becomes visible, at least for the statusbar.

As of now, the only unresolved issue is with the level ending screens and the animated Duke frames not aligning properly. Reducing orig_sizex to 426 for the widescreen backgrounds results in an improvement, but the barrels and spilled ooze still move a bit on the right frame edges.

I am also trying to resize the frames to match the background, but it won't change much. The game is stretching the images automatically, it seems.

[Phredreeke]

My advice would be to downscale the ending frames with Duke animation to standard resolution first, and get those displaying right with xoffsets. Once you've done that, it should be easy to get the full resolution images loaded in place.

[NightFright]

So far nothing I tried worked. It appears the highres background is cut precisely at the same spots as its lowres counterpart and the frames are inserted at the exact same spot, too. It's about what happens on the right side. My suspicion is it has to do with the way the highres image is stretched when using orig_sizex.

Two ways to try still, as far as I see:

1) So far I've used 1920x1080 as target resolution, but it may be the wrong approach. Since an original size of 428x200 is defined, in this specific case it might be better to only go for multitudes of that - 1712x800 (4x res), possibly? (Fact: The old HD graphics are 1024x768 and alignments are perfect with those.)

2) Reduce original resolution to 320x180 (orig_sizey 180), which is 16:9, and keep the HD replacement at 1920x1080.

[Phredreeke]

Keep the vertical size 200 as that is what the game expects. Don't attempt to "correct" the aspect ratio of the base tile, it doesn't use 1:1 pixel ratio. 428x200 is the correct resolution for 16:9. The tile should look slightly squished, as when displayed it's stretched 20% vertically.

[NightFright]

Ultimately, I guess the jittering is a side effect users may have to live with. The patches appear exactly where they should, but the background either stretches too much or too little.

[Phredreeke]

If you upload just the end of level assets I can have a look at it. Maybe the tiles that are overlaid needs some padding.

[Phredreeke]

It wasn't not the overlaid tiles that needed padding, it was the tile beneath (3240 and 3245)

The reason? a 428x200 tile (once stretched 20% vertically) doesn't actually have an exact 16:9 aspect ratio, it's just slightly wider. Nothing you would notice by itself, but once you start adding other tiles on top of it, it becomes noticeable.

By padding tiles 3240 and 3245 to 1926 pixels wide instead of 1920, it has the same ratio as the tile it replaces, and tiles 3241-3244 and 3246-3249 will align correctly.

I'm attaching the padded version of 3240 as an example. It was saved with Paint.net so you probably want to use PNGOUT to get better compression

Attached thumbnail(s)

• 

[NightFright]

I realized menu tiles can also be 426x200 instead of 428x200. It only matters for the statusbar, for whatever reason. With 426p width you would still have minimal borders on each side.

[DNS]

NightFright, on 05 October 2025 - 09:45 AM, said:

I realized menu tiles can also be 426x200 instead of 428x200. It only matters for the statusbar, for whatever reason. With 426p width you would still have minimal borders on each side.

So did you give up on this again?

It wasn't long ago that you were having issues with the HUD yet managed to figure it out after coming back to it. I believe you could complete this with a continued effort.

[NightFright]

Still planned, but hard to tell for when. I have very little free time available these days, just like pretty much anybody else. The remaining issue is to get widescreen expansions for the level ending screens. AI delivers shit results and so far I wasn't able to find anybody who was able to provide the necessary graphics.

[Phredreeke]

Did you not get the tweaked versions I sent you? (I checked and the download link is dead, I can't send them right now as I'm not at home)

[NightFright]

No idea what happened to those, I took a longer break. In my last test version (tiles dated Oct 5), the city screens look kinda OK (not perfect), but the space ones definitely show seams (where the added parts begin) during the animation and are unusable in their current form. Note that there are two variants of those screens out there, one with Parkar's older Duke model and one with the later version. The Parkar edit is used for Polymost AFAIK, to match with the model used there. In the worst case, we only focus on one version and drop the other.

[Phredreeke]

yeah those are not the ones I cleaned up for you. fortunately I had one saved in a DM on discord. I'll be reuploading the space one tomorrow

Attached thumbnail(s)

• 

[NightFright]

Actually that new city screen edit works worse than the one I already have. Brightness is definitely a factor here.

[Phredreeke]

I see, I'm gonna need to edit the 3241-3244 tiles so the rightmost edge matches the extended background

[NightFright]

Just in case you need it: Here's a temporary upload (active for 7d) of 3241-3244 and 3246-3249.

[Phredreeke]

Already had those saved. Anyway, here are the tweaked 3240 and 3245 + edits of 3241-3244 and 3246-3249.

Attached File(s)

•  hrp-levelend-ws.zip (5.28MB)
  Number of downloads: 34

[NightFright]

Excellent! These finally seem to do the trick. Can't see any transitions/seams now whatsoever. Thanks a bunch!

I will now resume internal playtesting of all widescreen-related additions.

[NightFright]

It is done. And with that, the HRP goes out with a bang, at least. Happy Holidays, everyone!

[LeonV]

NightFright, on 24 December 2025 - 06:06 AM, said:

It is done. And with that, the HRP goes out with a bang, at least. Happy Holidays, everyone!

What a treat, thanks for making this available! I have only followed this project from a distance over the many years since it started, but it is a huge achievement that you and the many other contributors, past and present, can justifiably be proud of.

[0815Jack]

Hi,

I had some time to play with the new HRP and I noticed that all Assualt Troppers & Captains have now a blue body armour, instead of green and red. I did a fresh installation to confirm its not related to other things. Can anyone confirm?



and in the log it reads
5.0459s INFO| High Resolution Pack v5.5.750
5.0482s INFO| Selected Edition: Polymer

and I was using Polymost. The problem might be:

// if polymost then
// include duke3d_hrp_polymost.def
// else
include duke3d_hrp_polymer.def
// endif

So the HRP is meant to be played with Polymer?

And someone might fix the rubbercans in the first level sticking halfway in the wall

[FRVIND]

Thank you.
I think there are still a lot of fans of the HRP version, but they're "silent" and many aren't aware of the efforts made by some brave people... if only there were more publicity, then there would be many more downloads and recognition.

[ck3D]

0815Jack, on 26 December 2025 - 03:02 AM, said:

Hi,

I had some time to play with the new HRP and I noticed that all Assualt Troppers & Captains have now a blue body armour, instead of green and red. I did a fresh installation to confirm its not related to other things. Can anyone confirm?

I don't use the HRP but it is not too surprising this is happening, there is the reason that the only base trooper sprite vest in the game technically is blue, and then the sprites recolored (pal swapped) to green at runtime for Troopers; in the case of Captains, it is the mapper who manually pal swaps them, but the end result is still the same: a sprite pal swap. In short, the default blue trooper that exists never appears without the HRP because the sprite version gets autocorrected to green if not given a custom pal, and Assault Captain intrinsically takes custom pal 21 which is bright red, so the coloring you are (rightfully) used to normally relies on sprite palette swaps. Again I have no experience with the HRP or models but from what I've seen on video, models do not seem to be as flexible as sprites with palettes, so that probably at least begins to answer your question. (I expect others will be quick to rectify or be knowledgable about this than me.)

[NightFright]

Will look into it later. Polymost worked fine for me when I checked, though. You must invoke the corresponding def file (duke3d_hrp_polymost.def) manually, as before. That thing with the if condition in the def files never worked IIRC. It was an idea which was never realized, unless I missed something.

Troopers should still change colors since they have skins for the different palettes, at least that's how it used to work. Admittedly my tests primarily focused on the new widescreen tiles since barely anything else changed. If it did, it's not excluded it's due to changes in EDuke32 which I'm not aware of, which is absolutely possible. Maybe this could have been avoided with a tester team, but as it stands now, we can be glad to have one person around to do it, even if only superficially.

In general it should be kept in mind that Polymer is clearly the preferred renderer for the HRP. You'll be missing out a lot of its advanced effects otherwise. Polymost should be rather seen as a fallback if your PC can't handle the other renderer. Nevertheless, support's still in. Therefore it should work, ofc.

[0815Jack]

Ok, I have tested with Polymer activated and the troopers now have the corrrect color. Also some maphacks fixed themself except for that rubber can in E1L1

[NightFright]

It's possible Polymost and Polymer hacks are not on the same level, even though they should. However, sometimes different models with different orientations are used. Which sucks, but unfortunately nobody ever bothered to make them all face in the same direction.

It's pretty insane to check all of that. Would have to make two complete playthroughs with both renderers, and we're not talking about speedruns, but thorough, level-by-level inspections of all sprites, also in all secret areas. The days I could single-handedly pull off such a thing are long gone, sadly. Maybe LeoD can take a look one of these days. Still, models stuck in walls may not look pretty, but are not such a big deal. You'll see plenty of those when using the HRP with mods (which IMO you shouldn't), anyway.

[DNS]

Glad to see this done and right on time as previously stated.

Great job.