Doom core requests

Bounty Discussion
#1

PrBoom 2.5 has long been obsoleted by other Doom source ports, including the fork PrBoom-Plus. While I’m not suggesting you remove the PrBoom 2.5 core, but rather rename it to PrBoom 2008 (if you want to keep it); as well as port both PrBoom-Plus 2.5.1.4 (as PrBoom 2016) and the latest trunk build (as PrBoom) to Libretro, though I’m not sure if it will be done without the financial insentive of the bounty system.

After that is done, it might be a good idea to look at porting Chocolate Doom and possibly some of its forks (namely Crispy Doom and Doom Retro) to Libretro, especially so Multiplayer, Heretic, Hexen, and Strife support could be added.

1 Like
#2

Related thread: Regarding the choice of prboom

Imho, GZDoom would be awesome to have, since it has become a very capable engine able to support a lot of crazy extensions with many custom WADs out there that make use of them to make games that look and feel like its very own thing, and not just a doom mod. Also, it supports all the other Doom-based games, like Hexen and Strife.

Latest GZDoom got rid of FMOD so it’s now 100% GPL-friendly in its license.

But I know it’s a very complex engine and so it might be hard work to port. Something like Chocolate Doom seems like a simpler and very portable option. It’s still actively maintained and because of its very specific goals it’s likely to continue alive for a very long time. It has already spawn its own family of forks, like you mentioned. However, there won’t be much advantage in adding a Chocolate Doom core if the PrBoom core works fine. And from the comments in the thread I linked, it looks like the main advantage vs GZDoom (vanilla demo compatibility) would be lost when made into a core anyway. So I’d still go for GZDoom personally, or maybe the Eternity Engine, which might be a good compromise (some of the features from GZDoom, while being also vanilla demo compatible).

I’d throw some money to the bounty of a GZDoom core if there’s one.

2 Likes
#3

How exactly would being made into a libretro core kill demo compatibility with PrBoom or Chocolate Doom? If neither the PrBoom or other hypothetical Doom cores can’t play demos, and if the netcode for Chocolate Doom or ZDoom based ports won’t work here, in that case you should still have Chocolate cores for Heretic and Hexen, if not for Doom.

As for GZDoom… yeah, I was curious about how well it could be integrated into libretro. Personally if you really want to include it (though it might be wise to port the simpler cores like Chocolate Doom, its forks, and the newer versions of PrBoom) i’d recommend taking the latest ZDoom maintenence branch (https://github.com/rheit/zdoom/tree/maint) and applying most of the changes from ZDoom Legacy Edition (https://github.com/drfrag666/ZDoom-LE/) except for the ones involving sound (modified openal and older fmod) and input (“No direct3d nor xinput joystick support, only classic directdraw mode.”) Thanks to how the commits for the latter are set, it shouldn’t be too difficult to separate the good changes from the bad.

There are some things I’d like to say about Eternity, but they have to wait for a bit…

edit: Having read that other thread, I find the idea of choosing WinMBF a weird one. I’m fairly sure it’s not synced with mbf-with-fixes (https://github.com/fragglet/mbf/)

#4

How exactly would being made into a libretro core kill demo compatibility with PrBoom or Chocolate Doom?

Quoting @MP2E

When the libretro team ported in prboom they changed the gametic functions from running 35FPS to 60FPS to make the core consistent with the way libretro works, unfortunately this means that no demos can be played back and that, strictly speaking, its not even really “prboom”.

About ZDoom, wouldn’t the licensing mess be a problem? That’s why I was suggesting GZDoom that since April was rewritten to be GPL.

Also, official ZDoom is discontinued, there won’t be more updates to ZDoom.

#5

  1. Libretro has cores with non-free licenses (For example all the SNES9X cores and all but the most recent MAME cores). Is there anything in ZDoom’s licensing situation that is more restrictive than the aformentioned cores?

  2. One of the most important things about the Libretro project is portability. Granted, the latest versions of GZDoom might be superior in their own ways (like better compatibility with other architectures) but with the aformentioned ZDoom LE things like Low Detail mode which have been removed from ZDoom can be restored, which might be useful for more low end systems.

  3. Non “Plus” PrBoom has also been discontinued, and yet it still remains as a core option here. Not to mention how many of the cores here are older versions of other cores that remain for one reason or another.

Edit: Relevent link: https://forum.zdoom.org/viewtopic.php?f=49&t=56740 (Legacy Hardware and Deprecation)

1 Like
#6

I guess there has been no updates in this regard. But I’ve noticed there has been some activity in sdl2-libretro, I’m not sure how far it is from being able to actually port sdl2 games to libretro but considering most of the modern Doom ports use SDL2, that’s probably the way to go.

I still think it would be a waste to go for older versions of no longer maintained code encumbered with non-free code and dependencies (FMOD), for that you might as well just remain using PrBoom, that one is good enough for legacy hardware.

An alternative to GZDoom would be Eternity. Particularly with changes from the splitscreen branch it would be very cool to have, it could mean being able to have retroarch’s netplay infrastructure to play 4-player coop Doom.

1 Like
#7

Would be nice so that BrutalDoom could be ran.

1 Like
#8

GZdoom would be awesome. Doom 64: Retribution is pretty great and only works in that.

1 Like