Obligatory Legacy of Rust/ Nightdive Doom Port thread

If it's not ZDoom, it goes here.
Gez
 
 
Posts: 17937
Joined: Fri Jul 06, 2007 3:22 pm

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by Gez »

AliciaPendragon wrote: Fri Aug 30, 2024 10:53 am Will at least the animated skyboxes, custom intermission screens and additional weapon slots of ID24 be added to GZDoom proper?
Custom intermission screens are probably not too hard; GZDoom already has that feature, it just needs a JSON parser for the ID24 format. (And by JSON parser, I mean just to specifically handle these properties and treat them accordingly; GZDoom already has the code needed to parse JSON files; the save format is in JSON for example.)

SBARDEF likewise shouldn't be too much of a problem; it'll just be kind of redundant with SBARINFO and ZScript but it can be handled.

Skydefs shouldn't be too hard, the main problem will be implementing the firesky.
yum13241
Posts: 854
Joined: Mon May 10, 2021 8:08 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): EndeavorOS (basically Arch)
Graphics Processor: Intel with Vulkan/Metal Support

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by yum13241 »

Borrow it from PSX Doom CE I guess, they have a shader that emulates it. Just change it so it's not the PSX fire sky but the LoR fire sky.
Also, saves used to be PNG's JUST for the save screenshot. Now that is really fucked.

Also, I feel we're all shouting at a wall here lol.
User avatar
Phredreeke
Posts: 310
Joined: Tue Apr 10, 2018 8:14 am

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by Phredreeke »

I agree that it's shortsighted.

What you're saying makes sense for a developer with a long term commitment. Unfortunately going by what I've heard on doomworld and elsewhere they were rushed to get it out by QuakeCon. Certainly a downside of commercial ports.
yum13241
Posts: 854
Joined: Mon May 10, 2021 8:08 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): EndeavorOS (basically Arch)
Graphics Processor: Intel with Vulkan/Metal Support

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by yum13241 »

rushed to get it out by QuakeCon
In the age of "almost everyone who plays Doom has an internet connection", updates are possible. It's out of character for Nightdive to rush something and never update it with fixes.
User avatar
Xterra
Posts: 69
Joined: Thu Feb 24, 2011 3:20 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Win7 SP1 / Tiny10 dualboot
Graphics Processor: nVidia with Vulkan support
Location: The ragged edge of disaster ('Bama)

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by Xterra »

yum13241 wrote: Thu Aug 29, 2024 2:58 pm
Xterra wrote: I will say that anonymous functions in DEC were a wonderful addition, and very much bridge a major capability gap.
Which no one ever uses, because Zandro's DECORATE does not support them, and if your DECORATE only runs in GZDoom, you may as well run it through that one DEC -> ZSC converter.

ZScript is actually quite easy to work with once you know its idiosyncrasies as a result of Doom cruft from iD, and if you take baby steps. Don't make your first ZScript project a Brutal Doom: ZScript edition-type mod..
I'd stand to gain *nothing* from converting my DEC actors to ZSC, and my mod already runs some compat-minded ZSC anyway. It's always been a GZ/LZ-exclusive mod to begin with, gonna stay that way.
yum13241
Posts: 854
Joined: Mon May 10, 2021 8:08 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): EndeavorOS (basically Arch)
Graphics Processor: Intel with Vulkan/Metal Support

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by yum13241 »

Xterra wrote: I'd stand to gain *nothing* from converting my DEC actors to ZSC
If your mod is a monster mod, monsters don't benefit from ZScript that much until you want to code in stuff like headshots (there's a headshot lib out there), advanced AI, and stuff like that. While weapons start to benefit from ZScript much earlier, as even basic stuff (like shooting lots of pellets or reloading) starts to make your code look really bad. Try not looking at the mod for a while, then come back to it. I don't know how Sarg knows his way around Brutal Doom anymore.

Besides, if you try to do ANYTHING "universal", ZScript is essentially required.
User avatar
Hellser
Global Moderator
Posts: 2741
Joined: Sun Jun 25, 2006 4:43 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Manjaro Linux
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: Citadel Station

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by Hellser »

yum13241 wrote: Fri Aug 30, 2024 12:08 pm Also, saves used to be PNG's JUST for the save screenshot. Now that is really fucked.
ZDoom's .zds files (ZDoom Save files) were just PNG files with save data appended to it...

So, after peeking through the ID24 stuff;

Code: Select all

Known Bugs              : Some cosmetic-only features may not work fully in
                          MBF21-compliant ports, since they're using new
                          ID24 features; gameplay should be the same.
Custom PSX-like skybox aside, it seems GZDoom is well on the path to support everything. Running a quick test, I'd say we're 99% the way there.

And, after re-reading this thread. Some personal opinions, everyone's entitled for those:

I love GZDoom/ZDoom, I've been part of this community since June of '06... and I had to rewrite the following words so many times without trying to step on anyone's toes:

GZDoom will never be the Golden Standard. Get your pitchforks and torches out and prepare to burn the heretic!

GZDoom prides itself in being the bleeding edge of the Doom community. Through bleeding edge, we lose ourselves for the sake of cool ideas and forget what the vast majority of other source ports strive to protect: Compatibility. The GZDoom community suffered this in the past; I myself have an ancient mod that ran fine on older GZDoom where FMOD outright shits itself on my newer system but is completely broken with the latest GZDoom. DECORATE right now is a deprecated feature set and anyone who looks to use it is ushered to the "How to ZScript" pages. I don't want to use ZScript, I'm not a C-style coder - and it took me a while to understand DECORATE, but I got the hang of it. Now, how long will it be before DECORATE itself is completely abandoned and all DECORATE mods out there will get broken? Five? Ten? Twenty years? What happens to DECORATE and ZScript if it's abandoned for the new and shiny... I don't know, ZScript++?

Let me put it through my personal view: GZDoom is no longer the Doom that 70% of the rest of the community knows. It is now an advanced source port that's trying to emulate Doom, Heretic, Hexen and Strife with logic that's built in mimicking what we knew from DECORATE. Onto map compatibility; does a map work with PrBoom+ but doesn't work with GZDoom? Let's whip up a little text file to throw into GZDoom to activate some sort of archaic compatibility mode. Once again, hinting that GZDoom is just emulating Doom. Because GZDoom has its OWN standard that does not follow the other source ports available. It strives to make its own path, and that's fine! But let's not burn ID24 for its ideas... because I assure you, soon those MBF compatible source ports will include ID24 into its feature list... and here we are arguing about DEHACKED being layers upon layers of a hacky mess... and to which I say, yes. It is. But it's the 70% that will use those DEHACKED features. It sucks, we just have to accept it and move on.

You may now burn the heretic. :grr:

Edit: Looking at Woof!, they're already discussing about ID24 - minor push back, but the general idea is that the cosmetic features, intermission screen and hud will be supported. Already leap and bounds compared to us arguing over JSON parsing...
User avatar
Rachael
Posts: 13853
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by Rachael »

Hellser wrote: Mon Sep 02, 2024 1:31 am
GZDoom will never be the Golden Standard. Get your pitchforks and torches out and prepare to burn the heretic!

GZDoom prides itself in being the bleeding edge of the Doom community. Through bleeding edge, we lose ourselves for the sake of cool ideas and forget what the vast majority of other source ports strive to protect: Compatibility. The GZDoom community suffered this in the past; I myself have an ancient mod that ran fine on older GZDoom where FMOD outright shits itself on my newer system but is completely broken with the latest GZDoom. DECORATE right now is a deprecated feature set and anyone who looks to use it is ushered to the "How to ZScript" pages. I don't want to use ZScript, I'm not a C-style coder - and it took me a while to understand DECORATE, but I got the hang of it. Now, how long will it be before DECORATE itself is completely abandoned and all DECORATE mods out there will get broken? Five? Ten? Twenty years? What happens to DECORATE and ZScript if it's abandoned for the new and shiny... I don't know, ZScript++?

Let me put it through my personal view: GZDoom is no longer the Doom that 70% of the rest of the community knows. It is now an advanced source port that's trying to emulate Doom, Heretic, Hexen and Strife with logic that's built in mimicking what we knew from DECORATE. Onto map compatibility; does a map work with PrBoom+ but doesn't work with GZDoom? Let's whip up a little text file to throw into GZDoom to activate some sort of archaic compatibility mode. Once again, hinting that GZDoom is just emulating Doom. Because GZDoom has its OWN standard that does not follow the other source ports available. It strives to make its own path, and that's fine! But let's not burn ID24 for its ideas... because I assure you, soon those MBF compatible source ports will include ID24 into its feature list... and here we are arguing about DEHACKED being layers upon layers of a hacky mess... and to which I say, yes. It is. But it's the 70% that will use those DEHACKED features. It sucks, we just have to accept it and move on.

You may now burn the heretic. :grr:
Nobody is asking for GZDoom to be the golden standard. We're just asking to not be asked to use a standard that's hacked to fuck and back, something that sanely allows naming instead of numeric ID's. I don't care if it's DECORATE, EDF, DDF, some new standard, whatever the fuck it ends up being, just not DEHACKED!

This isn't about compatibility it's about using a future-proof standard that won't have to be extended with hacks to the engine over and over and over again.

I'm not a ZDoom evangelist. I'm just an evangelist for not using broken shit.
yum13241
Posts: 854
Joined: Mon May 10, 2021 8:08 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): EndeavorOS (basically Arch)
Graphics Processor: Intel with Vulkan/Metal Support

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by yum13241 »

Hell, even DEHACKED didn't like hacking the EXE too much. After screwing around in DHE31 just for the sake of it, you can't even NULL out a function, nor can you make a NULL space have a function. For weapons in Doom 2 you can just use the frame pointer for A_CheckReload, but for items/monsters you can't do much except either edit the file yourself (HOW THE FUCK DO YOU DO TEXT EDITED DEHACKED?), or use WhackEd which is Windows only. Also, we didn't get DECOHACK until a while back and you have to compile it to real DEHACKED every time you want to do something, which is why DEHACKED mods tend to be less balanced, among other things.
Rachael wrote: something that sanely allows naming instead of numeric ID's.
Wait until you realize sprites are numbers... Oh, you already know that. Worst case scenario, we keep using numbers but convince everyone to make a "ThingSpawner" item that takes 1 argument: a ThingName, with the DoomEdNum of 13241. (lol)
Hellser wrote: that's built in mimicking what we knew from DECORATE
You meant "randi screwing the implementation of something up/a close approximation because we couldn't have truecolor yet" (remember the "poison flash [ZDoom|Hexen] option?)
The thing about ZScript is that Graf can expand it how he wants, mainly because of the version directive, among other things, such as being able to add new operators/functions easily.
Hellser wrote: archaic compatibility mode
Doom's behavior is what's archaic here. For example, did you know in Vanilla DOOM.EXE you could not travel straight N/E/S/W because of limitations in the sine table? Most ports aren't as ambitious as GZDoom is (not to blame them, a compat-focused port is always a good thing), and copy this behavior. When a map relies on it, we have to add a compatibility switch. The real fix here is to only use tricks that aren't excessively reliant on glitches/behaviors that were not intended (i.e, TNT's stairbuilder problem)

So you're criticizing GZDoom for not acting like other Doom engine ports (which is valid), then giving it shit when it tries to emulate specific behaviors so you can beat a map/fix some weird trick a map used that works only in software? What's the deal with that?

Yeah, back in the day computers couldn't calculate arbitrary values for sine so easily while running a game.
User avatar
Rachael
Posts: 13853
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by Rachael »

Wait until you realize sprites are numbers... Oh, you already know that. Worst case scenario, we keep using numbers but convince everyone to make a "ThingSpawner" item that takes 1 argument: a ThingName, with the DoomEdNum of 13241. (lol)
Yes - you are indeed correct, but at least with EDF/DECORATE/whatever they are names before they become numbers and the engine can assign them unique numbers without worry of collision or stepping on someone's "reserved" id.
yum13241
Posts: 854
Joined: Mon May 10, 2021 8:08 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): EndeavorOS (basically Arch)
Graphics Processor: Intel with Vulkan/Metal Support

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by yum13241 »

You posted twice. Either way sprites are not infinite but we all know long sprite names will never happen in a port, ever.
Rachael wrote: stepping on someone's "reserved" id.
Like all those MusicChanger things. Why was ID24's version of MUSINFO not thought of back then?
Gez
 
 
Posts: 17937
Joined: Fri Jul 06, 2007 3:22 pm

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by Gez »

yum13241 wrote: Mon Sep 02, 2024 11:04 am Like all those MusicChanger things. Why was ID24's version of MUSINFO not thought of back then?
Not sure hacking the texture name field is a preferable approach.

MUSINFO's system is reasonable enough, I've yet to see a single map that uses more than a handful of different tracks, let alone one that would exhaust the 64 different tracks allowed by MUSINFO and still need more. If you reach this point, then you'd probably be better served by using scripts instead of map constructs, be they things or lines.
User avatar
Xterra
Posts: 69
Joined: Thu Feb 24, 2011 3:20 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Win7 SP1 / Tiny10 dualboot
Graphics Processor: nVidia with Vulkan support
Location: The ragged edge of disaster ('Bama)

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by Xterra »

yum13241 wrote: Sun Sep 01, 2024 7:13 am If your mod is a monster mod, monsters don't benefit from ZScript that much until you want to code in stuff like headshots (there's a headshot lib out there), advanced AI, and stuff like that. While weapons start to benefit from ZScript much earlier, as even basic stuff (like shooting lots of pellets or reloading) starts to make your code look really bad. Try not looking at the mod for a while, then come back to it. I don't know how Sarg knows his way around Brutal Doom anymore.

Besides, if you try to do ANYTHING "universal", ZScript is essentially required.
My mod's an old mod, still (slowly) being updated. Randomizer, adds loads of monsters, weapons and items. Been around since 2014 at the earliest, before ZScript ever existed.
I don't care how bad my code looks, as long as it works and I understand it. It works. I understand it perfectly. If it ain't broke, don't fix it. :-P
yum13241
Posts: 854
Joined: Mon May 10, 2021 8:08 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): EndeavorOS (basically Arch)
Graphics Processor: Intel with Vulkan/Metal Support

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by yum13241 »

Xterra wrote: I understand it perfectly. If it ain't broke, don't fix it. :-P
Well others do, especially when you post to the Scripting forum because you can't get something to work. If you're posting code that's Brutal Doom levels of complex, just know that even Sarge indents.
Gez wrote: Not sure hacking the texture name field is a preferable approach.
I agree, but let's not forget that:

1. Vanilla HEXEN.EXE had this figured out. They used ACS, and while that's not super-elegant (it's a separate lump for separate reasons), it works better than eating DoomEdNums, and MUSINFO is already another lump anyway.
2. You can have infinite textures (until you run out of memory), while you can run out of DoomEdNums. (-32768 to 32767, why do programmers add signed-ness when they don't need it?)
Gez
 
 
Posts: 17937
Joined: Fri Jul 06, 2007 3:22 pm

Re: Obligatory Legacy of Rust/ Nightdive Doom Port thread

Post by Gez »

yum13241 wrote: Tue Sep 03, 2024 6:06 am 2. You can have infinite textures (until you run out of memory), while you can run out of DoomEdNums. (-32768 to 32767, why do programmers add signed-ness when they don't need it?)
Running out of editor numbers is a very theoretical concern.
Official classes include less than 700 entries. Even if you decided to give all the things a unique editor number in all games, even those they're not normally present in, that would still put you at barely above a thousand numbers.

Then let's add in all of Realm667 stuff. There's 13 pages of the armory, with twenty entries per page. That's 260. Let's assume each weapon comes with a big and a small ammo pickup, so we can triple that to 780, and round it to 800. Heck, round it up to 1000.
Bestiary has 20 pages, so that's 400 monsters. Now most of them have one single monster, but there are a few that are packs with a few variants. You know what? I'll just multiply by five. There's no way the average distinct placeable thing per monster pack is 5, but who cares. That's another 2000.
Item store has eight pages, so 160. Again, most of them are individual items, but some are packs, so I'm going to go with 10 times for 1600 more numbers, even if that's absurdly overestimated. I'll round it up to 2000.
Prop stop, eleven pages, 220. Those are usually packs, so I'm gonna go with twenty times just to be sure to overshoot how much unique IDs one would actually need. 4400. Round it up to 5000.
Finally, SFX shop. We've got just two pages, so 40. Highest claimed number of variants was 23, so I'm going to massively overshoot by giving them an average of 50 editor number per pack. Another 2000.
The fonts and textures are not things. The sounds aren't things either, but let's assume we convert them all into ambient sound things. There's a single page, so 20. Biggest amount of variants listed was 59, so I'll multiply by 60. +1200. Round it up to 2000.

So we have:
2000 standard things (I'm just basically doubling it, this way we can account for new ID24 stuff and whatever gets added).
+1000 from armory
+2000 from bestiary
+2000 from item store.
+5000 from prop stop.
+2000 from SFX.
+2000 from extra SFX from sounds.

We arrive at a total of 16000 editor numbers used. That's for all the standard actors from all supported games, plus the entirety of the Realm667 resources, and that's with deliberately overestimating how much we actually need.*

We still have another 16000 editor numbers to go. Just in the positive range. By using unsigned numbers, or allowing negative ones (same result), that's another 48000 numbers available.

Does your mod project needs more than 48000 extra thing types in addition to all the standard things and all the Realm667 content?


So MUSINFO taking up a few dozen editor numbers is not a problem. And it gives us a lump where we can see all the extra music used in all maps, so finding out about how a soundtrack is arranged requires only looking at MAPINFO and MUSINFO.

Scripted music changes now also requires looking at each map script.

ID24's line types now also requires looking at every single map line.

Also map validators that check the maps for if it uses missing textures will need to know about these new line types that use fake textures.

Yeah no, I actually prefer the MUSINFO approach.

Another thing about the ID24 music changing lines is that some of them behave completely differently from all previous music change functions. They've got these "change to this music but play it only once". So now to comply with specs the game must keep track of how long a music has been playing and cut it off when it ends? ZDoom has been happy to just tell the music engine to change which track to play, but otherwise ignore it, there's been no communication in the other way with the music engine telling the game engine that a music has stopped playing. Also it's not clear what happens after the music has ran its course -- does it mean to go back to the default map music, or does it mean to be silent?

Return to “Off-Topic”