atsb/doom64ex-plus

An improved modern version of Doom64EX.

Doom 64 EX+

Doom 64 EX+ is a continuation project of Samuel "Kaiser" Villarreal's Doom 64 EX aimed to recreate DOOM 64 as closely as possible with additional modding features.

I have kept the current release and current 'stable' branch as bug-free and stable as possible with every single optimisation, fix etc.. that I could add to it. For Linux and Windows users, this version will be stable and playable and will still give you exceptional usability over EX. However, I cannot devote much time lately and the time I do spend developing outside of my job, I would like to spend on productive projects, rather then on projects that are not used much.

Differences from Kaiser's C++ version of EX on GitHub:

• Support for the IWAD from Nightdive Studios' official remaster. Just so it is clear for everyone (NO IT DOES NOT SUPPORT THE OLD EX ROM DUMP IWAD).

• Support for the Lost Levels campaign

• Support for loading PWADs

• Better performance (especially when compared to Nightdive Studios' official version (which is slow as hell)

• Messages for discovering secret areas

• Support of MAP slots up to MAP40

• The "medkit you REALLY need!" message fix

• Many bugfixes

• KEX - This is pretty much removed. The only remnants are some comments with [kex] and the rendering stuff that is used in later versions. I wanted to keep Doom 64 EX+ very close in format to other source ports for familiarity purposes and for ease of porting code from Erick's DOOM64-RE project.

• NOTE for NVIDIA users, disable vsync from the control panel to fix stuttering. No idea why it only happens on NVidia cards, though I can't say I'm surprised.

• NOTE - for the launcher, you MUST have .NET 6 or higher installed as the launcher was programmed using .NET 6.0 and anything below won't work.

There are a few bugs still present, which I am slowly fixing.

This GitHub repo is the same as: https://sourceforge.net/projects/doom64ex-plus/ but if any contributors wish to help, then GitHub is a better place for it.

Mod Support

For modders wanting to make their mods work with EX+, there are a few things that deviate from ancient EX:

1. DM_START and DM_END tags are used (like the remaster) instead of DS_START and DS_END.
2. G_START and G_END graphics tags aren't implemented (like the remaster).

Instead:

• The first tag for graphics MUST BE called SYMBOLS.
• The last tag for graphics MUST BE called MOUNTC.

They can either be a tag or a graphic. This is due to me not flat-out reading all PNGs in a WAD but instead, to support the official IWAD, I read the content like this to catch all the graphics that EX+ needs from the IWAD.

No other changes are needed.

Where are the PWADs?

Since most EX PWADS would be incompatible with EX+ for many reasons, I have been adapting them one-by-one for use on EX+ You can find them on moddb, just look for the EX+ / EX Plus wads: https://www.moddb.com/games/doom-64/downloads/

Dehacked Support

For modders interested in dehacked for DOOM64EX+, please refer to the 'modding' directory for reference.

Discord server

Dependencies

• SDL3 and SDL3_net
• ZLib
• LibPNG
• FluidSynth
• OpenGL

System Requirements - 32 or 64bit

Linux Single Board Computer

• Raspberry Pi 3B

others may work but are untested

Linux / *BSD Desktop / Laptop

• 1.8GHz Dual Core CPU
• 2GB RAM
• 80MB Disk Space
• OpenGL 2.1+ Or Later Compliant Video Chip / Card

Windows

• 1.8GHz Dual Core CPU
• 4GB RAM
• 80MB Disk Space
• OpenGL 2.1+ Or Later Compliant Video Chip / Card

macOS

• mid-2013 macbook air or better (also arm64 systems)
• 4GB RAM
• 80MB Disk Space
• OpenGL 2.1+ Or Later Compliant Video Chip / Card

Installation

Windows

• Windows does not yet support installing the software, however you are able to manually put the software in any directory of your choosing and it will work fine.

GNU/Linux / BSD

• GNU/Linux and BSD supports system installations using the compile-time macro -DDOOM_UNIX_INSTALL this will force the software to look for all IWAD and supporting files inside ~/.local/share/doom64ex-plus
• compile-time macro -DDOOM_UNIX_SYSTEM_DATADIR=\"/some/system/path\" allows to specify the system folder where the software will look for all IWAD and supporting files. if not specified, it defaults to /usr/local/share/doom64ex-plus. Packagers should set DOOM_UNIX_SYSTEM_DATADIR to a proper folder for the distro and package files doom64ex-plus.wad and doomsnd.sf2 into that folder.

Finally, if a data file cannot be found in one of the two folders above, it will look inside the current directory.

Packaging will not be done by myself, but any contributor is welcome to package the software for GNU/Linux or macOS.

Compiling

Clone this repo

$ git clone https://github.com/atsb/Doom64EX-Plus

Linux

Use the build.sh script for a native build.

macOS

Install it from MacSourcePorts: https://macsourceports.com/game/doom64

Or if you feel adventurous, read below: Install MacPorts and get the dependencies.

Then use the XCode project file, which is the only supported way to compile on macOS. Everything is already defined. The IWAD needs to be placed in: /Users/user/Library/Application Support/doom64ex-plus directory along with the files found within the Resources directory inside the bundle (.wad and .sf2).

Raspberry Pi 3

Use build_rpi3_raspbian.sh for a native build of Raspberry Pi 3B

FreeBSD

Use the build_freebsd.sh script for a native build of FreeBSD

OpenBSD

Use the build_openbsd.sh script for a native build of OpenBSD

Windows

Use the Visual Studio solution and project files provided in the Windows directory of the repository for both 32-bit or 64-bit builds.

Usage

Doom 64 EX+ needs the DOOM 64 asset data files to be present for you to be able to play the game. The data files are:

• DOOM64.wad
• doom64ex-plus.wad
• doomsnd.sf2

Linux, FreeBSD/OpenBSD and Raspberry pi3

You can place the asset data described above into any of the following directories, searched in that order:

• ~/.local/share/doom64ex-plus if compiled with the DOOM_UNIX_INSTALL macro
• the folder specified by the DOOM_UNIX_SYSTEM_DATADIR compile macro, or /usr/local/share/doom64ex-plus if not specified

If data files are not found in these directories, it will search in the current directory.

macOS

You can place the asset data described above to:

• /Users/*user*/Library/Application Support/doom64ex-plus

Then, you can start playing:

$ DOOM64EX+

NOTE for Linux and FreeBSD/OpenBSD users: As of Nov. 5, 2022, the save data is located in the same directory as the Linux executable and not in ~/.local/share/doom64ex-plus. The files can be securely moved into their new place. Note: This assumes you have not compiled the software with the -DDOOM_UNIX_INSTALL

Windows

The asset data files need to be located in the same directory as DOOM64EX+.exe. Then, you can start playing by launching DOOM64EX+.exe (or optionally by using DOOM64EX+ Launcher.exe instead).

doom64ex-plus's Issues

Allow for RPI / Single Board Computers - a scaling system to scale a 320x240 resolution to fullscreen

I think this will make a lot of sense for those playing on a Single Board Computer. Right now it is either to play in a window, use a really small fullscreen resolution or to use a 7" raspberry pi screen.

A more ideal situation would be to allow the window to scale a 320x240 resolution so that it will upscale to fill the full monitor. We would also need to disable the resolution selection for these SBC computers. Then it would provide a very playable default configuration.

Issue: Configuartion file fails to create and load on Ubuntu 22.04LTS

Issue-1.mp4

Textures sometimes don't render at the edges of the screen when using a high fov

Not sure how much of a problem this is for most users, but I've noticed that when I set the FOV in the config file to 120 (my preferred FOV for this game) I have weird visual effects like this. Checked with the default FOV and this doesn't happen.

[Wolfy]Remove useless xbox buttons inside of wad[WIP]

Find a way to remove this guys since it´s crashing the whole game thanks to the kaiser and it´s great idea of implementing SDL_GAMECONTROLLER :)

Fully replace SDL callback with something else for fluidlite

Making this to document and track it. I’ve done as much as I can about the sdl2 callback to fluidsynth but every now and then it crashes the game within the callback.

We definitely should replace it. Maybe with the mus2mid code of chocolate doom? It’s probably the most compatible

Game cannot find pulse

Hi,

I am on Arch Linux and I am getting this error.

./DOOM64EX-Plus: error while loading shared libraries: libpulsecommon-16.1.so: cannot open shared object file: No such file or directory

It seems that it is looking for the library in a different place.

Remove Technical Debt

EX+ has inherited a lot of old crusty code that constitues a huge amount of technical debt. From missing headers that generate warnings to incorrect parameters.

After 3.6.5 is released, this should take priority. Ideally, to reduce the compilation warnings down to the absolute minimum and compile with pedantic enabled. Code quality should also be the highest possible, with clean, correct code.

This would also mean ideally, we would keep pace with the development of SDL3, it would be awesome to have EX+ be one of the first Free Software projects to be using it, the moment SDL3 has a stable release.

All this will be done in the branch technical_debt

N64 filter

I've always planned to get a 3-point filter working with shaders. I haven't gotten around to it yet, but I am open to either internal or external shader support for this. A lot of architecting needs to happen to properly support GLSL vertex shaders.

Volume is really quiet

Both the sound and music volumes appear to be really quiet, even at max. Using Win64 build.

Move strings to external .txt or .xml files to be read

This aids translation ability, currently everything is hardcoded to English. External txt or xml files is probably the most cross-platform way to do this.

Each release seems to almost always break the project

First, regarding the "segmentation fault" error, I tried in other 2 different rigs, and got exactly the same problem. Making them 3 in total then, I must mention that all of them are different brands, different hardware, and even different years of release. So I dare to discard hardware problems.

That was yesterday. Git-cloned today yet again... full of coding errors.
Even very first complain is "build.sh: line 2: HOME unknown command"
Then full of errors which seemingly had to do mainly with the save dir implementation. Or at least the first lines of output.

I'm actually no coder, so I cannot throw points of view regarding coding style or practices. However, and as only thing to suspect, I was taught that factory/unstable systems are meant for testing and experimentation; never for daily drivers.

Perhaps you're an enthusiastic tester of things, and that's actually excellent. However, if you're sharing a project like this one (just posting in a website such as Github and even making a wiki page for usage is "sharing"), could you perhaps also think about all those ones using stable branch systems, and test more before releasing?
With all my ignorance I'm suspecting the different glibc and gcc versions...

"I don't have a Debian Stable installation" What about live systems? That if you find setting up a VM would be too time consuming...

Could we even try locating and asking @svkaiser for some help?

Animating Pallette change

So while Erick fixed a lot of things about animating palette's, the horizontal palette's are broken again and no longer animate (wall palette's, doorframe lights). This is done solely in i_png.c

This whole code is generally a giant pain. It should be replaced with code that will simply read the palette's and allow them to animate normally. It'll need to do this on all platforms and architectures.

Rewrite the launcher from windows api to cross plataform

Collision or missile sprites being 'off'

I noticed this on EtherealBreakdown MAP12, where the laser or missiles or plasma 'disappear' into the walls in very select locations. Apparently this is the only map where this happens because I never noticed before.

No idea if it is a bug I caused due to the vanilla changes or if it is just this map. It doesn't happen on the remaster, so it is either a 'not fully EX+ compatible map or it is a bug.

[Feature request] automatically locate the Doom 64 WAD

add a feature to automatically locate the Doom 64 WAD from steam, or the user can add their game path to a config.

Fix the P_LoadLefs on linux

Sounds Section not found in IWAD

Hello,

Compiled from latest master just an hour ago (Ubuntu) and when attempting to run the DOOM64EX-Plus I get this output:

$ ./DOOM64EX-Plus 
Z_Init: Init Zone Memory Allocator
CON_Init: Init Game Console
G_Init: Setting up game input and commands
M_LoadDefaults: Loading game configuration
WARNING: Unknown Key
I_Init: Setting up machine state.
D_Init: Init DOOM parameters
W_Init: Init WADfiles.
W_AddFile: Adding /home/andy/Desktop/Doom64EX-Plus/src/engine/doom64ex-plus.wad
Error - Sounds section not found in IWAD

********* ERROR *********
Sounds section not found in IWAD%            

Is this an issue with the DOOM64.WAD itself? I generated it using the old Doom64Ex executable with -wadgen on the game rom.

Thank you

Feature request: make non-bindable keys bindable

Currently F1, F2, F5-F7, F11, T and 9 keys are hardcoded to various actions and cannot be rebound. It wold be nice if they could be rebound like any other key.

Also, I don't know if it's worth its own issue, but it would be great if sv_fastmonsters sv_respawn sv_respawnitems sv_nomonsters cvars wouldn't reset back to zero on every launch so it is possible to play with fast monsters without using launcher or command line parameter.

Nintendo Switch does not build properly

I was testing here a shell file of Doom64EX+ and when i just build it´s does not generate nothing looks like i´m gonna appeal to a Makefile

[Wolfy] - Broken Save/Load functionality

This needs to be fixed.

See if we can move to GLFW

Moving to GLFW would give us a lot more flexibility on embedded platforms.

Weapon sprite doesn't center when shooting

This is a small inaccuracy I noticed compared to Remaster/N64 original. Unlike in DOOM 1/2, the sprite in DOOM 64 always snaps back to center during the firing animation and then resumes bobbing when it's done. It's a tiny thing but I could immediately notice something was off when I was shooting the shotgun :D

Shooting switches not working at all

This is basically issue #2 , but I just think it's an issue bigger than we thought...

Shooting switches is essential part of gameplay ever since classic Doom. Let alone the "secrets" stuff, IIRC there are some levels which require this feature to even be clearable (I spent good part of the weekend testing playing through several levels).
And no, the noclip cheat wouldn't necessarily help since not all of them trigger doors, neither can they be activated by pressing the "use" key.
Most clear example that comes to mind now: MAP29.

I already read that you mentioned that you've reviewed the source code several times already, but, couldn't we try giving this another try? I think this would be kind of higher priority...
It was possible to fix the ugly segmentation fault thing when building on "stable" distros, and also there are more contributors. Perhaps there could be better luck this time?

Oh, and small additional side note: it seems that Doom 64 introduced item picking as "secret trigger" as well, and not just the "sectors". However, IIRC, I noticed that, after clearing a map, seemingly only the secret "sectors" are counted...

Thanks again.

64bit clean

Certain parts of the code aren't 64bit clean and will causes issues with tag activations and level warping/exiting if compiled as a 64bit binary. I've done a lot of fixing for this, but there is still much to do.

[Wolfy] - TITLEMAP crashes

The TITLEMAP crashes after about 5 seconds on the Wolfy branch.

[Wolfy] Fix the min and max of linux after a great cleanup

The fmin and fmax on linux is pissing me off after a great cleanup on the code to attempt for loading the config.cfg

"Conflicting types..." errors when running build.sh

Git-cloned just today again; when trying to build with build.sh now I get these errors:

con_console.c:74:15: error: conflicting types for ‘console_inputbuffer’
74 | int8_t console_inputbuffer[MAX_CONSOLE_INPUT_LEN];
| ^~~~~~~~~~~~~~~~~~~
In file included from con_console.c:29:
con_console.h:32:17: note: previous declaration of ‘console_inputbuffer’ was here
32 | extern char console_inputbuffer[];
| ^~~~~~~~~~~~~~~~~~~
con_console.c:117:6: error: conflicting types for ‘CON_AddLine’
117 | void CON_AddLine(int8_t* line, int len) {
| ^~~~~~~~~~~
In file included from con_console.c:29:
con_console.h:44:6: note: previous declaration of ‘CON_AddLine’ was here
44 | void CON_AddLine(char *line, int len);
| ^~~~~~~~~~~
con_console.c:170:6: error: conflicting types for ‘CON_AddText’
170 | void CON_AddText(int8_t* text) {
| ^~~~~~~~~~~
In file included from con_console.c:29:
con_console.h:39:6: note: previous declaration of ‘CON_AddText’ was here
39 | void CON_AddText(char *text);
| ^~~~~~~~~~~
con_console.c:197:6: error: conflicting types for ‘CON_Printf’
197 | void CON_Printf(rcolor clr, const int8_t* s, ...) {
| ^~~~~~~~~~
In file included from con_console.c:29:
con_console.h:40:6: note: previous declaration of ‘CON_Printf’ was here
40 | void CON_Printf(rcolor clr, const char *s, ...);
| ^~~~~~~~~~
con_console.c:213:6: error: conflicting types for ‘CON_Warnf’
213 | void CON_Warnf(const int8_t* s, ...) {
| ^~~~~~~~~
In file included from con_console.c:29:
con_console.h:41:6: note: previous declaration of ‘CON_Warnf’ was here
41 | void CON_Warnf(const char *s, ...);
| ^~~~~~~~~
con_console.c:229:6: error: conflicting types for ‘CON_DPrintf’
229 | void CON_DPrintf(const int8_t* s, ...) {
| ^~~~~~~~~~~
In file included from con_console.c:29:
con_console.h:42:6: note: previous declaration of ‘CON_DPrintf’ was here
42 | void CON_DPrintf(const char *s, ...);
| ^~~~~~~~~~~
con_cvar.c:63:9: error: conflicting types for ‘CON_CvarGet’
63 | cvar_t* CON_CvarGet(int8_t* name) {
| ^~~~~~~~~~~
In file included from net_server.h:27,
from d_net.h:33,
from doomstat.h:30,
from con_cvar.c:28:
con_cvar.h:88:9: note: previous declaration of ‘CON_CvarGet’ was here
88 | cvar_t *CON_CvarGet(char *name);
| ^~~~~~~~~~~
con_cvar.c:109:6: error: conflicting types for ‘CON_CvarSet’
109 | void CON_CvarSet(int8_t* var_name, int8_t* value) {
| ^~~~~~~~~~~
In file included from net_server.h:27,
from d_net.h:33,
from doomstat.h:30,
from con_cvar.c:28:
con_cvar.h:86:6: note: previous declaration of ‘CON_CvarSet’ was here
86 | void CON_CvarSet(char *var_name, char *value);
| ^~~~~~~~~~~
con_cvar.c:137:6: error: conflicting types for ‘CON_CvarSetValue’
137 | void CON_CvarSetValue(int8_t* var_name, float value) {
| ^~~~~~~~~~~~~~~~
In file included from net_server.h:27,
from d_net.h:33,
from doomstat.h:30,
from con_cvar.c:28: 

I did run an update in Debian Bullseye; gcc version is 10.2.1. Not sure if this is related...

Also, is custom save directory still into consideration?

Thanks again.

For underterminated time

I tried to fix the linux build on the every form, every way, even punch into the wall 200 times per day and no results so yeah this time unfortunally i give up on this one.

[Optional]Remove SDL_GetPath for open function

Music Still Desyncs

I probably should've mentioned this sooner, but I noticed while listening to the intro music, there is a clear desync on the notes, especially with the main melody.

i_w3 library fails to work on Linux, BSD and macOS

Compilation errors, and after fixing, a new error is below:

********* ERROR *********
R_InitSprites: Sprite PLAY frame A has rotations and a rot=0 lump

Unfortunately, all code must be compatible with all 5 supported Operating Systems (Including Intel and M1 macOS systems). Currently, the build is broken on anything that is not Windows.

I think this should be looked at again.

Fix opengl on other platforms

Sometimes enemy sprites get stuck or don't appear after reloading a save game

Happens a lot on Ethereal Breakdown. No idea why at the moment.

Add a better way to support Doom64EX+ for other platforms

This issue is a continuation of issue #99 that now we better think about the opengl itself

[Fixed] [Stable] Missing reference on A_

Saving/Loading is broken

Seems to have occured at the merge of the fancy new library. I'll debug on Linux later and see where the issue is.

Continue with the support of android :D

Error - W_Init: IWAD not found

Git-cloned today; finally built.

But now, when running, having put DOOM64.wad in corresponding place beforehand, I only get this:

Z_Init: Init Zone Memory Allocator
CON_Init: Init Game Console
G_Init: Setting up game input and commands
M_LoadDefaults: Loading game configuration
I_Init: Setting up machine state.
D_Init: Init DOOM parameters
W_Init: Init WADfiles.
Error - W_Init: IWAD not found

********* ERROR *********
W_Init: IWAD not found

I already tried putting all files, including the binary, in:
$XDG_DATA_HOME/doom64ex-plus
The directory DOOM64EX-Plus binary was built
Other directories

I also checked the checksum for the DOOM64.wad, and is correct.

What could be happening here?
Thanks again.

Remove dboolean and use bool where appropriate

I fixed the console because of this, however there are hundreds of instances of dboolean where there should be either a bool and an int (depending on what it is used for).

Sometimes a dboolean function will not return a real boolean but an integer value because dboolean is mapped to an int. This needs to be cleared up and tested.

This issue is to track this change.

Switch xinput to SDL_GameController

Remove useless / problematic entries in setup

EX+ should be simple and easy to configure with no settings that can drastically break or interfere with a wad's intended look and feel. Some settings break the visual / gameplay dynamic the author's intended.

All settings except:
Jumping
Mouse Aiming
Monster Height

Will be removed.

• This also includes the N64 compatibility settings, which will be restored to exactly how they were in vanilla.
• Lost souls will be limited to prevent possible crashing on lower-spec systems with unlimited lost souls.
• Setup will be renamed Configuration

For the purpose of a stable and reproducible configuration for PWAD author's, this is vitally important. Giving the user so many options to break the experience just causes issues for those author's.

This is not up for discussion.

"Segmentation fault" error when trying to run

It seems I'm cursed regarding this thing...

Z_Init: Init Zone Memory Allocator
CON_Init: Init Game Console
G_Init: Setting up game input and commands
M_LoadDefaults: Loading game configuration
WARNING: Unknown Key
I_Init: Setting up machine state.
D_Init: Init DOOM parameters
W_Init: Init WADfiles.
W_AddFile: Adding /home/user/Downloads/Doom64EX-Plus/doom64ex-plus.wad
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon.
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: cHRM chunk does not match sRGB
libpng warning: Interlace handling should be turned on when using png_read_image
P_Init: Init Playloop state.
NET_Init: Init network subsystem.
S_Init: Setting up sound.
fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable
fluidsynth: error: Failed to create PulseAudio connection
WARNING: I_InitSequencer: failed to create audio driver
D_CheckNetGame: Checking network game status.
ST_Init: Init status bar.
GL_Init: Init OpenGL
GL_VENDOR: Intel Open Source Technology Center
GL_RENDERER: Mesa DRI Intel(R) HD Graphics 4000 (IVB GT2)
GL_VERSION: 3.0 Mesa 20.3.5
GL_MAX_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_UNITS_ARB: 8
GL Extension: GL_ARB_multitexture = true
GL Extension: GL_EXT_compiled_vertex_array = true
GL Extension: GL_ARB_texture_env_combine = true
GL Extension: GL_EXT_texture_env_combine = true
GL Extension: GL_EXT_texture_filter_anisotropic = true
Segmentation fault

I have libfluidsynth2 2.1.7 installed; I don't have pulseaudio installed but apulse instead.
Inxi info about GPU:

Display: server: X.Org v: 1.20.11 driver: X: loaded: modesetting
  unloaded: fbdev,vesa gpu: i915 resolution: 1366x768~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 4000 (IVB GT2)
  v: 4.2 Mesa 20.3.5 direct render: Yes

EDIT:
Installed PulseAudio; now instead of this part:

fluidsynth: error: Failed to create PulseAudio connection
WARNING: I_InitSequencer: failed to create audio driver

I get this one:

fluidsynth: Using PulseAudio driver
WARNING: CVar s_soundfont doesn't point to a file.
Found SoundFont /home/user/Downloads/Doom64EX-Plus/doomsnd.sf2
fluidsynth: warning: Failed to set thread to high priority
fluidsynth: Sample 'SFX_008' has no flags set, assuming mono
fluidsynth: Sample 'SFX_022' has no flags set, assuming mono
[...]
fluidsynth: Sample 'SFX_123' has no flags set, assuming mono
fluidsynth: warning: No preset found on channel 9 [bank=128 prog=0]

What's wrong with this setup?
Thanks yet again beforehand.

Making Doom64EX-Plus work with ALSA

During the tests I made just today I noticed that I needed to install Pulseaudio for sound and music to work. Otherwise, both were totally absent, and also console output said these things:

fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable
fluidsynth: error: Failed to create PulseAudio connection

Do you think it could be possible to make Doom64EX-Plus to work with ALSA as well, or with the "ALSA Pulseaudio emulator" Apulse?

Thanks very much again.

Cannot build x64 executable with Visual Studio solution

It fails on linking for functions new_fluid_audio_driver and delete_fluid_audio_driver. I've attempted using latest fluidsynth release 2.3.0 but that failed to link across the board (not just 2 functions).

Black flashing on certain textures

This happened once I switched to the nightdive IWAD. Still investigating why.

Improve performance on lower-end hardware

So one thing I've noticed, especially on one of my low-end dev laptops, is that in certain situations in some levels with a lot of monsters and projectiles, the performance drops to single figures. Even when using such resolutions as 1366x768 or even 720p. It is especially noticeable when using Plasma projectiles such as the plasma rifle or BFG.

This must be improved. Other source ports, even software rendered ones run on such systems at a rock solid framerate. The same must happen here, there is likely a bottleneck somewhere.

Error running build.sh: gl_main.c: fatal error: wglext.h No such file or directory

Using Debian 11.

Installed all dependencies listed in the README, and when running build.sh I get aforementioned error, even though I already installed all packages providing such header.

The error pops with red letters, nevertheless process goes on for a brief while until suddenly halting shortly after with exit code 1.

Also tried copying it to src/engine directory.

Also, the previous Linux builds don't work neither because they demand a glibc version newer than what current stable branches use: the builds demand at very least version 2.32, when currently used version in distros in general is 2.31...

Could you help? Thanks.

"Secret items" not being counted

I know I mentioned earlier that the item picking "secret triggers" were now functional, but I think this was not the case.

Or at least not totally: I realized that at that moment I was testing on the skill level 2. When getting back to skill level 4, "secret items" were not being counted, albeit "secret sectors" still did.

So could it be that it depends on skill level? A quite good way to test is MAP10, where all the secrets are items rather than sectors.

Thanks again.

EDIT: perhaps the perfect map to test this issue is MAP14: it has only one secret, and it's an item. Yet secret count is 8%...

How to convert original dumped ROM to WAD?

A while ago there used to be a kind of converter from original dumped ROM to a WAD Doom64EX-Plus can read. Is this still possible? Can this be natively done on Linux?

And additionally, could it be possible to customize the save data location? So instead of $XDG_DATA_HOME/doom64ex-plus, telling it to save within doom64ex-plus directory itself or somewhere else.

Thanks again.

Error - W_GetNumForName: BUTTONS not found!

I am getting the following error when I press on any main menu entry.
I am on Windows 10 22H2, DOOM64.WAD is from GOG version.

Z_Init: Init Zone Memory Allocator
CON_Init: Init Game Console
G_Init: Setting up game input and commands
M_LoadDefaults: Loading game configuration
WARNING: Unknown Key
I_Init: Setting up machine state.
D_Init: Init DOOM parameters
W_Init: Init WADfiles.
W_AddFile: Adding D:\Games\DOOM 64\doom64ex-plus-3.6.5.2-win64\doom64ex-plus.wad
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon.
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: cHRM chunk does not match sRGB
libpng warning: Interlace handling should be turned on when using png_read_image
P_Init: Init Playloop state.
NET_Init: Init network subsystem.
S_Init: Setting up sound.
Found SoundFont doomsnd.sf2
D_CheckNetGame: Checking network game status.
ST_Init: Init status bar.
GL_Init: Init OpenGL
GL_VENDOR: NVIDIA Corporation
GL_VERSION: 4.6.0 NVIDIA 391.35
GL_MAX_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_UNITS_ARB: 4
GL Extension: GL_ARB_multitexture = true
GL Extension: GL_EXT_compiled_vertex_array = true
GL Extension: GL_ARB_texture_env_combine = true
GL Extension: GL_EXT_texture_env_combine = true
GL Extension: GL_EXT_texture_filter_anisotropic = true
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: cHRM chunk does not match sRGB
Error - W_GetNumForName: BUTTONS not found!

********* ERROR *********
W_GetNumForName: BUTTONS not found!