Chocolate Doom

fraggle said:

Really? I wasn't aware of this. I would have expected games without monsters to work completely cleanly; it's surprising to hear that they desync.

If found this issue with a multiplayer demo. I needed to use a hex-editor to remove the pause, but I couldn't remove it completely, else the game would desynch. LMPIT does remove the pause completely, hence the demo desynch. The game must be unpaused the tic after it was paused, so the pause is still there. It's while experimenting with the demo that I came to find this bug.

The game is paused in player1's tic, before the command inside player2's tic gets executed. If the pause is removed, it runs the command inside player2's tic that would not have been executed if the demo was paused. The game still records input when the demo is paused.

fraggle said:

Hah, wow, that's amazing. I really just meant recompiling the code under DJGPP rather than trying to port it to any modern system. To be honest I didn't think anyone had done anything with LMP-IT since I released the code a few years ago.

It will be more easier for people if it runs natively on their OS, it's simpler and faster than to use DosBox.

Looks like some antivirus believe that Chocolate Doom is contaminated.
http://forum.drdteam.org/viewtopic.php?f=2&t=6558
https://www.virustotal.com/en/file/2ea2f64a4c91e06d644e4e067d0c58f47950fda663ad7b427adcae85b71a69a5/analysis/1426279554/

Maybe this is why some people have also reported that the Chocolate Doom wiki is being reported as an attack site. I couldn't find any evidence of an infection of the actual site itself.

Thanks for the report Gez. I guess maybe this is related to the Avast block from a few weeks ago.

I sometimes build with a Windows XP virtual machine but I don't remember if I used that or a Mingw32 cross-compile for building the latest release. Regardless, I suspect it's a false positive; most of the other antivirus tools listed on the linked page don't detect anything. It's a shame the page doesn't provide more information about which file in the zip is supposedly "infected".

EDIT: "Problem" exe seems to be chocolate-doom-setup.exe. Still not sure why. I've confirmed that the .exes were built on a Linux machine cross-compiling to Mingw32 executables, so I'm basically 100% sure these should be entirely safe.

This kind of situation happened to me two times in my life. Both were a false-positive, detected in an executable of my own program that I built myself, right after the compilation. I just rebuilt the executable and it didn't cause any problem ever again.

Never_Again said:

BTW, it's "desync", not "desynch".

Sorry, I didn't see your comment. If "desynch" is not the correct spelling, then it's wrong on the DoomWiki.

Thank you, I corrected the article. There was another doozy there: "and are read signly".

As for chocolate-doom-setup.exe, could the reason for the false positive be that it's PE?

It'd be more accurate to say "desynch" is just unusual than to say it's incorrect, since the original root is the word "desynchronize." Still, best to be consistent :>

I wouldn't be surprised if the only reason the Chocolate Setup util is being picked on is that it has "doom" and "setup" in the file name.

Trying to build on Win XP SP3 again. Got tired of mucking around with the .vcproj files, so decided to give the approved method (Cygwin) another try.

· selecting only the nine packages listed by the article is not enough, there are a lot of dependencies the article doesn't mention
· 500+ MB later (I dread to think how long it would take on dialup) the setup completes
· wget http://www.chocolate-doom.org/build-chocolate-doom -> OK
· sh build-chocolate-doom -> ends with this

Tried reinstalling the packages (way more than nine), a different mirror - same result

configure: error:
*** Your compiler (gcc) does not produce Win32 executables!

edit: Code::Blocks + MinGW worked. The corresponding Wiki page needs to be updated, though:

- the workspace file is called 'main.workspace' -> the workspace file is called 'chocolate.workspace'
- for a successful build, the whole workspace needs to be built at least once, not just the 'Doom' project
- you may get compiler warnings and "Build failed" if you choose to SVN only chocolate-doom/chocolate-doom/trunk; these can be ignored


If anyone is interested, here's what I went through all this headache for:
Chocolate Doom v2.1.0 with sky fix

Never_Again said:

configure: error:
*** Your compiler (gcc) does not produce Win32 executables!

Have you installed the MinGW compiler? Have you tried explicitly requesting its usage on the command line?

CC=i686-w64-mingw32-gcc ./configure 

I had MinGW installed. Have you read the rest of my post?

Never_Again said:

I had MinGW installed. Have you read the rest of my post?

Yes, I have. What I meant to ask was "Have you installed (and explicitly selected) the MinGW compiler in your Cygwin environment"? The default Cygwin compiler will produce a binary format that is not able to run outside of a Cygwin environment, at least not without supplying additional libraries, that is. Choosing the MinGW compiler in a Cygwin environment will result in a Cygwin->Native Win32 cross compile and the executable should be able to run on native Windows, using only symbols of the MSVCxxx.DLL runtime.

You may have to run "./configure --host=i686-w64-mingw32" if the cheap trick with "CC=..." does not work. That's why I asked you to try that.

Thank you for the clarification, fabian. Both of the commands you suggested produce this:

-bash: ./configure: No such file or directory

You have to do this in the respective source directories. Does a file called configure.ac or configure.in exist? If yes, please run "autoreconf -vif" and try again.

Sorry, fabian, I already deleted the whole damn thing.

Googling for the "Your compiler (gcc) does not produce Win32 executables!" led to a sea of complaints on various forums and mailing lists. The offered solutions (like changing the gcc version to 3.x) only produced more errors on my end.

Thank you for trying to help but I think it's the developers' responsibility to ensure that the officially endorsed way of building their source port works. I followed the instructions on Wiki exactly, step by step, and it didn't work. OTOH, Code::Blocks had no problems. Same compiler, same SDL packages, as far as I can see. So much for "canonical" (which is BS, too, it was Code::Blocks until a few years ago; apparently it was not geeky enough to be called "canonical").

BTW: c:\codeblocks and c:\mingw combined are 445 MB. d:\cygwin by itself was 600+ MB, over 800 when I tried adding mingw64 packages. With Cygwin being CLI and CB GUI you would expect it to be the other way around.

Never_Again said:

Thank you for trying to help but I think it's the developers' responsibility to ensure that the officially endorsed way of building their source port works.

The problem seems to be that Cygwin changed their default compiler to not produce native Win32 object code anymore -- and they even removed the command line flag to enforce this behaviour.

BTW: c:\codeblocks and c:\mingw combined are 445 MB. d:\cygwin by itself was 600+ MB, over 800 when I tried adding mingw64 packages. With Cygwin being CLI and CB GUI you would expect it to be the other way around.

You can hardly compare those two. While Cygwin is a full-blown UNIX running on Windows (similar to a virtual machine), Codeblocks is merely an IDE (i.e. an advanced text editor) and MinGW a compiler. BTW, you can also have GUI in Cygwin. Last time I checked, it installed a full-blown X11 implementation as well.

All that may be interesting from the technical standpoint but the end user shouldn't have to know or understand any of it. People doing their own builds rather than using ready-made bins already go the extra mile, so it is entirely unreasonable to expect them to spend hours finding a way to work around self-defeating software.

The bottom line: currently the "canonical" way of building Chocolate Doom on Windoze is using a software package that "[does] not produce native Win32 object code anymore".

Cygwin's normal GCC toolchain, the one that targets Cygwin itself and allows applications to more-or-less act as regular POSIX applications, dropped the ability to compile normal binaries (no Cygwin dependency) long ago, basically because mingw replaced that role and better. The wiki page does inform you to install mingw rather than the standard gcc (both being installed at the same time shouldn't be an issue, but configure might be getting confused by it).

Considering the page still references updating the source via Subversion, it's probably in dire need of a review and edit or rewrite anyway. (I would personally also like to see the apparent dependency on a magic shell script eliminated or sidelined. Are the manual steps that complicated?)

Why is this the only pinned port?

Doom Retro and PrBoom-Plus don't count?

Because this is a retrograde vanilla purist zealot forum, that's why.

chungy said:

Considering the page still references updating the source via Subversion, it's probably in dire need of a review and edit or rewrite anyway.

I just updated it. The page had been partially updated already but there were just a couple of obsolete references to Subversion still there.

(I would personally also like to see the apparent dependency on a magic shell script eliminated or sidelined. Are the manual steps that complicated?)

Yes, I believe they are. While I admit the shell script as it currently stands has proved to be more painful than it ought to be for a lot of people, the alternative of forcing everyone to learn Unix is far worse. There are many gotchas here than you may think, not the least is the fact that you're essentially doing a cross-compile from Cygwin to Mingw.

I've considered some alternative ways of providing a Windows build environment but the problem has consistently seemed to have been Cygwin itself. Every now and then something changes and the script/instructions fall out of date. It's particularly difficult to keep up because I don't own a machine that runs Windows any more. If I'm trying to get things working again it's usually through guesswork or trying to run a Windows VM at a snails pace on an ancient netbook.

The build script is in Git here in case anyone else wants to send fixes for it.

Never_Again said:

which is BS, too, it was Code::Blocks until a few years ago; apparently it was not geeky enough to be called "canonical"

That's incorrect. In the 10 year history of the port, the canonical build system has always been Cygwin and autotools. I have never in my life even used Code::Blocks.

But I'm sorry you had a bad experience trying to get a compile environment working.

fraggle said:

That's incorrect. In the 10 year history of the port, the canonical build system has always been Cygwin and autotools. I have never in my life even used Code::Blocks.

You may never have used Code::Blocks but until mid-2010 Chocolate Doom's Windows build wiki page did not even mention Cygwin:

Revision as of 01:39, 18 April 2010

A couple of months later the page was renamed to "(alternative build)" and sidelined, and that's when "canonical" made its appearance for the first time.

But I'm sorry you had a bad experience trying to get a compile environment working.

Well, I'm sorry too, but I suspect that no matter how many times I say that, it's not likely to help any Windoze user who follows the "canonical" procedure step by step and gets no compiled exec as the result.

edit: the preceding history discussion is rather irrelevant to the end user who just wants to compile his own Choco build on Windoze. The short of it is that currently Code::Blocks is the painless way to do so, while Cygwin is not.

If you or Mike take a little time to review the Cygwin instructions and see what needs to be changed/updated, I don't mind reinstalling Cygwin and help you verify that following the wiki instructions produces no errors or warnings.

If I use this command:
"C:/STUFF/DooM stuff/ChocolateDoom/chocolate-doom.exe" -iwad "C:/STUFF/DooM stuff/WADS/TNT.WAD" -nomonsters

and start a new game, there are still monsters, why?

Because it doesn't work that way, at least not in vanilla Doom.

Add "-warp 1".

Jesus ...

Informed by my build-system distress when working on Crispy Doom. I made a thing. It's not feature-complete, but it's pretty damn comprehensive so far. Do you have any interest in merging it? What would you require it support before you do?

10 years today since the first commit:

https://github.com/chocolate-doom/chocolate-doom/commit/66a2cc66d7504c9b64e1c461e62ad2a9d964fa95

At the time I started the project I never expected Chocolate Doom to be anything other than a tiny side project to get the linuxdoom source working on modern systems. Since then it's grown into something much larger, spawning numerous spinoff ports and even been the basis of a commercial game release.

I just want to thank everyone who has used Chocolate Doom, all the people who have contributed code, reported bugs and everyone who has posted in this thread which now has over 1,800 comments :) Thank you all for making it what it is.

fraggle said:

10 years today since the first commit:

https://github.com/chocolate-doom/chocolate-doom/commit/66a2cc66d7504c9b64e1c461e62ad2a9d964fa95

At the time I started the project I never expected Chocolate Doom to be anything other than a tiny side project to get the linuxdoom source working on modern systems. Since then it's grown into something much larger, spawning numerous spinoff ports and even been the basis of a commercial game release.

I just want to thank everyone who has used Chocolate Doom, all the people who have contributed code, reported bugs and everyone who has posted in this thread which now has over 1,800 comments :) Thank you all for making it what it is.

Thank you, and everyone else involved! Probably the best free software project I've ever used and a joy to use and play with.