Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

port Chocolate Doom #4149

Open
vadosnaprimer opened this issue Dec 29, 2024 · 6 comments
Open

port Chocolate Doom #4149

vadosnaprimer opened this issue Dec 29, 2024 · 6 comments
Labels
Core: Future core Core doesn't exist yet or is an early WIP Enhancement For feature requests or possible improvements

Comments

@vadosnaprimer
Copy link
Contributor

vadosnaprimer commented Dec 29, 2024

https://github.com/chocolate-doom/chocolate-doom

The most accurate of the source ports.

Can't tell if it even has threads, but it seems to need to be detached from frontend and turned headless.

@Spikestuff
Copy link

Chocolate with a backup using Crispy?

@vadosnaprimer
Copy link
Contributor Author

The "limit-removing enhanced-resolution" part scared me in Crispy.

@YoshiRulz YoshiRulz added Enhancement For feature requests or possible improvements Core: Future core Core doesn't exist yet or is an early WIP labels Dec 30, 2024
@YoshiRulz
Copy link
Member

My old list had PrBoom+, which is now inactive. Though I'm guessing the choice of Chocolate Doom is because it doesn't have many enhancements, whereas PrBoom+ does.

@vadosnaprimer
Copy link
Contributor Author

Not only does prboom+ have insane amount of enhancements that nobody wants to adapt to our needs, it also has insane amount of dependencies that have to be ripped out. Dunno if libretro already simplified it tho.

@Spikestuff
Copy link

Honestly dsda-doom is probably a better replacement over PrBoom+.
It was made for a stronger focus on speedrunning (literally in the name "Doom Speed Demos Archive - DOOM") and strips out stuff within PrBoom+.

@vadosnaprimer
Copy link
Contributor Author

The only theoretical benefit of prboom is that they already made it build as a headless shared lib. Dunno how hard it'd be to turn chocolate or that dsda thing into that. Maybe not too painful, we just need to look how libretro grabs the data from the core, how it sends back inputs, and how it advances frames. May appear to be kinda universal across all ports. I feel whatever is the closest to vanilla, would be the easiest to support due to lack of feature creep.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core: Future core Core doesn't exist yet or is an early WIP Enhancement For feature requests or possible improvements
Projects
None yet
Development

No branches or pull requests

3 participants