Duke4.net Forums: [RELEASE] Widescreen Fixes for Duke3D - Duke4.net Forums

Jump to content

  • 4 Pages +
  • 1
  • 2
  • 3
  • 4
  • You cannot start a new topic
  • You cannot reply to this topic

[RELEASE] Widescreen Fixes for Duke3D  "Version 1.6 now available"

User is offline   NightFright 

  • The Truth is in here

#61

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.
0

User is offline   NightFright 

  • The Truth is in here

#62

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

User is offline   NightFright 

  • The Truth is in here

#63

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!)

This post has been edited by NightFright: 26 November 2022 - 05:13 AM

0

User is offline   NightFright 

  • The Truth is in here

#64

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

This post has been edited by NightFright: 28 November 2022 - 03:58 AM

0

User is offline   NightFright 

  • The Truth is in here

#65

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

This post has been edited by NightFright: 06 December 2022 - 07:56 AM

0

User is offline   NightFright 

  • The Truth is in here

#66

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.

This post has been edited by NightFright: 12 December 2022 - 08:41 AM

0

User is offline   Phredreeke 

#67

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)

  • Attached Image: 3281_vaca-wideinpaint.png
  • Attached Image: 3281_vaca-wideinpaint2.png
  • Attached Image: 3240_vaca-wideinpaint.png
  • Attached Image: 3240_vaca-wideinpaint2.png

1

User is offline   NightFright 

  • The Truth is in here

#68

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.

This post has been edited by NightFright: 12 December 2022 - 01:47 PM

0

User is offline   Reaper_Man 

  • Once and Future King

#69

View PostPhredreeke, 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.
0

User is offline   Phredreeke 

#70

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
Attached Image: 00000-2036834167-Beach pixelart.png

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

Attached Image: 00008-3854923645-Beach resort landscape pixel art.png

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

Edit: extended the edge further

Attached Image: 00014-3854923645-Beach resort landscape pixel art.png

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

Attached Image: 00071-3854923645-pixel art.png

This post has been edited by Phredreeke: 12 December 2022 - 05:51 PM

1

User is offline   Phredreeke 

#71

Tried to help it a little along the way
Attached Image: cropped-inpaint.png

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.
0

User is offline   NightFright 

  • The Truth is in here

#72

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.

This post has been edited by NightFright: 14 December 2022 - 02:02 PM

0

User is offline   Phredreeke 

#73

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)

  • Attached Image: 00009-2312201364-Terminals at space station pixel art.png
  • Attached Image: 00003-2534068113-Terminals at space station pixel art.png
  • Attached Image: 00216-2312201364-Inside spaceship pixel art.png

0

User is offline   NightFright 

  • The Truth is in here

#74

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.
0

User is offline   NightFright 

  • The Truth is in here

#75

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.

This post has been edited by NightFright: 08 January 2023 - 11:18 AM

0

User is offline   Phredreeke 

#76

Yeah, GDX expects CRCs to be written in decimal
0

User is offline   NightFright 

  • The Truth is in here

#77

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.

This post has been edited by NightFright: 08 January 2023 - 02:41 PM

0

User is offline   Phredreeke 

#78

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
0

User is offline   NightFright 

  • The Truth is in here

#79

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.

This post has been edited by NightFright: 09 January 2023 - 12:27 AM

0

User is offline   Phredreeke 

#80

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
0

User is offline   NightFright 

  • The Truth is in here

#81

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.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #82

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.
1

User is offline   NightFright 

  • The Truth is in here

#83

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.

This post has been edited by NightFright: 30 May 2023 - 11:10 PM

0

User is offline   Phredreeke 

#84

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

User is offline   NightFright 

  • The Truth is in here

#85

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

#86

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.
0

User is offline   Phredreeke 

#87

View PostDecember 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" }} 

1

#88

View PostPhredreeke, 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)

  • Attached Image: 2493.png
  • Attached Image: caribbeanbg.png

0

User is offline   Phredreeke 

#89

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.
1

#90

View PostPhredreeke, 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!
1

Share this topic:


  • 4 Pages +
  • 1
  • 2
  • 3
  • 4
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options