Source Ports personal deal breakers

[LexiMax]

off-topic digression elided

Edited November 19, 2023 by LexiMax

[Mordeth]

We're done here.

 

[Edit] Re-opened on OP's request. They are looking for recommendations for what to do or not to do when making one's own source port. I'd suggest sticking to that specific topic.

[CacoKnight]

Thank you, I can even make a list of all the posts that can be removed if you'd like that.

[LexiMax]

One "mistake" that used to be quite common in ports is using the default SDL_Mixer implementation of playing MIDI music.

 

SDL_Mixer's MIDI music player has been broken on Windows for quite some time.  Using it prevents a user from being able to set the MIDI music volume separately from sound effects on anything newer than Windows Vista, which was released over 15 years ago.  Most modern source ports have a workaround of one flavor or another, but you can't simply throw a MIDI file at SDL_Mixer and expect music to work properly.

 

EDIT: If you're curious, it seems like ceski's winmusic is the least-intrusive way of accomplishing this.  It looks a little gnarly because it's essentially injecting and rewriting volume events into the MIDI stream, but it's a fair bit less intrusive than bringing in a library.

 

Other alternatives include.

• ZMusic is a very capable alternative that allows you to have the music-playing feature-set of GZDoom.
• Odamex uses PortMidi to help with the MIDI rewriting, and to ease playing with external MIDI synthesizers, but it's a bit overkill for all the work you will have to do just to do what ceski's code does out of the box.
• Standalone FluidSynth exists, but from what I understand it can be tricky to integrate into a project from scratch, and it won't sound quite like Windows MIDI. ZMusic includes it in-tree.
• Playing MIDI in an external process was something that was done previously by many Chocolate forks and Eternity engine, but the setup turned out to be a bit brittle and as far as I'm aware no port that is actively in development uses it anymore.

Edited November 19, 2023 by LexiMax

[CacoKnight]

There was some confusion with the my English since it's not my first language, I'm not trying to make a port but I like to constantly learn new things and tweak/improve the ones I use, that's the main reason of why I started this thread, to know what people like or don't.

 

Thanks for all those info!

 

52 minutes ago, LexiMax said:

• ZMusic is a very capable alternative that allows you to have the music-playing feature-set of GZDoom.

Nice, didn't know about this either. Does DSDA use ZMusic as well since on that GitHub page they say the newer PrBoom+ uses this?

 

52 minutes ago, LexiMax said:

FluidSynth won't sound quite like Windows MIDI

Oh... really? I haven't even thought about that. Maybe it's not a big deal (for me) since the reason I haven't thought about it is because I can't hear a difference, just some volume change.

 

edit:

Funny now that I'm searching things I see people complaining that FluidSynth is "too quiet", it's the main reason I like it more than others, lower lows. But I understand the volume may not be accurate with all the others.

Edited November 19, 2023 by CacoKnight

[LexiMax]

1 hour ago, CacoKnight said:

Oh... really? I haven't even thought about that.

 

SDL_Mixer has two ways of playing MIDI on Windows - either by using Windows MIDI directly via WinMM, or by using a software synthesizer that it has built-in called Timidity.

 

Windows MIDI sounds like how you remember it, but it has largely sat untouched since the 90's, has had broken volume control since Vista, and only works on Windows.

 

Software synthesis will sound exactly the same across all supported platforms - it's in the name, a synthesizer implemented in software - but requires the use of a soundfont and people tend to complain when their MIDI's don't sound like how they remember it playing on Windows XP.

Edited November 20, 2023 by LexiMax

[rfomin]

6 hours ago, LexiMax said:

If you're curious, it seems like ceski's winmusic is the least-intrusive way of accomplishing this.  It looks a little gnarly because it's essentially injecting and rewriting volume events into the MIDI stream, but it's a fair bit less intrusive than bringing in a library.

 

It turns out that inserting MIDI volume messages is the correct way to work with MIDI hardware, that's what ZMusic, Portmidi and original DMX do. It's just that I hadn't researched it much when winmusic was first implemented. Nowadays it has been greatly expanded by @ceski and even has complevels.

[Caffeine]

On 11/16/2023 at 4:23 PM, CacoKnight said:

Have you ever tried Nugget?

 

No, I have not. I am certainly willing to try new things, but I settled on DSDA-Doom and GZDoom for a reason.

 

I like DSDA-Doom because while it sticks to the old-school feel of OG Doom and Boom reasonably well, its interface is a bit more modern and easy to use. I like DSDA for when I want to play the old-school way.

 

I like GZDoom because of its advanced features, even texture filtering which I turn on and off depending on the wad I am playing (shots fired, lol). I grew up with Doom as a teenager, and I distinctly remember when GLQuake and later Quake 2 came out that I wished Doom could look that nice. With GZDoom, it does: plus it has plenty of support for other advanced features in UDMF and both types of scripting that enable the mish-mash of Doom and Quake that I dreamed about back in the 1990s. Essentially, Quake-ish geometry with Doom's palette, textures, weapons, and most importantly, its bestiary that is still my favorite thirty years later.

 

Depending on the wad I am playing and the mood I am in, I can switch between a more old-school, "pure but modern" Doom experience with DSDA-Doom, and a "I don't care: I want Doom's game play but rendered like it is at least 2010" experience with GZDoom.

 

I am not convinced there is room for another source port in there, but I am willing to try. I did try Chocolate Doom a few months ago and feel that it did not do anything for me that DSDA-Doom cannot do, but with a more primitive interface. Nugget looks to sit somewhere between Chocolate and DSDA, if I understand its Doom Wiki page correctly. While I am doubtful I will like it enough to add it to my list of favorite source ports, I will try it and go in with an open mind.

[CacoKnight]

You missed a point, hardware vs software mode. Nugget is the absolute smoothest I've tried in software mode and if you're looking for the most accurate for vanilla lights, palettes, sprites etc. you have to run software mode. Give it a try for sure yeah, I keep all three.

 

I constantly update the first post of this thread based on my testing.

Edited November 22, 2023 by CacoKnight

[CacoKnight]

@dpJudas what is the map's name on the VKDoom's homepage?

Edited November 22, 2023 by CacoKnight

[dpJudas]

2 hours ago, CacoKnight said:

@dpJudas what is the map's name on the VKDoom's homepage?

The first two maps are DM01 and DM02 in Nash's Disdain game. I'm not sure if they are publicly available or not. If they are, there's a demo of Disdain on Steam that might have them.

 

The screenshots bit further down the page are from various Doom maps where their mappers have experimented with how they could look like using light maps or ray traced dynamic light shadows.

[The Doommer]

On 11/3/2023 at 7:07 AM, CacoKnight said:

GZDoom is the port that made me love Doom (again) after so long and I still use it daily

 

Same actually

 

Back to the topic at hand, performance mostly

I'm cool with limit-removing stuff

[CacoKnight]

On 11/22/2023 at 3:19 PM, dpJudas said:

The screenshots bit further down the page are from various Doom maps where their mappers have experimented with how they could look like using light maps or ray traced dynamic light shadows.

Those look damn amazing btw, still can't believe Doom can look like that, crazy stuff.

[CacoKnight]

On 11/25/2023 at 7:15 AM, The Doommer said:

I'm cool with limit-removing stuff

Changed my mind on the complevels, it's a personal deal breaker now :) Also updated the first post about it.

[CacoKnight]

Sorry guys, new post because it's a completely different subject.

 

I was thinking, since I'm not really a programmer, how hard would it be to copy the 800p (4x) (maybe even 600p (3x)) resolution code from a different port and add it and maintain it, for every new release of DOOM Retro, into a fork? Can't be that hard right? Only that, the other options are pretty awesome actually I like the port. Thanks.

Edited December 1, 2023 by CacoKnight

[Redneckerz]

1 hour ago, CacoKnight said:

Sorry guys, new post because it's a completely different subject.

 

1 hour ago, CacoKnight said:

how hard would it be 

 

1 hour ago, CacoKnight said:

I'm not really a programmer,

 

1 hour ago, CacoKnight said:

Can't be that hard right? 

Code entirely depends by who has written it. You can have streamlined code and you can have spaghetti code. Both achieve the same result, but you are better pressed to go with the former than the latter, since the latter might be slower, more prone to bugs, etc..

 

In other words, what may sound easy might be difficult as not all source ports are created equal.

[CacoKnight]

Nice reply, I was going back and forth thinking "how hard can this be, it's only ONE feature ...but I'm not a programmer I have no idea" but yeah, I see your point there.

Edited December 29, 2023 by CacoKnight

[Gez]

Porting code from port A to port B depends on how different both ports do stuff. Rendering in particular is a thorny issue because that's one thing that can be modified quite freely from the original without breaking anything you might want to keep -- cf. any port with hardware-accelerated rendering, or even new software renderers like Eternity's "Cardboard" or Helion or even Rum & Raisin.

 

Ports may also have moved from the original C to a different language, e.g. C++ (ZDoom), C# (Helion), or even Java (Mocha Doom), Delphi (DelphiDoom), Eiffel (Brie Doom)... Plenty of oddball stuff if you start digging; Doom has always been one of the most popular code base to mess with, hence all the memes about running Doom on random stuff absolutely unsuited for it like an ATM, a printer, a watch, etc.

 

So all this means that it really depends on a lot of factors whether grafting code from port A to port B will be easy or hard.

[CacoKnight]

Thanks for that reply as well. Also to be clear, I meant forking Retro + the 800p code, Brad already said it's one thing he likes to keep and I respect that, didn't mean to demean anyone's work :)

[Gez]

Doom Retro is based off an older version of Chocolate Doom, so the easiest would presumably to look for the higher-res code of anothr Choco fork. Obvious starting point here would be Crispy Doom, but its high-res mode is limited to doubling resolution to 400p, so look at forks of Crispy instead for 800p.

[JadingTsunami]

4 hours ago, CacoKnight said:

Thanks for that reply as well. Also to be clear, I meant forking Retro + the 800p code, Brad already said it's one thing he likes to keep and I respect that, didn't mean to demean anyone's work :)

 

To put it in non-programming terms, imagine you have two books with two different stories in them. They take place in the same genre but contain different characters, settings, and storylines. Suppose you like one book more than the other, but the other book you don't like as much contains a chapter with a big fight that you like a lot, and you wish the big fight chapter was in the other book you like better. So you ask "how hard could it be to include JUST that chapter I like in the other book?", but this is much harder than it sounds. Sure, you could copy and paste the chapter, but the rest of the story won't make sense. Characters won't be in the correct places when the fight takes place. The fight setting would contain characters not in the book. Characters would talk about events that never happened. And so on.

 

As a one-time effort, maybe you could fix up the story so the fight chapter fits, and edit any references before or after that don't make sense (for example, if characters say "we've never been in a battle before", you need to make sure that line is before the fight chapter or removed, and so on). But to make it worse, neither book in this case is finished. So you would need to continually adapt to the changes in each book to make the transplanted chapter make sense.

 

This is why your intuition that what you're asking is much more effort than you think is correct (you had good insights there): many (perhaps even most) "features" are not isolated modules that you can "click" into place. They're woven into the storyline like in a book, and it's often a significant effort to move them around.

[CacoKnight]

Oh, this makes sense actually, nice analogy thank you.

 

5 hours ago, Gez said:

so the easiest would presumably to look for the higher-res code of anothr Choco fork

So... International Doom is a Chocolate fork with 800p resolution..

 

I thought about all this because yesterday I noticed the hidden spoilers in the Nugget's thread's first post, where Alaux says he doesn't considers himself a programmer and I was like geez if he's not a programmer and he made all those changes and my favorite Doom port how hard can it be to fork Retro and add just that one thing, but now I understand more, it's a little more tricky than I thought.

Edited December 1, 2023 by CacoKnight

[The Doommer]

On 12/1/2023 at 1:21 PM, Gez said:

Ports may also have moved from the original C to a different language, e.g. C++ (ZDoom)

 

C to C++ ports should be mostly fine for more experienced C/C++ programmers, but I agree

It can still be very messy

[Xemonix]

I don't think I have any specific "dealbreakers", I've tried over 20 different source ports (around 18 installed on my computer right now), and I didn't straight up dislike any of them. Despite that, whatever source port I try playing with, I always fall back to GZDoom, DSDA and Cherry (also Zandronum for occasional multiplayer sessions). GZDoom is only for the maps and mods that require it. If a WAD can be played in DSDA or Cherry, I'll play it in DSDA or Cherry. I still can't decide which of the two I like more. I keep switching between them every month or two, ha-ha.

[CacoKnight]

Geez 18? :)

Yeah same, I like all of them but I keep GZDoom, DSDA and Nugget, I'm on the same boat, I circle between them and can't decide which one is my favorite but I tend to use Nugget the most, it's the one I feel the most when playing.

 

To separate them a little I keep GZDoom more full of options now, hardware renderer and hardware palette tonemap, to run maps like Lullaby. DSDA on OpenGL and Nugget full software so I see some differences when I play them, but again, I like all three the same.

 

Sometimes I run DOOM Retro and Crispy too because they are just fun ports but I HATE (!!) that they only go up to 400p!

Edited December 6, 2023 by CacoKnight
grammar

[tomas7777]

On 12/6/2023 at 6:02 PM, CacoKnight said:

Sometimes I run DOOM Retro and Crispy too because they are just fun ports but I HATE (!!) that they only go up to 400p!

Have you looked at So Doom? It's a fork of Crispy and one of its features is supporting 800p.

Nvm I just read the first post lol. Also, you can disable infinitely tall actors, it's a setting called "Walk over/under monsters".

Edited December 12, 2023 by tomas7777

[CacoKnight]

52 minutes ago, tomas7777 said:

Also, you can disable infinitely tall actors, it's a setting called "Walk over/under monsters".

Oh damn damn, how the hell did I miss this? Editing right now, thank you!

[CacoKnight]

On 12/11/2023 at 4:56 PM, tomas7777 said:

it's a setting called "Walk over/under monsters".

What the hell, I just noticed you can do that in Crispy too, what an awesome port it is, the longer I use it the better it becomes.

 

I need to try FOV 90 again without thinking about it too much and see, that would re-include so many ports.

Edited December 19, 2023 by CacoKnight

[CacoKnight]

Added a comparison link, please double check, still learning here https://rentry.co/doomconfigs#comparison

 

I only add ports that have: MBF21, FOV and 800p/800p+ (Retro has 400p max but it's an exception for now).

 

edit:

Pretty much done, this is too much work damn it. Can someone help me with the audio/music file formats? Not sure which ports supports what and can't find much about it.

Edited December 28, 2023 by CacoKnight

[Professor Hastig]

Here's a few random comments about your list:

 

* '.lmp' doesn't really mean much. Better write 'Vanilla Demo support', then it's clear.

* What is "Level stats bar"? The term doesn't tell me much.

* Music formats:

** MID and MUS are obviously supported by all ports.

** Streaming formats: Ogg is supported by all major ports. MP3 I'm not sure, but AFAIK DSDA also supports it. Opus is less commonly supported.

** Common module formats (MOD, IT, XM, S3M) should be supported by all major ports, all that I checked have some support for them.

** There's some more esoteric formats that may or may not be supported, but I have never seen them in released mods, aside from Descent's HMP MIDI format, which is only supported by GZDoom. The common MIDI and module formats plus Ogg and (very rarely) MP3 will make up 99% of all music.

* If you start listing all different names for zip file extensions the list will get long. Under the hood pk3, pk4 and pke are all just normal zips, and pk7 is just a normal 7z file, just renamed. You could rename the files to anything and they'd still be loaded, even if your extension was ".myawsomedoommod". What is far more important here is not the file format but how content is organized, and here is where things will become incompatible. As an example, historically .pk3 was Quake 3's file extension, but Doom ports won't be able to do much with such files...

* You may just as well strike RAR off the list. The unpacker for it is not considered free software due to a license restriction that is not compatible with the GPL so no GPL port will ever be able to legally support it.

Edited December 27, 2023 by Professor Hastig