[NightFright]

Someone asked on Github whether this can work with JFDuke3D. Is that even possible? I see there's a build from 2021 available (http://www.jonof.id.au/jfduke3d), but I have no idea about its technical capabilites. TBH I am surprised this even still exists and there are people actually using it.

Stuff I'm not sure JFDuke3D supports:
- Widescreen gfx in general
- tilefromtexture with xoff/yoff and ifcrc to selectively replace tiles from addons
- globalgameflags 1 (disables widescreen orientation bits for weapon sprites)
- tiles97-99.art to provide 1.3D redfont

[Phredreeke]

If you want vanilla accuracy, you use Rednukem. If you want fancy modding features you use EDuke32. I don't know where that leaves JFDuke3D other than being the granddaddy of Duke source ports.

Anyway, I downloaded JFDuke3D and the widescreen fix. First I created an autoload folder that I put the zip file in. Resulting in nothing. Then I extracted the zip file to the same folder as jfduke3d, again nothing.

[NightFright]

My expectation is that there's probably no way to make this work. I think not even tilefromtexture is supported.

In general, I'm wondering why anybody would willingly choose a clearly inferior, outdated port these days when there's at least four viable alternatives out there. I mean, JFDuke3D was the pioneer port which made the HRP possible and laid the foundation for EDuke32, but since many years, actually decades, it's little more than a historical artifact.

[Phredreeke]

NightFright, on 09 February 2024 - 02:47 PM, said:

I mean, JFDuke3D was the pioneer port which made the HRP possible and laid the foundation for EDuke32,

The other ports are also downstream from JFDuke3D, either directly (DukeGDX and Raze) or through EDuke32 (Rednukem), hence me calling it the grand daddy. But as I said Rednukem has superseded it as the "vanilla accurate" port

[JonoF]

I wouldn’t waste an ounce of effort trying to accommodate JFDuke3D. It reached its final form a long time ago.

[NightFright]

Well, if even the port author chimes in and states it's lost cause...

[NightFright]

Special request:
Widescreen-ification of the "Duke Nukem Forever 2013" RPG launcher.

Not necessarily for this project, but for archiving purposes.

[NightFright]

Version 1.6 has been released, at long last!
As usual, download and changelog can be found on Github.

[Doorhenge]

NightFright, on 27 March 2024 - 09:20 AM, said:

Version 1.6 has been released, at long last!
As usual, download and changelog can be found on Github.

Here is a non-stretched 3d Realms Plaque.

for the life of me I can't seem to convert it to the right palette to make it work. Keeping the indexes the same and all that, doesn't seem to work for me.

Attached thumbnail(s)

• 

[Phredreeke]

There's a reason that particular tile is defined using a regular hightile in the ERP.

What you need to do is convert it to this palette, then change it to use the standard palette while retaining index values.

Although I feel that some sort of engine side coding is needed to tackle most screens

[Doorhenge]

Phredreeke, on 07 July 2025 - 01:19 PM, said:

There's a reason that particular tile is defined using a regular hightile in the ERP.

What you need to do is convert it to this palette, then change it to use the standard palette while retaining index values.

Although I feel that some sort of engine side coding is needed to tackle most screens

isn't that png in that pallette? I did try to put it in the duke3d pal after that with the indexes and it doesn't work.

[NightFright]

BafEd might be able to do the conversion:
https://forums.duke4...s-editor-bafed/

IIRC it has the intro screen palettes implemented. Another option to try is SLADE.

In the meantime, here is a fixed version of the tile - still without proper palette, though. Seems to be darker than the original in general as well. (Also, we would need this in two versions - one for EDuke32 and one for Raze. The latter doesn't need a conversion IIRC.)

Attached thumbnail(s)

• 

[Doorhenge]

NightFright, on 08 July 2025 - 01:54 PM, said:

(Also, we would need this in two versions - one for EDuke32 and one for Raze.)

Are you asking me for one that will work in raze? The pic you posted seems to work for me in Raze.

Trying to make this work has been a little dirty dog. but I found the answer.

put the line "texture" in the definition and it ignores that stupid palette crap in eduke.

tilefromtexture 2492 { file "tiles/widescreen/2492-raze.png" texture ifcrc 0xD153CF9A }

[NightFright]

I'm sure there's a way to get it working. We already did it with the previous version of this tile, so... patience. ^^

[Phredreeke]

NightFright, on 10 July 2025 - 01:03 AM, said:

I'm sure there's a way to get it working. Phredreeke already did it with the previous version of this tile, so... patience. ^^

Anyway, try this and tell me if it works.

Attached thumbnail(s)

• 

[Doorhenge]

Phredreeke, on 10 July 2025 - 09:56 AM, said:

Anyway, try this and tell me if it works.

Can't you test it? well anyway, it still has the same problem - stuffed with blue and black pepper across it.

[NightFright]

I believe this was poorly converted when the widescreen parts were added already, hence the color being off. Trying to re-apply the original palette at this point may not work any more. It would probably have to be redone.

[Phredreeke]

Second try. This time I "unmapped" colors that gave the wrong results when converted. It should work now as there are no more ambiguous mappings.

Doorhenge, on 10 July 2025 - 01:01 PM, said:

Can't you test it? well anyway, it still has the same problem - stuffed with blue and black pepper across it.

The computer where I have most of my Duke work is currently offline, including the palettes. I had to reconvert the realm14 palette to a format PSP could use (thank Daedolon for that, he made the tool and it was fortunately still in our Discord DMs from 7 years ago). I really didn't feel like fiddling with def scripts to load it up in eduke32 to check that it converted right.

Attached thumbnail(s)

• 

Attached File(s)

•  realm14-hacked.zip (1.13K)
  Number of downloads: 22

[Doorhenge]

Phredreeke, on 10 July 2025 - 03:09 PM, said:

Second try. This time I "unmapped" colors that gave the wrong results when converted. It should work now as there are no more ambiguous mappings.



The computer where I have most of my Duke work is currently offline, including the palettes. I had to reconvert the realm14 palette to a format PSP could use (thank Daedolon for that, he made the tool and it was fortunately still in our Discord DMs from 7 years ago). I really didn't feel like fiddling with def scripts to load it up in eduke32 to check that it converted right.

Bingo! looks great! unlike my method this shows up looking right in software mode too.

Can we do widescreen hi-def screens yet or is it as no go? it still hasn't been done in the hi def pack.

[Phredreeke]

The ERP has a widescreen title screen tile so it's certainly doable.

[NightFright]

In this mod we operate with low-res assets only, so hi-res stuff won't be of any use here. Feel free to post it in the ERP thread if you wish to go ahead with it, no problem with that. ^^

The edit posted by Phredreeke won't work with existing tilefromtexture definitions, though. I'm afraid I would have to insist on this since it is a requirement for this project.

tilefromtexture 2492 { file "tiles/widescreen/2492.png" ifcrc 0xD153CF9A }

[Phredreeke]

It does work, I just checked it, both in Rednukem and EDuke32. Here it is using the exact syntax you requested.

Raze will need a different definition any way you go about it. Alternatively the new 3D Realms logo could be put in an ART file, which should work the same in both Raze and EDuke32, but then there's a higher probability of interfering with custom episodes, which is probably a greater concern.

Attached File(s)

•  new3drealmslogo.zip (42.12K)
  Number of downloads: 22

[NightFright]

Got it working. It's on Github now. Thanks a lot!
(Maybe someone can still test it in Raze, just to make sure the alternate tile works.)

If anybody wants to take a shot at the following, feel free:
- 3240_vaca (Vacation tally screen > uses gapfiller)
- 3281_vaca (Vacation menu screen > uses gapfiller)
- 3292 (Ep.1 ending screen > black edges)
- 3293 (Ep.2 ending screen > black edges)

[Phredreeke]

Here's my idea of the episode ending screens

1. take the current images and crop out the text.
2. the game scales the image to fit the width of the current resolution, fade in from black.
3. after a short time, type the text over the screen. this would necessitate a font change for visibility

This is a radical change, and would require CON coding. But it avoids scenarios such as a small image with black borders all around, or placing important things outside of the area visible when running in a narrower aspect ratio (this happened before IIRC)

[NightFright]

It would probably look good in EDuke32 for sure, but I doubt there's a way to make it work in all ports. CON coding is something I'd really like to avoid here. It's surely a neat idea for a highres project, though.