Doomsday Engine

The doom64 plugin has been kept around and compiles fine, but likely needs plenty of fixing.

Some notes about the plugin, for those that are interested:

I have forcibly made the plugin to accept the 33-Map (rather than 38-Map) IWAD, as even generating a WAD from a ROM.

That aside, here's what is working.

• Menu music seems fine

• Font works

• Skull icon for selected item works, is animated

• Menu logo textures work

What's not behaving:

• The engine skips alot of patch files, complaining that the corresponding maps do not exist

• FPV Weapon sits visibly above the bottom of the screen. This is only noticeable with a non-opaque status bar, and is also present under the same conditions when D64 resources are loaded in to doom2 and played (not that you should do this, many things will not work, and are not meant to work).

• Missing lumps

• Slider textures are borked

• Save game slots appear to be missing backgrounds

• There are colour inconsistencies between menu prompts and menu items

• Reloading the game results in GUI_ShutDown calling `free` on an invalid pointer

• In-game music is horrifyingly not music. If testing, it is highly advisable, that, unless working on music, you mute the ingame music.

• Logging to the OSD appears to cause a segmentation fault. For example, picking up an item results in this call chain: `P_TouchSpecialMobj (libdoom64) > P_SetMessage (libdoom64) > UILog_Post (libdoom64) > Z_Realloc (in libdeng_legacy) > [ memcpy implementation ]`. For me, `memcpy implementation` is `__memcpy_sse2_unaligned`. However, I am unsure whether this is SSE-specific or not -- I will look in to this. As it stands, this is the most breaking issue I have yet to encounter.

Code Things:

• A method borrowed from jHexen is used when firing the lazer weapon (this is indicated in the source code)

• There are a lot of magic numbers/ambiguous values in the plugin code marked only as 'jd64' or '64tc' without any explanation as to the purpose

• While the plugin is far from feature complete, it shares a very large amount of code with the jDoom plugin. it should probably be investigated whether or not some kind of code sharing could be done, if possible. I do not, however, think that jDoom64 should merge in to jDoom as there are too many significant modifications to make that possible.

• Some C files need conversion to CPP, and need some logic cleanup and auditing, also.

I have attached a screenshot at the main menu with a portion of the warnings shown, not for debugging purposes, but simply for anyone interested in seeing the TC WAD loaded.

I think it is good to be clear that the current Doom 64 plugin is completely based on the Doom 64 TC, so this issue should be about repairing and updating the code to work with modern Doomsday. The end result is an up-to-date version of the Doom 64: Absolution plugin.

There is a separate line of work regarding the creation of a new, more accurate Doom 64 plugin (#2023), although that work is not yet even started.

I think there is a case to be made for having a plugin for both the Doom 64: Absolution TC and the "real" Doom 64 emulation. The former is a matter of fixing what already exists, while the latter is a major effort involving writing new code and taking care of possible Boom/MBF dependencies.