VZDoom: The Dream Source Port (rambling)

[Gez]

5 hours ago, AlexMax said:

You absolutely do not have to remove even close to all of the ZDoom stuff.

Oh, you do.

 

Sure one could then go and try to put ZDoom stuff back in afterward, but I'd rather start with a demo-compatible codebase and then build back up than try to hack at the current GZDoom codebase until it's demo-compatible again.

[SilverMiner]

10 hours ago, OpenRift said:

100% dehacked compatibility

Dehacked is not vanilla

Hacked Doom.exe != Vanilla Doom.exe lol

[Maes]

7 minutes ago, SilverMiner said:

Dehacked is not vanilla

Hacked Doom.exe != Vanilla Doom.exe lol

 

What about hacked doom2.exe?

[SilverMiner]

5 minutes ago, Maes said:

What about hacked doom2.exe?

The same

[seed]

What you're asking for kinda already exists - Eternity is probably as close as possible to such a dream. Or something like Chocolate or PrBoom running on the GZDoom backend.

 

But this all reads like a smokescreen to me, judging by the wording, and just another opportunity to give Graf shit because GZDoom is not what some folks want, and you've already admitted your bias before. This is all the more ironic when considering that GZDoom actually got quite a bit more vanilla since ZDoom ceased development, most notably with the return of the vanilla physics. Gonna agree with @ketmar, as long as purists are taken into account, a port will never get too far, as they won't be pleased no matter what, and it's too much of an obstacle.

 

Just use different ports, Choco/Crispy/PrBoom/Eternity for more vanilla mods, and GZDoom for TCs and other things.

[Edward850]

37 minutes ago, SilverMiner said:

Dehacked is not vanilla

Hacked Doom.exe != Vanilla Doom.exe lol

Despite the fact that dehacked is now officially supported by Doom? Thus there's no Doom executable (other than 95) that can't dehacked? 

 

There's semantics and then there's just being plain silly. 

[Loud Silence]

OP, shouldn't you finish fixing your dream SC-55 soundfont first?

 

About dream source ports... many people might be using them already. My dream source port is Eternity Engine for example.

[leodoom85]

The dream port doesn't exis..........wait..........Eternity is the closest port that you can have. Interesting, right?

 

Eternity needs some pats though....

 

Leave alone GZDoom for now since it's used for a plethora of things. If someone does the "dream" port, then go ahead. Then again, we have EE to enjoy. 

Edited January 13, 2021 by leodoom85

[SilverMiner]

27 minutes ago, Edward850 said:

Despite the fact that dehacked is now officially supported by Doom?

If I said it before the rerelease of Doom, I would be actually right

(wondering why dehacked and not edf or decorate)

[seed]

9 minutes ago, SilverMiner said:

(wondering why dehacked and not edf or decorate)

 

Too advanced and incompatible with the engine, most likely.

[Edward850]

10 minutes ago, SilverMiner said:

(wondering why dehacked and not edf or decorate)

Because they do very different jobs. Dehacked changes the existing frame table and string data. It couldn't add anything new because that would have required changing the actual code in the executable. All it does really is just change values and pointers. 

 

EDF and Decorate are for defining entirely new frame tables and objects. They don't change the existing properties of things (don't confuse replacement with editing), and thus require ports designed around a limitless frame table and object references. 

[Maes]

Such threads remind me of the old joke about the guy who went to the doctor and asked how could he have sex with his wife, ejaculate inside her, use no contraception whatsoever, and still not leave her pregnant, and in the end asked "....am I asking for too much?"

 

"No", said the doc, "you're just asking for ass".

[MFG38]

15 hours ago, OpenRift said:

Doesn't run like shit

 

This one strikes me as slightly odd, because in my experience, GZDoom runs about as well as any other source port. That is when it's not trying to process 10k monsters (see nuts.wad) or render a million sidedefs at once. But ignoring those caveats, GZDoom is arguably the most well-kept source port when it comes to keeping up with and optimizing the engine for modern hardware. How many other source ports have implemented a Vulkan rendering backend, for instance? My guess is not many. Naturally it does mean that not-so-modern PCs won't be able to run GZDoom as well, if at all, but realistically, no one in their right mind would even contemplate attempting to run it on a 486 IBM PC anyway.

 

That's not even mentioning the other caveats you mention, such as the port's lacking demo compatibility. I'm no expert programmer, but I can only imagine how much work it'd be to try and hack proper demo compatibility into the engine at this point. Hell, GZDoom itself mentions that vanilla demos would desync horrendously, and the same is even known to happen between different versions of the same engine. GZDoom has strayed so far from true vanilla compatibility by now that making it truly vanilla-compatible is virtually impossible without rebuilding it entirely upon a closer-to-vanilla codebase.

 

The problems you seem to have here are more easily rectified by using another source port that's more vanilla-compatible than trying to shoehorn GZDoom's feature set into the vanilla engine.

Edited January 13, 2021 by MFG38

[Diabolución]

I post this, and I leave the thread alone...

 

https://tvtropes.org/pmwiki/pmwiki.php/Main/PerfectSolutionFallacy

[JustCallMeKaito]

So basically, what you're saying is:

"Fuck this guy. Here's my idea, now you do it for me. Also, fuck that same guy again."

[LexiMax]

6 hours ago, Gez said:

Sure one could then go and try to put ZDoom stuff back in afterward, but I'd rather start with a demo-compatible codebase and then build back up than try to hack at the current GZDoom codebase until it's demo-compatible again. 

 

Oh, in that case I'm completely tracking with you.  That's pretty much what Odamex is doing.

 

2 hours ago, MFG38 said:

GZDoom is arguably the most well-kept source port when it comes to keeping up with and optimizing the engine for modern hardware. How many other source ports have implemented a Vulkan rendering backend, for instance? My guess is not many.

 

Pretty much every port that uses SDL2 has hardware acceleration blitting the software renderer to the screen.

Edited January 13, 2021 by AlexMax