nukeykt / pcdoom-v2 Goto Github PK

I found other differences between Doom 2 (alternative Final Doom executable) and PCDoom.

cfg is displayed instead of SB.

The other is status 0 10 0 0, I wonder what this means.

int seq and int vol are inverted in DMX.H. This doesn't match how it is used in DMX.C in the declaration of the function where the function is defined. This doesn't change how the code behaves.

The offending line: https://github.com/nukeykt/PCDoom-v2/blob/master/DMX.H#L37

You can quickly compare with SFX_SetOrigin which has the seq and vol parameters in the good order.

Starting MAP01 will crash DOSBox with the following error:

Illegal write to ffffffff, CS:IP      160:  1b49b0
Exit to error: Illegal descriptor type 0 for int 8

Vanilla Doom would exit with the following error message: I_Error ("R_DrawPlanes: visplane overflow (156)

WAD: http://www.doomworld.com/idgames/levels/doom2/deathmatch/Ports/s-u/shdwpit

You forgot to add your copyright in this file.

https://github.com/nukeykt/PCDoom-v2/blob/master/r_things.c

This bug isn't fixed in PCDoom-v2: nukeykt/pcdoom#4

The message will display unless I set memsize in DosBox to at least 5.

Vanilla Doom doesn't display the "insufficient memory" message when memsize=4.

The mem command is DosBox may be useful if you want to do tests.

At 4mb, mem will display:

On Alien Vendetta MAP19, where you would get a visplane overflow with the original Doom 2 executable, you get memory read or sometimes memory write errors instead in PCDoom.

Sometimes I get an overflow as high as 153 in Doom 2, but in PCDoom looks like the memory is trashed before the engine can do anything to detect the overflow.

When I got a memory write error, it was at address ffffffff. The screen can also be corrupted and it will appear as columns which are offset (vertically shifted). This always causes a lockup, which is not always immediate in the case where it's just reading memory.

PCDoom doesn't show that it's calling DMX_Init like the original doom2.exe.

Even though I tested with doom2.exe that comes with Doom 2: Hell on Earth, I can confirm that it's the same with Final Doom.

Would it be possible to add an option in the makefile to compile PCDoom v2 as C only, without any assembly? That way only Open Watcom would be needed and not tasm, as in PCDoom v1.

This would mean no joystick support and C versions of R_DrawColumn and R_DrawSpan (the ones from v1) surrounded by "#ifdef C_ONLY" when compiling with pure C, and probably adding back m_fixed.c.

Thanks.

i tried to build with DosBox, OpenWatcom and TASM5. I get a linking error message:

"Name must come first"

I suspect I don't have the right compiler/assembler. What version are needed?

In ASS, there is a way to play PC Speaker sounds from a MUSE format. It's in the source code file PCFX.C.

In Apogee games, the PC Speaker sounds were stored in an AudioT file. The sound data is stored in a format called Inverse Frequency Sound Format, which is the direct ancestor of Doom's PC Speaker sound format.

A document describing the reverse engineered PC Speaker sound format can be found here. All it needs is a conversion to the Inverse Frequency Sound Format before it's sent to ASS to be played.

A file called ULTRAMID.INI is created in the exe's directory when the game runs with the music device GUS. Vanilla Doom doesn't do this.

The music doesn't sound quite right (like some channels not playing, and the ones that play, sound different). You can test this hearing the music from the first demo in Vanilla and pcdoom. The music volume bar also doesn't seem to be working correctly (the music appears to start at full volume but the bar is at the middle, so when you move the bar, you notice a sudden drop of volume).

I'm trying to build it with the IDE and it doesn't work. I got some problems with undefined references. I don't want to use the makefile. I want to do it easy by building with the project open in the IDE.

pcdoom_build_log.txt

When I select Gravis Ultra Sound in setup and play, then I can hear the sound being weird like if it was played twice almost over each other. It's like some echo.

I get this message when I try to start a game. I'm using doom1.wad v1.9 (shareware).

When playing with the release executable, I noticed that the music plays at the maximum volume although I set the music volume lower.

Here's my DEFAULT.CFG, you can see my SFX volume and music volume are very low. I tried with GUS and General Midi and I get the same bug. If I move the music slider in the F4 menu, then the music becomes played at the supposed volume. Maybe it's an initialisation problem which always set the music volume to an arbitrary value?

mouse_sensitivity		9
sfx_volume		2
music_volume		5
show_messages		1
key_right		77
key_left		75
key_up		17
key_down		31
key_strafeleft		30
key_straferight		32
key_fire		29
key_use		57
key_strafe		56
key_speed		54
use_mouse		1
mouseb_fire		0
mouseb_strafe		1
mouseb_forward		2
use_joystick		0
joyb_fire		0
joyb_strafe		1
joyb_use		3
joyb_speed		2
screenblocks		10
detaillevel		0
showmessages		1
comport		1
snd_channels		16
snd_musicdevice		5
snd_sfxdevice		3
snd_sbport		544
snd_sbirq		7
snd_sbdma		1
snd_mport		-1
usegamma		0
chatmacro0		"no macro"
chatmacro1		"no macro"
chatmacro2		"no macro"
chatmacro3		"no macro"
chatmacro4		"no macro"
chatmacro5		"no macro"
chatmacro6		"no macro"
chatmacro7		"no macro"
chatmacro8		"no macro"
chatmacro9		"no macro"
		0

Running PCDoom-v2 with doom1.wad doesn't work, the error message is:

W_GetNumForName: M_EPI4 not found!

Which refers to a lump the shareware doesn't have.

Starting with a demo doesn't crash:

C:\PCDOOM2>DOOM.EXE -timedemo demo1

I got some MIDI files in a WAD and they get converted to MUS when playing Doom, so the music system plays them. If they are too large, they cause memory errors. A MUS file has a 64K limit.

PCDoom will play them without problem.

Warp through map01 to map09. https://ufile.io/4a5c9
Not every of them will cause errors because some are smaller than 64K.

This is what I get when I select HELP.

https://github.com/nukeykt/PCDoom-v2/blob/master/p_pspr.c#L47

A line has // but there is not comment. This was probably added by mistake, because it's not in the PCDoom-v1 source code.