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

Vanilla compatibility issues / lack of emulation #8

Open
GoodSign2017 opened this issue Apr 19, 2017 · 2 comments
Open

Vanilla compatibility issues / lack of emulation #8

GoodSign2017 opened this issue Apr 19, 2017 · 2 comments

Comments

@GoodSign2017
Copy link
Contributor

GoodSign2017 commented Apr 19, 2017

There are couple of bugs that was in vanilla DOOM due to limitations of engine combined with the attributes of the language it was written in - pointer arithmetic, manual memory management and so on.

Of course, in Mocha Doom there is little or no of these bugs. An emulation of them is not simple task, but the Chocolate Doom took approach and succeeded in emulation of most of them.

We lack such emulation. But eventually I would like to implement it.

For now, I'll post a little bit of "bugs we do not have".
If you open this wad in vanilla, the sky would glitch and the demo should crash after the first respawn (visplanes overflow). However, Mocha Doom does behave well beyond this point and show no hall-of-mirrors effect on the sky.
whitehouse.zip

@AXDOOMER
Copy link
Owner

AXDOOMER commented Apr 19, 2017

Mocha Doom must be limit removing. I believe Maes also wanted to make it Boom compatible, but he hasn't completed and Boom levels may crash the engine.

I believe Mocha Doom should stay limit removing and have Boom compatibility, else there's no way players are even going to use it. They might as well use Chocolate-Doom or PrBoom. Mocha Doom is still "just another port" and today players are looking to play levels with more features, so we loose these potential users if we aim at strict vanilla compatibility. (vanilla is niche)

Mocha Doom aims for demo compatibility, but if we do such emulation (of rendering bugs), it should be optional and turned off by default. A testing feature could also be provided so statistics like the number of visplanes would be shown on the screen, that would compliment the full vanilla emulation very well.

@GoodSign2017
Copy link
Contributor Author

I think exactly the same way. Moreover, alongside with very optional strict emulation support, I would like to see many advanced features implemented. Maybe even ones that can rival major modding source ports. As Java is managed language, a proper implementation of modding support can be very rich on functionality. Just need to choose right architecture.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants