[NightFright]

Version 1.43 has been released after I realized I didn't use the proper file name for the fixed Skycar from World Tour in the definitions.

[NightFright]

Version 1.44 has been released with two typo fixes for the NW finale panel (3293), inspired by Hendricks266's fix from NW+.

[NightFright]

Version 1.45 has been released. Just realized I never added a widescreen version for NW's level ending screen. About time that changed!

(Notice the slight focus on NW these days? Well, 'tis the season!)

[NightFright]

Version 1.46 has been released. Significant improvements for NW tiles #3245 (level ending) and #3293 (episode ending)!

[NightFright]

Version 1.47 has been released.
Added a missing DM kills bar (#2465) and further refined the NW episode ending screen (#3293).

[NightFright]

Version 1.5 has been released.
This release gets rid of all stretched images to achieve widescreen aspect ratios. In some cases (especially Vacation), I had to place border images to cover the gaps, but it still looks way better than simply stretching the graphics and making them look completely distorted.

[Phredreeke]

Alright, I took the Vaca end of level screens and ran them through an outpainting AI. No further editing has been done but it's a starting point I guess. The images with 2 tagged at the end uses a more primitive model but it appears to cope with the image better (although still not great)

I'll see if I can do any more trickery, the outpainting AI isn't really made for pixel art

Attached thumbnail(s)

• 
• 
• 
• 

[NightFright]

Amazing what AI can do these days. Always needs a lot of additional work, especially at the seams, though. It's also about 3292 and 3293 of the original game, btw (image parts only). 3293 (ep.2 ending panel) is less urgent since both sides of the image are already pretty dark, so the transition to the black bars seems less abrupt.

For Nuclear Winter episode ending panel I managed to make a pretty good non-stretched version since the background is easy (black sky) and the cut-off tree on the left could easily be completed with the original tile from the NW art files.

[Reaper_Man]

 Phredreeke, on 12 December 2022 - 12:20 PM, said:

I'll see if I can do any more trickery, the outpainting AI isn't really made for pixel art

Something that may be worth trying is AI upscaling the entire image to something like 4k resolution, then doing the AI outpainting, then finally downsample them back to the target resolution.

[Phredreeke]

That's actually what I considered doing but the result wasn't really better than what I was already getting. I attempted a slightly different approach (take the outpainted area as a base, then inpaint those, the advantage here is that I can )

First one I attempted to take a padded version of the original frame, make a mask which used for inpainting. The advantage here is that I can supply a description of what I want. The result was... interesting


I then went back to the outpainted image and used that instead (since it has a decent idea of what I want at a coarse level) and inpainted over that. This also gives me the advantage of controlling for strength. After some different tries I got this



I'll keep experimenting and report back later with more results

Edit: extended the edge further



Edit 2: enough messing around for tonight. someone graffiti'd the mountainside

[Phredreeke]

Tried to help it a little along the way


BTW, how feasible is using scripting to generate the episode end screens based on the current screen aspect ratio? Take the inner image and scale it to the width of the screen (assuming the screen aspect ratio is less than the aspect ratio of the image, otherwise windowbox it) and then place the text (possibly with some kind of fade-in) at an appropriate position based on the screen aspect ratio.

If this is not possible, IMO revert those images to the originals, because if viewed on a narrower screen the text will actually get cut off, unlike with the title screen and level ending screens, where what is cropped off is just our additions.

[NightFright]

I was also thinking about that. In fact, the center part of the images should always remain unchanged. Tiles 3292 and 3293 currently (still) violate that rule with the text exceeding the borders. I had already undone part of it recently by reverting the images to 4:3 ratio.

All things considered, it should only be the images getting expanded, not the text. So as it stands now, I should indeed not use these panels at all. Adding text dynamically is something EDuke32 might be able to do, but this is also supposed to work in other ports like Rednukem, BuildGDX or Raze, so we better stick to using images only.

We'll keep in mind that the ep.2 and ep.3 ending panels also need AI widescaling. That or leave it to Nash. What he did for Doom and Heretic is just mind-blowing.

[Phredreeke]

Honestly what I'd prefer would be if someone loaded the original image into a 3D program, then took the assets used in it (possibly using the upscales from the ERP) and positioned them to match the image. Then the edges of the image could be filled in similarly.

The AI managed to fill in the beach loading screen relatively well. It did not handle the ep 1 ending as nicely. The ep 2 ending came out decent though. I'm attaching a few attempts on both ending screens. (two of them are mirrored because they came out better when processed that way)

Attached thumbnail(s)

• 
• 
• 

[NightFright]

That ep.2 panel turned out nicely, indeed. Guess it was easier to do since it's pretty dark on both edges, so you have to worry less about smooth transitions. The one for ep.1 also isn't bad for a first draft.

On Github I have uploaded some placeholders for now which are the original images with black side borders plus a few minor text fixes (needless commas removed etc). They'll be in the next release, available one we get the Vacation screens done. Maybe I can even wait until 3292/3293 are done, too.

[NightFright]

Can anyone with DukeGDX experience explain what might lead to def-related issues as reported in this Github ticket?

https://github.com/N...idefix/issues/6

Is it because ifcrc is not supported or maybe the hex values I am using? The error message in the log is very vague, unfortunately.

[Phredreeke]

Yeah, GDX expects CRCs to be written in decimal

[NightFright]

Holy crap. And this is only revealed now? Well, I guess that tells how many of the folks out there are actually using DukeGDX.

In that case, I guess the easiest solution is to use decimals in general, right? All ports should be able to handle those. (Is there actually any advantage when converting to hex, besides having a few characters less, maybe? Guess not.) Oh, and if the decimals are negative, you don't have to do some weird conversion crap, do you? It's just the value as-is, IIRC.

[Phredreeke]

Well in the case of DukeGDX that's understandable as

1. Widescreen sprites are already included with the port
2. There's already a skybox pack for it on M210's website

[NightFright]

Well, the widescreen stuff provided by DukeGDX isn't as comprehensive as in this mod. But well, turns out the "artquality" parameter also isn't supported, which I am using in the skybox definitions. I really love when features are only partially supported/implemented.

*EDIT*
Turns out DukeGDX does not support widescreen tiles for menu graphics. Considering that this is the main difference between the widescreen gfx that come with the port any my mod, the main reason to use this in DukeGDX is gone. I will therefore just remove DukeGDX support for the time being, I guess, as sad as it is.

[Phredreeke]

Just use nocompress nodownscale, it does the same thing. Although I don't think they're needed for GDX as it doesn't compress textures anyway

[NightFright]

Could someone help verify whether the lower part of the Freezethrower (2548/2550) or rather its upper parts (2551-2553) are aligned incorrectly in this mod?

Referring to this Github ticket:
https://github.com/N...idefix/issues/7

I've checked and there's indeed a mismatch which apparently hasn't been noticed for quite a while, if ever.

[Hendricks266]

This misalignment is present in the original game, and any defs I created such as for Megaton or my old .zip package are strictly accurate.

[NightFright]

Wow. Are there ports which fix this somehow, like Raze, or how did the Github guy notice it?
But anyway: I guess that means it doesn't really matter which part of the sprite you realign since it's hard to tell which of them is supposed to be shifted. I'd rather go for the top, though.

[Phredreeke]

Has anyone tried to get the widescreen expanded AI renders up to a quality good enough for inclusion in the pack?

[NightFright]

You mean the episode ending screens and the like? Haven't read any news about those so far.

[December Man]

Hey, is it possible to use a high quality/resolution PNG as a title screen? When I try to use "texture" in defs it cuts it like usual. With "tileastexture" the PNG is shown incorrectly, i.e. zoomed in with low color fidelity.

[Phredreeke]

 December Man, on 25 January 2024 - 12:54 PM, said:

Hey, is it possible to use a high quality/resolution PNG as a title screen? When I try to use "texture" in defs it cuts it like usual. With "tileastexture" the PNG is shown incorrectly, i.e. zoomed in with low color fidelity.

Yes. you have to do both if the new texture is a different aspect ratio.

Example from the ERP

// Widescreen title screen by Phredreeke with additions by Tea Monster
tilefromtexture 2493 { file "lr/tile2493.png" }

// tiles using non-default palettes defined using true color tiles
texture 2492 {  pal 0 { file "hightile/tile2492.png" }} 
texture 2493 {  pal 0 { file "hightile/tile2493.png" }} 

[December Man]

 Phredreeke, on 25 January 2024 - 02:09 PM, said:

Yes. you have to do both if the new texture is a different aspect ratio.

Example from the ERP

// Widescreen title screen by Phredreeke with additions by Tea Monster
tilefromtexture 2493 { file "lr/tile2493.png" }

// tiles using non-default palettes defined using true color tiles
texture 2492 {  pal 0 { file "hightile/tile2492.png" }} 
texture 2493 {  pal 0 { file "hightile/tile2493.png" }} 

Does the pic have to have specific height and width? Because I've been checking these two and they appear either stretched (when using NightFright's widescreen 2493) or squeezed (when using original title pic).

Attached thumbnail(s)

• 
• 

[Phredreeke]

the first pic (using tilefromtexture) should be 200 pixels tall, and with a 1:1.2 pixel aspect ratio. For convenience, here are some aspect ratios and the resp. size you need

4:3	320x200
16:10	384x200
16:9	426x200
21:9	560x200

The pic doesn't actually need to contain anything but will be displayed if EDuke32 is run with the software renderer. It needs to be remapped from the title screen palette to the Duke3D in-game palette. (this is why the ERP doesn't use indexed hightile for those two tiles)

the second pic (using texture) could be any size and aspect ratio. This is the pic you actually want defined.

[December Man]

 Phredreeke, on 26 January 2024 - 11:03 AM, said:

the first pic (using tilefromtexture) should be 200 pixels tall, and with a 1:1.2 pixel aspect ratio. For convenience, here are some aspect ratios and the resp. size you need

4:3	320x200
16:10	384x200
16:9	426x200
21:9	560x200

The pic doesn't actually need to contain anything but will be displayed if EDuke32 is run with the software renderer. It needs to be remapped from the title screen palette to the Duke3D in-game palette. (this is why the ERP doesn't use indexed hightile for those two tiles)

the second pic (using texture) could be any size and aspect ratio. This is the pic you actually want defined.

Ah, now it works! Thank you!