Coder Social home page Coder Social logo

svkaiser / doom64ex Goto Github PK

View Code? Open in Web Editor NEW
231.0 30.0 48.0 12.67 MB

Doom64EX is a reverse-engineering project aimed to recreate Doom64 as close as possible with additional modding features.

Home Page: http://doom64ex.wordpress.com/

License: GNU General Public License v2.0

C 9.68% C++ 87.06% CMake 2.83% Ruby 0.18% Shell 0.01% Roff 0.17% Vala 0.07%

doom64ex's Introduction

Doom64EX Build Status Build status

Doom64EX is a reverse-engineering project aimed to recreate Doom64 as close as possible with additional modding features.

NOTICE 2nd February 2017 The supplementary data file kex.wad has been renamed to doom64ex.pk3.

Installing

At the moment there are no official binary builds. You can find older versions here.

Compiling

It's possible to compile Doom64EX yourself. Officially, only Linux, Windows and macOS are supported. Patches for alternative operating system are gladly accepted, however.

Dependencies

Ubuntu 14.04 Fedora 24 Arch Linux / MSYS2* on Windows Homebrew on macOS
C++14 compiler g++-6 gcc gcc Xcode
CMake cmake cmake cmake cmake
SDL2 libsdl2-dev SDL2-devel sdl2 sdl2
SDL2_net libsdl2-net-dev SDL2_net-devel sdl2_net sdl2_net
zlib zlib1g-dev zlib-devel zlib zlib
libpng libpng-dev libpng-devel libpng libpng
FluidSynth** libfluidsynth-dev fluidsynth-devel fluidsynth N/A

* MSYS2 uses a naming convention similar to the one utilised by Arch, except packages are prefixed with mingw-w64-i686- and mingw-w64-x86_64- for 32-bit and 64-bit packages, respectively.

** FluidSynth is optional. The fluidsynth-lite fork can be used instead.

Note: You may also need to install dynamic libraries separately.

Using the system-provided FluidSynth library

Doom64EX uses fluidsynth-lite to reduce the number of dependencies. If you wish to use FluidSynth as provided by your package-manager, add -DENABLE_SYSTEM_FLUIDSYNTH=ON as a cmake argument.

$ cmake -DENABLE_SYSTEM_FLUIDSYNTH=ON ..

Compiling on Linux

All of these steps are done using the terminal.

Prepare the Dependencies

On Ubuntu:

$ # Add additional toolchains
$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test
$ sudo apt update

$ # Install GCC
$ sudo apt install build-essential gcc-6 g++-6

$ # Install dependencies
$ sudo apt install git cmake libsdl2-dev libsdl2-net-dev zlib1g-dev libpng-dev

On Fedora:

$ # Install development group
$ sudo dnf groupinstall "Development Tools and Libraries"

$ # Install dependencies
$ sudo dnf install git cmake sdl2-devel sdl2_net-devel zlib-devel libpng-devel

On Arch Linux:

$ # Install dependencies
$ sudo pacman -S git gcc cmake sdl2 sdl2_net zlib libpng

Clone and Build

Find a suitable place to build the program and navigate there using cd.

$ # Clone this repository (if you haven't done so already)
$ git clone https://github.com/svkaiser/Doom64EX --recursive
$ cd Doom64EX

$ # If you have previously cloned the repository, you'll need to also grab the fluidsynth-lite submodule
$ git submodule update --init --recursive

$ mkdir build       # Create a build directory within the git repo
$ cd build          # Change into the new directory
$ cmake ..          # Generate Makefiles
$ make              # Build everything
$ sudo make install # Install Doom64EX to /usr/local

You can now launch Doom64EX from the menu or using doom64ex from terminal.

NOTICE Ubuntu ships with a severely outdated version of CMake, so you'll need to create the doom64ex.pk3 file manually.

Compiling on Windows

Download and install CMAKE. Follow the instructions on the website and make sure to update the system. Clone the repository in a suitable place to build the program.

Next, download the Win32 Dependencies. Extract the archive into the extern directory. Also remember to clone fluidsynth-lite and generate the .lib and .dll files. Place these in extern\lib and extern\bin, respectively.

Next, generate the MSVC project files.

$ mkdir build                           # Create a build directory within the git repo
$ cd build                              # Change into the new directory
$ cmake .. -G "Visual Studio 15 2017"   # Generate MSVC 2017 files

Visual Studio 2017 project files will now be sitting in the build directory.

Compiling on macOS

Install Xcode for its developer tools. Follow the instructions to install Homebrew. You can probably use other package managers, but Doom64EX has only been tested with Homebrew.

Open Terminal.app (or a terminal replacement).

$ # Install dependencies
$ brew install git cmake sdl2 sdl2_net libpng zlib

Find a suitable place to build the program and navigate there using terminal.

$ # Clone this repository (if you haven't done so already)
$ git clone https://github.com/svkaiser/Doom64EX --recursive

$ # If you have previously cloned the repository, you'll need to also grab the fluidsynth-lite submodule
$ git submodule update --init --recursive

$ mkdir build       # Create a build directory within the git repo
$ cd build          # Change into the new directory
$ cmake ..          # Generate Makefiles
$ make              # Build everything
$ sudo make install # Install Doom64EX.app

You will now find Doom64EX in your Applications directory.

Creating doom64ex.pk3

If for some reason CMake refuses to automatically generate the required doom64ex.pk3, you can easily create it yourself.

Data Files

The data files required by Doom64EX to function are:

  • doom64ex.pk3 (Generated by cmake)
  • doom64.wad
  • doomsnd.sf2

To generate the two latter files, acquire a Doom64 ROM and run:

$ doom64ex -wadgen PATH_TO_ROM

This will generate the required files and place them somewhere where Doom64EX can find them.

Doom64EX needs the Doom 64 data to be present in any of the following directories.

On Linux and BSDs

  • Current directory
  • The directory in which the doom64ex executable resides
  • $XDG_DATA_HOME/doom64ex (usually ~/.local/share/doom64ex)
  • /usr/local/share/games/doom64ex
  • /usr/local/share/doom64ex
  • /usr/local/share/doom
  • /usr/share/games/doom64ex
  • /usr/share/doom64ex
  • /usr/share/doom
  • /opt/doom64ex

On Windows

  • Current directory
  • The directory in which the doom64ex executable resides

On macOS

  • Current directory
  • ~/Library/Application Support/doom64ex

Community

Official Blog

Forum

Discord

You can join the official IRC channel #doom64ex on irc.oftc.net (OFTC).

doom64ex's People

Contributors

alexey-lysiuk avatar alice-mkh avatar faxdoa avatar haleyjd avatar kamikazow avatar kmg1 avatar manuel-k avatar mdeguzis avatar nvllsvm avatar pinkwah avatar ryan-sg avatar shockwavenn avatar skyehdd avatar svkaiser avatar tatsh avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

doom64ex's Issues

Reversed condition in P_ScanSights

The comparison at

// must have longer tics
should be testing != 1 instead of == 1, which matches the GAS assembler in Jaguar Doom as well as a second look at the Doom 64 assembly:

li $s3, 1
...
lw $t7, mobj_t.tics($s0)
nop
bne $s3, $t7, loc_8001EB98

The side effect of this error is that monsters with chase states of 1 tic in duration may become docile after losing sight of a player that has not attacked them after waking up by seeing him, as their subsequent sight checks will be rejected. I am not sure if this fits any Doom 64 monsters (the cacodemon was affected in the Calico project).

Cyberdemon doesn't predict the player's position when it fires its third rocket

Last time a played, two years ago, I found out that the cyberdemon didn't predict the player's position when it aimed its third rocket. This is something that's done in Doom 64 and it's very nice. It makes the cyberdemon an even more formidable opponent. I wasn't able to do anything about it since I thought the project was dead.

Crashes with Segmentation Fault in Ubuntu 16.10

I'm not an expert on compiling programs from source. I'm compiling this code on a pretty stock install of Ubuntu 16.10. However, the game is unplayable because it frequently crashes with a "Segmentation Fault"!

Is Ubuntu 16.10 the problem? I'm willing to change distros. What should I do?

Incorrect monster's death / count

  1. Sometimes after death of Zombieman (Shotgun?) his sprite remains standing in the same place forever. These kill not added to kills counter, not allowing you to get 100% kills in a level.
    Happens only 2 times for entire playtrough for me.
  2. More often happened that Lost Souls is not count (without any sprite in map, tested it with cheats).

In "Map 17: Watch Your Step" I closed exactly 1 Lost Soul that stayed after Pains Elements in center room. I looked on automap with cheat: LS still was in the room. Then I closed the automap and walked in level for a dozen of seconds and opened map again - LS disappeared. And i was not able to do exactly 1 kill for 100% kills, there was not any more enemies in map (tested again with cheats).

I am really not sure, but for me looks like only LS from Pain Elementals affected by this bug.

Happens ~6 times per playthrough.
Used build from https://doom64ex.wordpress.com/

Issue on map29 outpost omega

I'm running Doom64 EX on a gentoo, with the latest git from nov 25.
I had to create the wad and SF2 file using d64ex 2.5 with wine, which loaded correctly however.

There however seems to be an issue in one of the secret maps, particularly "Outpost Omega (map29)".
There is a certain shootable trigger on this map that will spawn the unmaker in the so called "yellow room".

link to a let's play on original hardware with the particular secret : https://youtu.be/sDDg4QYfYM8?list=PL4109CAF34427E32E&t=617

The button is there, but won't active by shooting it or activating it normally. I've checked out the rom used to create the wads in mupen64plus and it does indeed work in mupen64plus.
If I check out other LP's using d64ex they however get it to work. I could attempt to compile & run it through wine to see if it's this particular version that's causing it.

edit: using wine and Doom64EX 2.5 from Kaisers' wordpress site using the same resources I can get the unmaker using that trigger.
When I openend up a savegame that I made in the level on the windows version, it worked as well. I was able to trigger the switch without issues.

Load Game screen crash with recent commits

With the recent commits just made, Doom64ex crashes when going to load game screen. I'm on Arch Linux and my full system specs are in my steam profile, which is linked in my GitHub page. I'll post the error from the terminal when I get home from work.

Should not read non-Doom64 EX savegames

Currently any file named *.dsg will be read even if it wasn't created by Doom64 EX. This sometimes results in crashes, and frequently in the display of garbage, if people have placed D64EX in the same folder with another Doom source port.

Trouble building on Debian 8

Details:

This project builds and links with the manual steps in the readme, but the build system choices here don't work with dpkg-buildpackage

[ 83%] Building C object src/engine/CMakeFiles/doom64ex.dir/system/i_system.c.o
/build/doom64ex-0.20160530+git+bsos/src/engine/system/i_system.c: In function 'I_Printf':
/build/doom64ex-0.20160530+git+bsos/src/engine/system/i_system.c:680:5: error: format not a string literal and no format arguments [-Werror=format-security]
     printf(buff);
     ^
cc1: some warnings being treated as errors
src/engine/CMakeFiles/doom64ex.dir/build.make:1779: recipe for target 'src/engine/CMakeFiles/doom64ex.dir/system/i_system.c.o' failed
make[4]: *** [src/engine/CMakeFiles/doom64ex.dir/system/i_system.c.o] Error 1
make[4]: Leaving directory '/build/doom64ex-0.20160530+git+bsos/Build'
CMakeFiles/Makefile2:207: recipe for target 'src/engine/CMakeFiles/doom64ex.dir/all' failed
make[3]: *** [src/engine/CMakeFiles/doom64ex.dir/all] Error 2
make[3]: Leaving directory '/build/doom64ex-0.20160530+git+bsos/Build'
Makefile:117: recipe for target 'all' failed

What could be going wrong here?

Script breakage with the kexplus merge?

It seems like when you load a saved game, it doesn't really seem to load the script sequences correctly.

For example the first map, the last open room has a light that "circles" around the room. However, when you save and load the game, only 1 sector lights up, and the rest just stay dark.

https://youtu.be/t2n7opbewVg?t=198
This isn't my video but that is the room I'm talking about.

EDIT: Hmm, the crusher sequence when you grab the soulsphere in hectic however does seem to trigger and continue just fine when you load up a saved game. Might be something else at play here.

No sound after "unstable" merge

I updated my git branch ,but specifically since commit 10eb9f1 (Merge remote-tracking branch 'origin/unstable') the sound doesn't want to work. I use pulseaudio on my desktop, and I can see no registration of a audio stream, whereas the older ones, with the exact same config just works. (well, almost the same config, seeing as it no longer is stored in ~/.doom64ex/)

startup log from new version : http://pastebin.com/7t5n9gSe
startup log from old version : http://pastebin.com/jVwncQRu

I tried setting it to another output method with the following results :

oss nags about /dev/dsp being in use, which is correct, and seeing as I have no hardware mixing available is expected,
alsa doesn't give me sound either (neither does it register an audio stream, which it should because default audio is routed through pulseaudio),
file generates a file in the root folder called fluidsynth.raw but has nothing really of any value in it, and is only a couple bytes big.

running the engine through a wrapper like padsp also results in no actual audio stream being registered, even though the "in use" errors in the startup log disappear.

I'm not really sure where to start looking first because that commit is quite a big one, but I'll see what I can come up with.

[Feature request] Green blood toggle regardless of ROM version used

It'd be cool if there were a red-or-green blood toggle that enables a recoloring of the blood sprites to match their appearance in the Japanese version, similar to the violence level options in Turok 1 and 2. Kaiser says the sprites are the same between versions, but are just recolored, so this could be replicated by providing a separate palette. Likewise, a ROM built from the Japanese version could provide a red palette for red blood mode.

CMake build scripts are outdated?

When doing a fresh git clone and trying to build, I got this error during the cmake process.

The kexlib Cmake files apparently expect the folder to be there, but it's either not committed or the files are outdated?

[cmake stuff]
-- Found Threads: TRUE
CMake Error at src/kexlib/CMakeLists.txt:61 (file):
file COPY cannot find "/GuntherDW/src/git/Doom64EX/data/kexlib_test".

-- Found SDL2: /usr/include/SDL2 (found version "2.0.4")
[more cmake log]
-- Configuring incomplete, errors occurred!
See also "/GuntherDW/src/git/Doom64EX/build/CMakeFiles/CMakeOutput.log".
See also "/GuntherDW/src/git/Doom64EX/build/CMakeFiles/CMakeError.log".

Trying to launch doom64ex on Debian 8 - segmentation fault

Data is in /usr/share/games/doom64ex after conversion.

error:

Z_Init: Init Zone Memory Allocator
CON_Init: Init Game Console
G_Init: Settting up game input and command
M_LoadDefaults: Loading game configuration
I_Init: Setting up machine state
D_Init: Init DOOM parameters
W_Init: Init WADfiles
Segmentation fault

Does this mean my ROM and/or ROM conversion to .wad was bad? The conversion method does not allow .bin ROMs either.

Game stalls at end of level stats screen

Until I alt+tab out of it. It does not matter if it is the normal exit or the secret level exit. If I enable "screen melt", I even have to alt+tab before the melting starts.

Before I spend time investigating – does this happen for anybody else? Or is it this crappy laptop?

Missing CMakeList

When compiling, I get an error about the CMakeList missing. I'll post the error message after work.

Build instructions for Windows

I've been trying pretty much all night to build this source on Windows to no avail, using multiple VC versions but nothing seems to work. It's just errors on errors on errors.

Which VC should I be using, and where should I put the external dependencies so CMake actually sees them?

Thanks!

Demo recording/playing

  1. Recording works, but when I complete the level, I get "Error - Demo .lmp recorded" instead of intermission, which makes determining the time impossible. (Okay, not impossible, but watching the automap is not the best solution.)
  2. I can only record a single level, don't have ability to record multi-level demos.
  3. When I playing the demo, the HUD doesn't displayed.

Wadgen not working with newer libpng

Some textures have a weird number of palettes. Each palette contains 16 colours and a few textures use either 5 or 9 (80 and 144 colour totals, respectively), but try to fit it into a 4-bit-per-pixel png.

Likely culprit: /src/engine/wadgen/wad.c#Wad_AddOutputTexture

Segmentation Fault 11 trying to enter Hectic

I initially posted this issue in Alexey Lysiuk's Doom64EX OS X build, but they suggested to post it here:

I used the secret exit in "Staging Area" to proceed to the level "Hectic." I was shown the text informing me I'd found Hectic (though the screen did not melt beforehand), but when I clicked to proceed, the game crashed. Using Terminal, I discovered the application underwent "Segmentation fault 11" when trying to transition. I attempted to use lldb to further diagnose the problem, but that wound up forcing me to restart my computer. Curiously, using the normal exit from "Staging Area" to "The Terraformer" worked just fine. Maybe it has something to do with Hectic's unusual level transition (there's no after-level stats screen; it goes straight to the intro text)? I'm including my crash log: doom64ex_2016-05-29-164020.txt

"Only the best will reap its rewards" indeed. ;)

Issues with CMake build system

As response to #15 I decided to create standalone Doom64EX build environment for OS X.
However a few issues are still preventing me from finishing it:

  1. kexlib depends on libpng, at least png.h must be available. However if I don't have it somewhere in default search paths, kexlib will fail to build. Although the main executable target doesn't have this problem and locates libpng correctly.
  2. The same target has a quite strange statement for a static library:
    target_link_libraries(kexlib m png). In fact this affects executable that is linked with this library. But what if libpng library is named differently, like libpng16.a in my case? I think this statement should be removed and replaced with proper libpng dependency, similar to the main executable target.
  3. The main executable target tries to search for FluidSynth headers inside FLUIDSYNTH_INCLUDE_DIRS. However the corresponding CMake file doesn't provide this variable but it provides FLUIDSYNTH_INCLUDE_DIR (without S at the end) instead.

I can make a pull request with fixes however I have very limited abilities to test on other platforms. Moreover 1. and 2. can be fixed in various ways.

[Enhancement] Linking to Linux builds or using buildbot

I'd love to help out providing Debian/Ubuntu/Fedora etc. packages. I already build a lot for SteamOS, but I am familiar with rpm/mock a bit and for Debian flavors, pbuilder. I have my own repository at http://packages.libregeek.org. I am also curious about buildbot and am looking into that soon. Thoughts? Sorry if I should have sent an email to @dotfloat instead.

Build error on Debian 8 Jessie

Build using Clang 3.8

[ 93%] Building CXX object src/engine/CMakeFiles/doom64ex.dir/zone/z_zone.cc.o
/build/doom64ex-0.0.0+git20170102.3989543/src/engine/zone/z_zone.cc:359:23: error: arithmetic on a pointer to void
        memset(result + origsize, 0, size - origsize);
               ~~~~~~ ^
1 error generated.
src/engine/CMakeFiles/doom64ex.dir/build.make:2270: recipe for target 'src/engine/CMakeFiles/doom64ex.dir/zone/z_zone.cc.o' failed
make[4]: *** [src/engine/CMakeFiles/doom64ex.dir/zone/z_zone.cc.o] Error 1
make[4]: Leaving directory '/build/doom64ex-0.0.0+git20170102.3989543/build'
CMakeFiles/Makefile2:179: recipe for target 'src/engine/CMakeFiles/doom64ex.dir/all' failed
make[3]: *** [src/engine/CMakeFiles/doom64ex.dir/all] Error 2
make[3]: Leaving directory '/build/doom64ex-0.0.0+git20170102.3989543/build'
Makefile:127: recipe for target 'all' failed

Log: http://sprunge.us/WbhO

Crash on startup

With config.cfg OS X build of Doom64EX crashes for me at startup with the following call stack:

libGL.dylib`glTexEnvi + 20
doom64ex`GL_SetColorScale + 135 at gl_main.c:359
doom64ex`CvarCmd_r_colorscale(cvar=...) + 17 at r_main.c:97
doom64ex`CON_CvarSet(var_name="r_colorscale", value="0") + 229 at con_cvar.c:177
doom64ex`CMD_Seta(data=0, param=...) + 70 at g_game.c:284
doom64ex`DoRunActions(al=..., free=1) + 193 at g_actions.c:243
doom64ex`G_ExecuteCommand(action="seta \"r_colorscale\" \"0\"") + 39 at g_actions.c:532
doom64ex`G_ExecuteMultipleCommands(data=...) + 295 at g_settings.c:81
doom64ex`G_ExecuteFile(name=...) + 350 at g_settings.c:123
doom64ex`G_LoadSettings + 139 at g_settings.c:141
doom64ex`M_LoadDefaults + 9 at m_misc.c:282
doom64ex`D_DoomMain + 98 at d_main.c:982
doom64ex`main(argc=1, argv=...) + 89 at i_main.c:537
doom64ex`start + 52

The reason of the crash is a lack of OpenGL context (which is created later I think).

TurokEX

I am quite sorry, but I did not knoe how else to contact you. Will you ever return to this project? I've been trying my earnest to build it on Linux

Incorrect saving of total sercrets for some levels

For some reason the game incorrectly saves a total number of secrets and it is incremented after each save by the same specific value for a level. So you can not achieve 100% if saved in this levels.

For example, in map6 you have 3 total secrets. If you saved and then loaded - the game starts thinking that it is 5. If you saved again, after loading the game start thinking that total secrets is 7 for this level.

I tested every level, the bug 100% happens in these levels for me:
Map 06 - +2 (3, 5, 7, 9)
Map 10 - +7 (7, 14, 21, 28)
Map 11 - +2 (4, 6, 8, 10)
Map 14 - +1 (1, 2, 3, 4)
Map 29 - +4 (6, 10, 14, 18)
Map 30 - +1 (2, 3, 4, 5)

All other maps are without this bug.

Mouse completely broken on all Windows 10 systems with Fall update.

View snaps back to starting position the moment mouse stops moving. Cannot turn or aim subsequently. I've tested this on many machines, present on all Win 10 systems with Fall update. Compatibility mode has no effect. Basically unplayable. Forum suggested nightly build in post 5 has working mouse but no sound. https://www.tapatalk.com/groups/doom64ex/doom-64-ex-mouse-not-working-t219.html?sid=d173a9fd7f00a641098335e71cb5daa6#p40003790

Crash on level intermission screen

In the options->settings menu, if you set texture fit forcibly to "scaled" and exit a level, it'll crash at gl_ResampleTexture. More specifically by checking at the crashlog it's crashing on the "EVIL" texture.

I'm just winging it but it looks like the ratios look a bit wonky. It resamples it to 256*256, and crashes in that method.
What's weird is that even though I compiled with debugging symbols enabled, gdb mentions one of the inWidth/inHeight to be "". But that might just be because of my compiler. I'm using GCC 5.3.0-gentoo (gcc (Gentoo 5.3.0 p1.0, pie-0.6.5) 5.3.0)

Terraformer sounds incorrect

There should be a fireball swoosh sound at each impact after activating the terraforming machine on MAP02; it is inaudible for some reason (audio channel limits?)

Linux x64: No crosshairs.

The crosshairs section is stuck in the 'off' position in the menu. Setting via console yields no result either.

W_Init: IWAD not found

I have iwads installed:

$ ls -la /usr/share/games/doom64ex
celkem 13812
drwxr-xr-x 2 root root    4096  1. pro 16.42 .
drwxr-xr-x 5 root root    4096  1. pro 16.39 ..
-r--r--r-- 1 root root 5429302  1. pro 16.42 DOOMSND.SF2
-r--r--r-- 1 root root 8671208  1. pro 16.42 DOOM64.WAD
-rw-r--r-- 1 root root   27069  1. pro 16.39 kex.wad

Still get error:

$ doom64ex 
Kexlib_Init: Init kexlib
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

Linux x64: Screen melt effect missing.

The screen melt effect doesn't render when enabled. Instead, there is a brief pause when the effect should have started, and then the game resumes at the time the effect should have ended.

Wadgen fails if run on a ROM in the current directory when run over SSH

With doom.z64 in PWD:

doom64ex -wadgen doom64.z64 
...
Writing IWAD File...
ERROR: File_Open: Couldn't create doom64.z64/doom64.wad

In another directory:

mkdir output_wad && cd output_wad
doom64ex -wadgen ../doom64.z64 
...
Sucessfully created ../doom64.wad
Writing Soundfont File...

Sucessfully created ../doomsnd.sf2

Probably something to do with XDG_DATA_HOME not being set on my VPS. It may be nice to have a fallback if this scenario occurs. Just something I noticed.

Launcher source missing

This is a peculiar omission

(long story short i was hoping to rip off the launcher to quickly prototype an OA launcher)

"Illegal Instruction 4" when attempting to run in OS X 10.11.5

When I attempt to run the Mac port of Doom 64 EX version 2.4 in the Terminal, this is what I get:

Z_Init: Init Zone Memory Allocator
CON_Init: Init Game Console
G_Init: Setting up game input and commands
M_LoadDefaults: Loading game configuration
G_GetConfigFileName: using config file '/Users/XXXXXXX/.doom64ex/config.cfg'
I_Init: Setting up machine state.
Illegal instruction: 4

EDIT: I've also included the complete crash report:
doom64ex_2016-05-25-223716.txt

According to this "Illegal instruction" means the binary contains instructions my OS does not understand. I've tried using the fix described in that link, adding "-mmacosx-version-min=10.x" to the command, with progressively lower and lower values for x, but to no avail.

For reference, I am running Mac OS X El Capitan (10.11.5) on a mid-2010 13" MacBook Pro. I have a 2.4 GHz Intel Core 2 Duo processor, 4 GB 1067 MHz DDR3 RAM, and an NVIDIA GeForce 320M 256 MB graphics card.

This is apparently an issue that afflicts other OS X users according to these topics. It wouldn't be so bad if we knew what Doom 64 EX's current status is. Your last post on the subject was just over two years ago, where you said version 2.6 would be available sometime that month, and the Dropbox link for the pre-release is currently broken. Otherwise, I could at least use Wineskin to run the Windows executable (2.5 prevents me from saving unless the game is set to a 4:3 aspect ratio).

Your last post in general was on December 15, 2015, and the silence is unbearable. Please, at least let us know the status of the project. It would be enough to know some kind of timeline, even if actual updates are a ways off.

Levelstats get "mangled" after a save/load.

Whilst playing I noticed that even though I got all of the secrets, it didn't count it as 100% all of the time.
After a while I noticed that saving and loading after getting a secret in a map changes the amount that doom64ex thinks is in the map.
This is easiest to demonstrate in MAP11: Terror core. There is a secret berserk pack right behind you at the start of the level.
Before saving it then says I got 1/4 secrets, which is correct. However, after I save and load that save, it says I have 1 out of 6 secrets.

Screenshot before loading the savegame : http://wrongplace.be/files/d64ex/BeforeSavingAndLoading.png
Screenshot after loading the savegame (notice the secret amount going up) : http://wrongplace.be/files/d64ex/AfterSavingAndLoading.png
I'm not entirely sure but I think this can happen to the other counters as well.

Please tag pre-file move and rename revision

I need to be able to browse the source tree from a revision that predates every file being moved to subfolders and being renamed to .cc; github's interface will not allow this because it's too limited to understand git file moves. Please create a tag (or several) that points to some of these revisions so that the source history is browsable.

load/save game seg.faulting

after a fresh compile and beating a few levels, I tried to save my game. it appeared to seg.fault immediately. after poking around, i found it created a file in ~/.doom64ex but it contains no data. when trying to load a saved game, it instantly segfaults. I discovered if I copied my one empty save game file to fill the extra "slots" creating 0 through 7, the load game menu now works, but seg.faults upon loading what appears to be garbage data.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.