Chocolate Doom

It's just a PWAD file, so:

3 hours ago, Master O said:

chocolate-hexen -iwad hexen.wad -file hexdd.wad

On 5/17/2018 at 12:20 AM, fraggle said:

It's just a PWAD file, so:

 

Thanks for clarifying.  Also, I noticed something else involving Hexen's CD music files.  When ripped to FLAC using EAC, the SHA-1 hashes do not match the hexen-music.cfg file found here https://github.com/chocolate-doom/music-packs/blob/master/hexen-music.cfg.  The hashes below are ripped directly from my Hexen CD via EAC 1.1 to FLAC:

12ace25ef66716a0d55a60def8814c2a7598f6be = hexen-music/hexen02.flac   # level  2 (jachr)
34cb9019ab715738ac2a8a8720ad9338a3bbc367 = hexen-music/hexen03.flac   # level 26 (blechr)
8806a434f4d6a9ce8deb1cd260702fed515cdc45 = hexen-music/hexen04.flac   # (hexen)
940d8485a3eae94c6869c1211e8f0ac403747f14 = hexen-music/hexen05.flac   # (orb)
8a21ef2a70be75f9c28b9f975c372b2c21fbb32d = hexen-music/hexen06.flac   # level 10 (fubasr)
17f1d1f6f794c984114851d2e5d3914e585bd04d = hexen-music/hexen07.flac   # (chess)
5d6c952979f3983aa0a8e0a53ccebdd9f6ef7e08 = hexen-music/hexen08.flac   # level 24 (cryptr)
d651e241148e8c9031dec18daad72e6d6e8b33d1 = hexen-music/hexen09.flac   # level  5 (falconr)
f5bff729995a15b2821894b1dd048442321c0c89 = hexen-music/hexen10.flac   # level 36 (octor)
b9fe1a8b8f91656f6de3bd5fd3099b35ce3e7568 = hexen-music/hexen11.flac   # level 37 (rithmr)
8d5d88a5e1c7962b41488b3c413b25bac395f63c = hexen-music/hexen12.flac   # level 22 (sixater)
d56ef31ede8155d9a5b425cf26ed2d1fc17b0edc = hexen-music/hexen13.flac   # level  1 (winnowr)
650f8900d862bd3b248ff986f7b71b303a91d982 = hexen-music/hexen14.flac   # level  8 (swampr)
c895decd31a578abeac9fec38800d85f12da859d = hexen-music/hexen15.flac   # level  4 (wutzitr)
8a89c888d2476604b2abc0392a2a7ea270c23b3d = hexen-music/hexen16.flac   # level 35 (bonesr)
027229c7e09cc916a5523e3c970af131c873b31d = hexen-music/hexen17.flac   # level 28 (chap_1r)
35a5e1667928805e95c1dce7a5d9c9bb08aa9f1e = hexen-music/hexen18.flac   # level 31 (chap_4r)
9c5fd7d413acb6f9e60c9cfeff8640209cd3877a = hexen-music/hexen19.flac   # level 25 (fantar)
e40b0ea83316809b65318df6d08f17b90954e63a = hexen-music/hexen20.flac   # level 21 (foojar)
d05a4a39543b6ebcc5d778ef8fcf0b5fd16316f2 = hexen-music/hexen21.flac   # level  6 (levelr)
6a1efb4e8ca5169ed451134c51887fa7d5db42ee = hexen-music/hexen22.flac   # level  3 (simonr)

The hashes are of the IWAD lumps. They're not supposed to match the flac files.

The link for the bleeding edge builds in the OP is broken.

Fixed, thanks.

Nice little video of a civilian downloading the Chocolate Doom source and wrangling with it.

1 hour ago, Linguica said:

a civilian

That's an amusing choice of word.

Chocolate Hexen
Strange behavior when press F12 spy key: in a single player game and when playback/recording single player demo - engine resets the player to the beginning of the map, only in netgame modes F12 work correctly. I see this problem on the Chocolate Hexen 2.3.0 and also on a very old version from 2010. Need check the operation of F12 spy key on the current version of the engine, I can not check it myself.
 

Check it against vanilla's behavior and/or report it on the issue tracker.

Why is it that Bytefence keeps detecting Chocolate Doom 3.0.0 having Trojan.VBChinky? (I downloaded Chocolate Doom from Github.)

Considering Bytefence is most commonly installed and associated with adware, and thus anything it says might as well be considered a lie, not using Bytefence would be the obvious solution to your problem.

And yes, it's most assuredly a false positive. There's no chance any sort of trojan has embedded itself into the github release.

21 hours ago, Edward850 said:

Considering Bytefence is most commonly installed and associated with adware, and thus anything it says might as well be considered a lie, not using Bytefence would be the obvious solution to your problem.

And yes, it's most assuredly a false positive. There's no chance any sort of trojan has embedded itself into the github release.

Thanks, I was suspecting that before I wrote the report but I asked anyway just to be sure.

On 13 июня 2018 г. at 11:19 PM, chungy said:

Check it against vanilla's behavior and/or report it on the issue tracker.

Of course, Hexen 1.1 is checked first, although I remember it well. I realized that this: in choco Hexen now works by default the map development mode. As far as I can see, the DevMaps command itself and this mode was thrown out from the choco Hexen source, but in mn_menu.c -> MN_Responder() - check F12 key has remained as part of this function, therefore it now works in all modes except the netgame. It is necessary to remove F12 check from MN_Responder(), it is not needed at all, in my opinion. F12 spy key should work only in netgame coop / coop demos, that now works normally, in single player / demo modes - spy key should not work completely.
 

Is there any possibility for non-smooth (aka nearest) scaling and no sound interpolation in the future?

... unless it is technically possible in the current version, but I don't know how :P

Chocolate Doom doesn't use smooth scaling so I don't know what you're talking about. Have you confused it with a different port?

I guess he means our "linear" upscaling into the intermediate texture.

16 hours ago, fabian said:

I guess he means our "linear" upscaling into the intermediate texture.

Yes, this. Sorry for the misunderstanding.

Phrasing confused me. If you really want linear scaling you can get it by setting max_scaling_buffer_pixels to 64000 in chocolate-doom.cfg.

I know my issue was last posted back in february of last year, but I am having that STBAR error again. This time, I am trying to mod doom 2 and then turn it into an IWAD. All I have really changed so far is the HUD.

why can I not start chocolate doom?

edit: nevermind had files in the wrong area.

I made a thread about this a few days ago because I thought I was having a problem specific to Chocolate Hexen, but I now realize it's also affecting Chocolate Doom. Basically, right now both of them immediately crash a few seconds after booting into the main menu. It's usually right when the demonstration starts up, or a few seconds after I start playing the game. The setup exes for both of them crash after running for a few seconds too.

This is happening for both Chocolate Doom 3.0.0 and Chocolate Hexen 3.0.0 which I downloaded from the downloads page at the wiki. I'm running both on Windows 10. The Hexen iwad is from Steam and the Doom iwad is from GOG. The weirdest thing is that I'm also running both on another system I have that's running the same version of Windows 10, and both of them run fine there. I keep checking for differences in the installation on each system. On the system where they're both not working I've installed both ports totally fresh, on the other I've been playing them a while and probably did some stuff to the cfg but can't remember what exactly. I even tried copying the entire Chocolate Hexen installation from the computer where it works to the one where it isn't, and I get the same result. I also tried launching from PowerShell but I get the same result. I've tried installing on the C drive and other drives but that doesn't seem to have any effect.

I've got a small problem with chocolate-doom running on a Sun Ultra 5 (360MHz ultrasparc ii system). OS is currently Debian 7.1. 

I compiled SDL2, SDL2_mixer and SDL2_net from source. I made sure I fulfilled all the dependencies (even the optional ones) for things like sndsamplerate etc. Chocolate-doom also compiled fine.

First issue I ran up against was that my system uses an ATI Rage pro graphics chipset. The 3d core is practically non-existent and SDL2 had built around an openGL library which was software rendered. This made the chocolate-doom-setup program glacially slow, just selecting a menu item was painful. Chocolate-doom itself was also glacially slow, but the terminal output suggested that I was using a software openGL renderer (i.e bad idea). Fixing chocolate-doom was easy, I just forced software rendering in the config file. Fixing the setup menu was more complex - I recompiled SDL2 using the --disable-video-opengl --disable-video-opengles and --disable-video-vulkan flags (i.e. build without 3d support). This just left the X11 driver. Now everything moved smoothly and the game ran.

I then decided to try out the audio. Turning on sound effects works fine (slight system slowdown, but nothing I can't handle). The music is a different story. Even loading into the game (before the chocolate-doom graphical window appears) becomes painfully slow. The sound audio is very choppy and the framerate is basically measured in frames per minute. I also get the occasional alsa buffer overrun error. Googling the buffer error suggests tweaking the pulseaudio buffer chunk size/quantity. I tried this but it made little/no difference.

I've also got the same problem with scummvm. Works fine with just effects, music slows it down to a crawl.

Anyone got any ideas of what to do from here? Would recompiling SDL2 to diasable pulseaudio/alsa improve things (i.e. force OSS)? I would really like to get music going so I can get the full doom experience on this thing!

7 hours ago, 3pcedev said:

I've got a small problem with chocolate-doom running on a Sun Ultra 5 (360MHz ultrasparc ii system). OS is currently Debian 7.1. 

 

I compiled SDL2, SDL2_mixer and SDL2_net from source. I made sure I fulfilled all the dependencies (even the optional ones) for things like sndsamplerate etc. Chocolate-doom also compiled fine.

 

First issue I ran up against was that my system uses an ATI Rage pro graphics chipset. The 3d core is practically non-existent and SDL2 had built around an openGL library which was software rendered. This made the chocolate-doom-setup program glacially slow, just selecting a menu item was painful. Chocolate-doom itself was also glacially slow, but the terminal output suggested that I was using a software openGL renderer (i.e bad idea). Fixing chocolate-doom was easy, I just forced software rendering in the config file. Fixing the setup menu was more complex - I recompiled SDL2 using the --disable-video-opengl --disable-video-opengles and --disable-video-vulkan flags (i.e. build without 3d support). This just left the X11 driver. Now everything moved smoothly and the game ran.

 

I then decided to try out the audio. Turning on sound effects works fine (slight system slowdown, but nothing I can't handle). The music is a different story. Even loading into the game (before the chocolate-doom graphical window appears) becomes painfully slow. The sound audio is very choppy and the framerate is basically measured in frames per minute. I also get the occasional alsa buffer overrun error. Googling the buffer error suggests tweaking the pulseaudio buffer chunk size/quantity. I tried this but it made little/no difference.

 

I've also got the same problem with scummvm. Works fine with just effects, music slows it down to a crawl.

 

Anyone got any ideas of what to do from here? Would recompiling SDL2 to diasable pulseaudio/alsa improve things (i.e. force OSS)? I would really like to get music going so I can get the full doom experience on this thing!T

Think I actually have answered my own question. Chocolate-doom is using an OPL-PCM conversion (emulating the adlib). This is sucking up a huge amount of CPU which is in short supply in my system. My options are now limited to no music (easiest) or obtain a sound card that has midi capability (and works with the sparc). Tried an SBLIVE today; turns out the DMA doesn't play nice with the architecture....

Also here's a crummy picture just to prove it works...

Interesting report, thanks for sharing.

It's a very old machine so I'm not too surprised that OPL emulation is eating up the CPU. You might try using Timidity playback instead, that might play a bit faster. Sound card with MIDI support might work, but don't look for OPL ones - the SPARC doesn't have the CPU instructions needed to talk to hardware OPL.

You're not the first to experience Chocolate Doom's OPL slowing the game down on a slow machine so I filed this bug to add a warning message.

Chocolate Heretic
Function P_FindNextHighestFloor in p_spec.c contains an error: in an unusual situation, when other->floorheight == height or other->floorheight < height - the taged floor starts to move high into space, trying to reach the defined value INT_MAX. In vanilla Heretic floor in this unusual situation remains at current height and does not move anywhere.

I found this moment when recorded a vanilla demo on another engine and tried playback it on Chocolate Heretic 2.3.0, demo go to desync on Chocolate Heretic precisely because of an error in this function. As an option, it is possible to add this condition from Chocolate Doom:

I think this will fix the situation, but I'm not sure, it's probably better to use a full copy of P_FindNextHighestFloor from Chocolate Doom or another solution. I can not use github guys, for me it is possible to give information only here, if it is necessary for project.
 

Yes PVS, you're right. The code in Chocolate-Doom has been changed from the original code. Good find.

Original code for those who can't use GitHub:

//==================================================================
//
//	FIND NEXT HIGHEST FLOOR IN SURROUNDING SECTORS
//
//==================================================================
fixed_t	P_FindNextHighestFloor(sector_t *sec,int currentheight)
{
	int			i;
	int			h;
	int			min;
	line_t		*check;
	sector_t	*other;
	fixed_t		height = currentheight;
	fixed_t		heightlist[20];		// 20 adjoining sectors max!
	
	for (i =0,h = 0 ;i < sec->linecount ; i++)
	{
		check = sec->lines[i];
		other = getNextSector(check,sec);
		if (!other)
			continue;
		if (other->floorheight > height)
			heightlist[h++] = other->floorheight;
	}
	
	//
	// Find lowest height in list
	//
	min = heightlist[0];
	for (i = 1;i < h;i++)
		if (heightlist[i] < min)
			min = heightlist[i];
			
	return min;
}

I noticed that this is a modified Heretic function, which removes the original 20 sectors limit. I've already tested the options: if add simple condition if(!h) or full copy of P_FindNextHighestFloor from Chocolate Doom - in both cases the function works equally well and returns 'currentheight' for such non-standard situations, which are associated with small errors in the mapping, of course. But I see such situation already on 2 maps now, where Chocolate Heretic works incorrectly while Heretic 1.3 no have problems.

It is absolutely incredible coincidence, but today when testing something else on another engine - I saw a warning from Heretic P_FindNextHighestFloor about 21 sectors in floor raise action, I remember the comment in your Doom source that the critical number of sectors is 22, if more - original engine crash. It became interesting to check this, I started to add sectors in the editor and check the work on the vanilla Heretic. My result for this map is 24 sectors, the engine is working fine, 25 or more - crash. Maybe someone will be interested in this information.
 

2 hours ago, PVS said:

I noticed that this is a modified Heretic function, which removes the original 20 sectors limit. I've already tested the options: if add simple condition if(!h) or full copy of P_FindNextHighestFloor from Chocolate Doom - in both cases the function works equally well and returns 'currentheight' for such non-standard situations, which are associated with small errors in the mapping, of course. But I see such situation already on 2 maps now, where Chocolate Heretic works incorrectly while Heretic 1.3 no have problems.

It is absolutely incredible coincidence, but today when testing something else on another engine - I saw a warning from Heretic P_FindNextHighestFloor about 21 sectors in floor raise action, I remember the comment in your Doom source that the critical number of sectors is 22, if more - original engine crash. It became interesting to check this, I started to add sectors in the editor and check the work on the vanilla Heretic. My result for this map is 24 sectors, the engine is working fine, 25 or more - crash. Maybe someone will be interested in this information.
 

The original code and the limitation is bizarre: Store all of the encountered heights, just to find the lowest. It wastes time and memory, requires a second iteration, possibly overflows the array, and creates a hard-coded limit... all of which is completely unecessary, and more complicated than calculating within the first iteration!

id wrote this code just as quickly as possible, I think.

kb1
We have been sitting for almost 20 years now, drinking coffee and quietly analyzing each variable and line of code and sometimes we say - here it's bad and there was something strange, right? Of course, for iD it was a job that needs to be done as quickly as possible and make money. Similar hard-coded limits, as here, if sum it all together and wish the stable work of the whole engine - this may well be needed for the hardware of the 90s, not?

Chocolate Hexen
1. Sometimes there show funny screenshots, I will also offer a small puzzle game for Hexen guys :) The question is which of the choco screenshots below are not correct? Hint: there is only one correct screenshot and this is the original game bug. You can see it yourself if you run the game and just watch 3 demos in the main menu demo loop.

1   2   3 

2. In Chocolate Hexen 2.3.0 added suppot multi-levels demo recording resulting in the following problem, which noticed and suggested to me by Opulent. It can be reproduced very quickly, it takes 2 minutes, start record demo with the following line:
chocolate-hexen -warp 11 -skill 4 -class 0 -record DieTest -demoextend

After appearing on map11 the teleport will immediately be behind you - enter in it, after the teleporting to map7 - stop recording a demo. Now repeat the record with the same parameters, after the teleporting to map7 - engine kill you? Further, it will kill you constantly, with any number of attempts to record demo with these parameters.

In this example, I use the map11 specifically, because here the teleport is nearby and you can test very quickly. But it will happen on any map and it needs to be fixed. I think, this kills happens because the engine did not delete the needed reborn/base slots from last session in savegame folder at the beginning of a new game session and at the following starts - engine tries to use these savegame files, which is not correct. Also, this only happens for recording and timedemo processes and never happens when start a new game or playback multi-levels demos.

To fix this possible if call G_StartNewInit() before G_InitNew() in G_RecordDemo() and G_TimeDemo() functions in G_game.c, ie do the same as now doing G_DoPlayDemo(). This will force the cleaning old savegame files in the save folder. I tested, for me now everything works correctly.