Doom64EX 2.3 Feedback Thread

NOTE: This build is a work-in-progress and will be updated periodically. This is NOT an official release but rather consider this an 'alpha' test build. I want to be absolutely sure that there won't be any major bugs present before I make this release official.

The release of version 2.2 was pretty embarrassing and version 2.3 will be resolving just about all of those bugs and other issues that was present in 2.2.

Changes:

* Complete overhaul of the zone memory allocator. This replaces the old zone heap system that Doom used
* Memory corruption fix due to some things being given the MF_NOBLOCKMAP flag
* Fixes to sky due to front face culling
* Sprites are properly culled and disable culling for laser sprites
* Fixed pixel pack-alignment when taking screenshots or saving savegame thumbnails while in a widescreen resolution
* Different logic when setting music and sound volumes
* Out Gain cvar added for tweaking the overall gain output in Fluidsynth
* Support for 65534 sidedefs and segs
* Fixed buggy cameras in co-op mode
* Fixes to Regional menu. Now displays 'Unavailable' if user doesn't have a localized version of the game
* R_GLRegisterProc no longer errors out when failing to find a OpenGL extension address.
* Fixed issue where it was failing to validate non-US versions of the IWAD
* Include Microsoft Visual Studio runtime library (MSVCR71.DLL)
* Wadgen will check for existing files and remove them before generating new ones
* Fix in Wadgen for converting MIDI data. Some bytes of data were lost during conversion resulting in incomplete tracks

Download Link Last Updated: 03/18/12: http://dl.dropbox.com/u/18609/Kex_Engine.zip

Because that there was a fix in converting the MIDI data, I suggest you re-run wadgen to create a fresh new IWAD and Soundfont file.

Please report any bugs or feedback relating to this test build here. Happy bug hunting!

Sorry, haven't gotten to try the last couple versions yet, and this may not be the best thread to post this question in. But, has the recent versions added general windows gamepad support like for logitech dual action gamepads? I thought I remembered that there was xbox gamepad support, but that's it.

Zdoom supports universal gamepads very well. Especially how you can map both analog sticks as well as the d-pad.

If the latest svn checkout of the 2.2 branch in your svn repository is 2.3(I think it is as it was the most recently committed to according to websvn) it runs absolutely perfectly in Arch Linux x64. Do note that CMakeLists.txt needs some changes because libdl and libm aren't being included automatically. I had to modify CMakeFiles/doom64ex.dir/link.txt to include -ldl -lm at the end to get it to link properly.

Other than that though, runs fantastically :) Great work

Yeah, I didn't plan that one through. I should of branched way after I did the first initial release of 2.2. I'll be branching later this week though.

Also can you provide me that updated CMakeList file?

Brewtal_Legend said:

has the recent versions added general windows gamepad support like for logitech dual action gamepads?

D64EX still supports the xbox 360 controller. I would implement support for generic PC gamepads but I've found that there's a conflict with the direct input driver and XInput, making it difficult to support both.

Very nice - this works on my MX440!

If you're in game and press F2 to save
-the options menu fades in, fades out anf then comes the save slot screen.

Great work overall!

So.. I downloaded it, noticed the DOOMSND.SF2 file, and could not help myself from throwing it into PrBoom-Plus and playing some other wads with that sound font. Shit sounds creepy as fuck listening 'Doom64ified' versions of songs I know already.

I'll get around to actually playing Doom 64 EX a bit later though, haha.

_bruce_ said:

If you're in game and press F2 to save
-the options menu fades in, fades out anf then comes the save slot screen.

Cool, I'll have that addressed shortly.

Sorry for the wait, I have patch for CMakeLists.txt to fix the linking issue:

http://pastebin.com/fhTFMVE4

MP2E said:

Sorry for the wait, I have patch for CMakeLists.txt to fix the linking issue:

http://pastebin.com/fhTFMVE4

Awesome, I'll patch it once I get the chance.

Whoops I'm new to cmake syntax and it seems I made a mistake in the patch, change ELSEIF(UNIX) to ELSE.

Should work as intended now.

I managed to find this

http://code.google.com/p/x360ce/

Which lets me use my logitech dual action gamepad to play.

I noticed that in classic control mode, the turning on the right stick is very slow if the threshold is set to anything but completely to the left.

Don't know if it's intentional, but I thought I'd mention it.

Also, is there any chance of adding gamepad config? Instead of only being able to choose between classic or modern control scheme. I like to use left stick for forward/back and strafing, use the right stick for turning, and the d-pad for looking up and down with another button configured to center the view. It would be nice to configure the controller to do this.

I was running doom64ex using the Doom Runner front end ( http://sourceforge.net/projects/doomrunner/ )and noticed I can't get any sound. I could have sworn that the sound worked fine the first time I tried it, but not now. I even made the program load the doomsnd.sf2 but still no sound.

Also, there is no sound when punching a wall.

Think there might be a way to add blood splatter on the walls when killing enemies like in PC Doom? I know it wasn't that way in Doom 64, but it would be a nice extra option.

Brewtal_Legend said:

Think there might be a way to add blood splatter on the walls when killing enemies like in PC Doom? I know it wasn't that way in Doom 64, but it would be a nice extra option.

It's not "like in PC Doom". Decals were introduced by Doom Legacy, and then ZDoom.

Gez said:

It's not "like in PC Doom". Decals were introduced by Doom Legacy, and then ZDoom.

I guess it's just been so long since I played vanilla Doom without gzdoom that I forgot and assumed the decals were always there. It would still be a nice optional feature for d64ex though I think. The dark grittier atmosphere is just begging to have blood splattered on the walls. :P

ZDoom's decals are horrid looking (and not in a good way).

Brewtal_Legend said:

I guess it's just been so long since I played vanilla Doom without gzdoom that I forgot and assumed the decals were always there. It would still be a nice optional feature for d64ex though I think. The dark grittier atmosphere is just begging to have blood splattered on the walls. :P

I can put that on my to-do list but the whole point of version 2.3 is to eliminate all bugs that was responsible for the disastrous 2.2 release. After that, then D64EX is open for new feature requests and what not.

Random suggestion, is it possible to have an option for "Use Context" that shows the little Use key popup without highlighting the wall texture? Because it is apparently getting sent over network in co-op mode (I think?).

Yikes. I'll have to make that local to the client then...

-The load snapshot gets distorted and is black and white.



-In the 'options/video' menu the 'Anisotropy' setting shows '00D' when I start the .exe and is corrected to on/off when changed via keys.


-are you considering the dirty solution of incorporating a hack to make deathmatch possible/abusing the standard spots for it?
Obvious solution would be deathmatch spots in the map files - so maybe a patchfile per original map distributed with the release for a cleaner solution?

Is this with the very latest version?

Also I am not sure about deathmatch support. I think I took out some deathmatch components when I was struggling to get co-op support to work. But since I am lacking free time, maybe someone could help add support for this (either by code or by map patches).

I think Quake 2 had to do something similar where it manually added co-op starts via code to maps that lacked them.

Kaiser said:

Is this with the very latest version?

Also I am not sure about deathmatch support. I think I took out some deathmatch components when I was struggling to get co-op support to work. But since I am lacking free time, maybe someone could help add support for this (either by code or by map patches).

I think Quake 2 had to do something similar where it manually added co-op starts via code to maps that lacked them.

Hi Kaiser, any chance you could release the DS port you were talking about a while ago please? Am going to be spending a lot of time on the train soon... :)

_bruce_ said:

-The load snapshot gets distorted and is black and white.
http://i.imgur.com/toIn1.png

That one is easy to solve. I had to fix that in the screenshot code in GZDoom some times ago. You need to call

glPixelStorei(GL_PACK_ALIGNMENT, 1);

before taking the snapshot, and then once it is taken call

glPixelStorei(GL_PACK_ALIGNMENT, 4);

to return to normal for performances purposes.

The problem happens when image widths aren't a multiple of four. Here the resolution for the snapshot appears to be 341x256.

Since the image data isn't aligned on four bytes, when you read the renderbuffer's pixels to store them in a picture, you get out of alignment visually. So you have to tell it to use a 1-byte alignment. But it is apparently costly for performances, so you want to return to the default of 4-byte alignment once you've finished reading the pixels.

@Kaiser - you're correct.
The save/load picture issue was incorrectly reported by me because it was an old savegame... maybe there's something odd in the stimpaks I've been using lately. ^^
The Quake2 map hack was the first thing that crossed my mind when writing the post... funny mind jump.
Tried downloading the DoomEx source via SVN but it doesn't work and the tar-ball never finishes.
I can't guarantee to be of any help but if I'm able to provide something useful I'll see to it.
On a different note - on what is the movement code in DoomEX based? I've played a few maps over the last days and movement seems so "against" the player unlike in the original Doom.
Other than that DoomEX is the bomb - I had a blast, yet again, revisiting the levels of Nintendo's purgatory.


@Gez - those pesky packing... reminds me of my first bmp loader where I was totally overloaded by every line width having to be evenly dividable by 4.

Convex said:

Hi Kaiser, any chance you could release the DS port you were talking about a while ago please? Am going to be spending a lot of time on the train soon... :)

I am hoping to. Still lacking a lot of things (such as new graphics for the lower screen) but other than the menu, I think its close to release.

Just haven't been working on it because of work and uh... TurokEX...

_bruce_ said:

On a different note - on what is the movement code in DoomEX based? I've played a few maps over the last days and movement seems so "against" the player unlike in the original Doom.

Friction has been slightly changed and the sliding code was slightly tweaked to prevent the wall running bug that boosts the player's momentum. Both of these were based off of the disassembly I've gathered from the original game.

I know I'm a little behind the times, but I just grabbed v2.3 because I felt inclined to play some Doom64.

When was the video option for 1280x1024 screens dropped, and why? Surely I can't be the only person still in 5:4 land. Trying to force it in the config file doesn't have any effect. Is there some glaringly obvious way of fixing this that I'm missing?

Its an oversight on my part because I never knew 5:4 even existed. I am only checking for resolutions with the 4:3, 16:10 and 16:9 ratios. So basically I need to add support for that aspect ratio....

There's also another ratio common on netbooks: 1024x600. Using nice numbers ZDoom/ECWolf approximates this to 17:10, but you could use a more exact ratio if you want. Toshiba also released a laptop with a 21:9 screen @ 1792x768.

This might be helpful...

Isn't standardisation a wonderful thing. :/