atsb / doom64ex-plus Goto Github PK
View Code? Open in Web Editor NEWAn improved modern version of Doom64EX.
License: GNU General Public License v2.0
An improved modern version of Doom64EX.
License: GNU General Public License v2.0
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!
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
The fmin and fmax on linux is pissing me off after a great cleanup on the code to attempt for loading the config.cfg
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.
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.
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.
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.
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.
This happened once I switched to the nightdive IWAD. Still investigating why.
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.
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?
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.
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
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 :)
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).
Both the sound and music volumes appear to be really quiet, even at max. Using Win64 build.
Seems to have occured at the merge of the fancy new library. I'll debug on Linux later and see where the issue is.
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.
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
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.
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.
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.
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.
add a feature to automatically locate the Doom 64 WAD from steam, or the user can add their game path to a config.
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.
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.
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
This needs to be fixed.
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
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.
The TITLEMAP crashes after about 5 seconds on the Wolfy branch.
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.
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.
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.
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.
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.
This issue is a continuation of issue #99 that now we better think about the opengl itself
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%...
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.
Happens a lot on Ethereal Breakdown. No idea why at the moment.
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.
Moving to GLFW would give us a lot more flexibility on embedded platforms.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.