Is there a Crispy derived sourceport capable of running everything from Doom to Hexen with a single executable?

[Dweller Dark]

I haven't been able to find any kind of Crispy derived sourceport that fits the title, and I'm not sure if one exists that does. To simplify what I'm looking for, it would be like Woof if it had support for Heretic and Hexen, like a DSDA-Doom equivalent in the Crispy/Woof lineup. And iff there isn't such a sourceport, is it feasible to create one?

[Gez]

Possible, yes. Easy, no.

 

Just out of curiosity, what motivates this request? In other words, in a Choco/Crispy context, what's wrong with separate executables?

[Dweller Dark]

1 minute ago, Gez said:

Possible, yes. Easy, no.

 

Just out of curiosity, what motivates this request? In other words, in a Choco/Crispy context, what's wrong with separate executables?

 

Well, the major reasons is that I really like the software look and vanilla compatibility of Crispy and sourceports based on it, and I like being able to run most of my IWADs with just one executable. Crispy, for example, has six total executables for setting up and playing Doom, Heretic, and Hexen. DSDA-Doom or GZDoom have one executable each and can run most older IWADs (like Doom, Doom 2, Plutonia, Evilution, HACX, Chex Quest, Heretic, Hexen, and so on). Both of those together are 1/3rd of the executables needed to run anything with Crispy. But it might be simpler to add Heretic/Hexen support to an existing sourceport that only uses one executable than to make an entirely new sourceport.

[rzh]

Not as far as I'm aware.

Chocolate tries to emulate the vanilla .exe as close as possible so no extended functionality apart from really basic limitations and additional controls. Vanilla Doom's .exe never supported Heretic :p

Crispy is "how many QoL features can we add / limits can we remove while still being minimalistic".

I also like having them separated, because this way I have a Doom folder, a Heretic folder and a Hexen folder that are all as light and as organized as possible.

There's also the issue with Crispy's set of features (Doom having the most and Hexen the least), which aren't implemented across all games.

All in all, I don't think there's enough interest for creating and maintaining such a project, sorry.

[NightFright]

I think having three separate executables is a small price to pay and we can be glad we have those.

[Graf Zahl]

IMO combining the different games into one executable is only worth it if the separate games' features can be exposed to the other games. Otherwise the subtler differences between the games can become a real nuisance. Even ZDoom has run into these issues in the distant past because it wasn't careful enough to properly handle a few things that later turned out to become genuine roadblocks.

[Dweller Dark]

1 minute ago, Graf Zahl said:

IMO combining the different games into one executable is only worth it if the separate games' features can be exposed to the other games. Otherwise the subtler differences between the games can become a real nuisance. Even ZDoom has run into these issues in the distant past because it wasn't careful enough to properly handle a few things that later turned out to become genuine roadblocks.

 

So it might be more of a hassle to get support working for the separate games in a single executable than letting them be separate executables targeting those specific games?

[Dweller Dark]

38 minutes ago, rzh said:

Not as far as I'm aware.

Chocolate tries to emulate the vanilla .exe as close as possible so no extended functionality apart from really basic limitations and additional controls. Vanilla Doom's .exe never supported Heretic :p

Crispy is "how many QoL features can we add / limits can we remove while still being minimalistic".

I also like having them separated, because this way I have a Doom folder, a Heretic folder and a Hexen folder that are all as light and as organized as possible.

There's also the issue with Crispy's set of features (Doom having the most and Hexen the least), which aren't implemented across all games.

All in all, I don't think there's enough interest for creating and maintaining such a project, sorry.

 

Yeah, maybe condensing everything down to one executable is something for a later time, then. 

 

33 minutes ago, NightFright said:

I think having three separate executables is a small price to pay and we can be glad we have those.

 

You're right about that, and Crispy Doom can run at least 6 IWADs all on it's own. One executable for 6 IWADs, and two executables for 2 IWADs isn't such a bad thing.

[fabian]

2 hours ago, Eddie 2077 said:

So it might be more of a hassle to get support working for the separate games in a single executable than letting them be separate executables targeting those specific games?

 

Absolutely! 

[Gez]

4 hours ago, Eddie 2077 said:

So it might be more of a hassle to get support working for the separate games in a single executable than letting them be separate executables targeting those specific games?

It definitely is! Because these games have between each other enough subtle differences that when you want to preserve vanilla demo compatibility you have to fill the code with version checks and slightly-different duplicated functions. And that's something that Choco/Crispy isn't meant to do more than it already does to account for the three different v1.9 of Doom.

 

It's relatively easier for DSDA-Doom to do that because it's based on PrBoom+ which is already designed around compleveling everything. Still a lot of work, though. And Hexen is such a massive divergence from Doom (completely different line format and special action code, addition of scripting, hub travel, polyobjects, many tables de-hardcoded and exported to MAPINFO, SNDINFO, etc. lumps, and more) that it'll be quite hard to get it into DSDA-Doom. I wonder whether Strife wouldn't be slightly easier in that regard; it still has hubs and the conversation system but that's less than what Hexen has.

[Dweller Dark]

4 hours ago, Gez said:

It definitely is! Because these games have between each other enough subtle differences that when you want to preserve vanilla demo compatibility you have to fill the code with version checks and slightly-different duplicated functions. And that's something that Choco/Crispy isn't meant to do more than it already does to account for the three different v1.9 of Doom.

 

It's relatively easier for DSDA-Doom to do that because it's based on PrBoom+ which is already designed around compleveling everything. Still a lot of work, though. And Hexen is such a massive divergence from Doom (completely different line format and special action code, addition of scripting, hub travel, polyobjects, many tables de-hardcoded and exported to MAPINFO, SNDINFO, etc. lumps, and more) that it'll be quite hard to get it into DSDA-Doom. I wonder whether Strife wouldn't be slightly easier in that regard; it still has hubs and the conversation system but that's less than what Hexen has.

 

I see. Is the complexity of Heretic, Hexen, and Strife why support for those is either incomplete or nonexistent for some sourceports as well?  

[GoneAway]

5 hours ago, Gez said:

It's relatively easier for DSDA-Doom to do that because it's based on PrBoom+ which is already designed around compleveling everything. Still a lot of work, though. And Hexen is such a massive divergence from Doom (completely different line format and special action code, addition of scripting, hub travel, polyobjects, many tables de-hardcoded and exported to MAPINFO, SNDINFO, etc. lumps, and more) that it'll be quite hard to get it into DSDA-Doom. I wonder whether Strife wouldn't be slightly easier in that regard; it still has hubs and the conversation system but that's less than what Hexen has.

That's what I originally thought, but in the end complevels didn't really help all that much. In reality, it would probably be significantly easier for a port like choco or crispy to merge heretic in because the code is significantly closer to heretic than prboom+ was (older code = closer to doom v1.2 = closer to raven). There were a lot of times where I had to perform a 3-way comparison of how something was implemented in prboom+, crispy, and heretic (if prboom+ was quite different on the surface level but crispy and heretic were the same, it would imply prboom+ was also fine for heretic for a given section). Many of those cases would be trivial if merging directly into crispy. All of the logic related to rendering comes to mind (the old implementations are hardly recognizable in prboom+). The real hard truth about this kind of project is that you just need someone dedicated to the project that will just grind it out. The process of merging another code base or otherwise adding support piece by piece for an entire game is long, complex, and at times tedious.

 

"Hexen...it'll be quite hard to get it into DSDA-Doom" - Hexen support was added in august of last year.

[Shepardus]

14 hours ago, Graf Zahl said:

IMO combining the different games into one executable is only worth it if the separate games' features can be exposed to the other games. Otherwise the subtler differences between the games can become a real nuisance. Even ZDoom has run into these issues in the distant past because it wasn't careful enough to properly handle a few things that later turned out to become genuine roadblocks.

I think this is really the core of it - unless you're actually doing something with the combination of the different games like ZDoom does, or dsda-doom with the Doom in Hexen stuff, merging them into a single executable is a lot of work for something that's not functionally any different from using a launcher to launch one of the Crispy executables.

[Blzut3]

There actually is a relatively easy way to do it as demonstrated by ReflectionHLE for Wolf3D/Catacomb 3D.  There the code was converted to compile as C++ and then everything was compiled into a namespace.  The benefit is marginal but ReflectionHLE has a built in launcher so it makes that simpler I suppose.