Chocolate Doom version 2 beta

Oops! Thanks marineController for finding this. I will definitely fix it ASAP.

Share this post


Link to post

Okay, h5s2-344 now seems to play back correctly. h5f3-803 still desyncs. Any ideas?

marineController said:

OK, after messing around with the DOSBOX debugger for a bit

I'd be very intrigued to hear your methods!

Share this post


Link to post

I've just downloaded the zip from the v2 branch on git hub, applied the two changes listed in this thread (nice that Quasar spotted the other one), built with msvc and both demos playback fine for me.

My method was basically:
Locate D_DoomLoop, from there the heretic source code can be used as a guide by following the calls.
Locate the addresses of thinkercap, leveltime and P_MobjThinker.
Play the demo and wait until it's just about to desync.
Break into the DOSBox debugger (ALT-Pause).
Set a memory break point for changes to leveltime (F5 then advances the game by 1 tick).
Dump the memory to a file (16M).
I made a program to load the file and walk the thinkers list outputting the x, y and z position for each mobj (function == P_MobjThinker).
I made a similar mod to choco-heretic so then the data for both tics could be compared.
The tick and mobj responsible for the desync can then be determined.
Use choco to break on the tick and mobj update and step through and see what is happening (I added a mobj counter so I could break at the mobj).

In DOSBox, for me the addresses were always the same:
CS = 0180, DS = 0188
D_DoomLoop = 0180:001a6c08
P_Ticker = 0180:001c04b0
P_MobjThinker = 0180:001b90b0
thinkercap = 0188:00214940
leveltime = 0188:00214950

Share this post


Link to post

Just to be clear, are you saying the fix I pointed out the need for hasn't been applied to v2-branch? I'm a bit confused as to why it wouldn't have been. I did mention it both here and on IRC. Anyway glad to hear it is fixed.

EDIT: I did a SVN update and the fix does seem to be applied already.

Share this post


Link to post
marineController said:

I've just downloaded the zip from the v2 branch on git hub, applied the two changes listed in this thread (nice that Quasar spotted the other one), built with msvc and both demos playback fine for me.

My method was basically: [snip]

This is really interesting, thanks!

I wonder if it would be possible to script the DOSbox debugger in some way? Theoretically it would then be possible to dump a file containing eg. the positions of all objects in a level at every tic. This could then be compared with positions in Chocolate Doom. It would be useful both as a regression testing and debugging tool.

I already have a script for doing regression testing against Vanilla over the Compet-N archive set, but this uses a "black-box" style method that is fairly coarsely grained. Having something finer grained that could identify the precise moment a desync occurs could be quite useful.

Quasar said:

Just to be clear, are you saying the fix I pointed out the need for hasn't been applied to v2-branch? I'm a bit confused as to why it wouldn't have been. I did mention it both here and on IRC. Anyway glad to hear it is fixed.

EDIT: I did a SVN update and the fix does seem to be applied already.

I think I see what happened here. For now the SVN repository is still the canonical source code repository for Chocolate Doom, but I have a Git repository that is synced from it. The sync process is automated but I have to manually run the script and forgot to do so. MarineController was using the Github code that didn't include my fix.

Share this post


Link to post

I don't know if this is outside the scope of "vanilla compatibility", but I have a joystick with 28 buttons, and chocolate doom doesn't seem to recognize the higher ones. I'm not sure how far up it will read. chocolate-doom-setup.exe does recognize all buttons, and I can move with the joystick, so I'm pretty sure it's not the fault of the hardware.

(In case you're wondering, my joystick is an arcade fighting game stick very similar to this. However the PCB that came with it sucked, so I gutted it and replaced it with a USB joystick interface, and wired it in an extremely haphazard and amateur way. So the button mapping is all over the place, and ended up being at the high end of what the USB device offers. Something I've been meaning to redo for a while, one of these days...

As to why I'm using it: http://www.doomworld.com/vb/showthread.php?postid=1218468. For now I'm just using a joy-to-key program that seems to work well enough.)

Share this post


Link to post

I just gave chocolate-strife beta 3 a try in Linux and I believe it is not ready yet.

1) The following fix is required to keep it from instantly segfaulting whenever a (new) game is started or loaded:

--- a/src/strife/hu_stuff.c
+++ b/src/strife/hu_stuff.c
@@ -274,7 +274,7 @@
         // haleyjd 09/18/10: [STRIFE] nickname weirdness. 
         if(nickname != player_names[consoleplayer])
         {
-            if(*nickname)
+            if(nickname && *nickname)
             {
                 DEH_printf("have one\n");
                 nickname = player_names[consoleplayer];
2) When talking to Rowan, his text isn't displayed at all. Just the "Rowan" title and the choices, but not what Rowan actually says.

I stopped testing then...

Edit: Also, the src/chocolate-*-setup binaries are not cleaned up in the distclean rule - as are the manpages, the desktop files and some others...

Edit 2: Sorry, the missing dialog was my fault. I had voices.wad in the same directory as strife1.wad, had my speakers turned off and "show_talk 0" in my strife.cfg.

Share this post


Link to post
fabian said:

I just gave chocolate-strife beta 3 a try in Linux and I believe it is not ready yet.

1) The following fix is required to keep it from instantly segfaulting whenever a (new) game is started or loaded:

--- a/src/strife/hu_stuff.c
+++ b/src/strife/hu_stuff.c
@@ -274,7 +274,7 @@
         // haleyjd 09/18/10: [STRIFE] nickname weirdness. 
         if(nickname != player_names[consoleplayer])
         {
-            if(*nickname)
+            if(nickname && *nickname)
             {
                 DEH_printf("have one\n");
                 nickname = player_names[consoleplayer];
2) When talking to Rowan, his text isn't displayed at all. Just the "Rowan" title and the choices, but not what Rowan actually says.

I stopped testing then...

Edit: Also, the src/chocolate-*-setup binaries are not cleaned up in the distclean rule - as are the manpages, the desktop files and some others...

Edit 2: Sorry, the missing dialog was my fault. I had voices.wad in the same directory as strife1.wad, had my speakers turned off and "show_talk 0" in my strife.cfg.

I can investigate the crash.

EDIT: Removed rest of post because post was edited while I was responding to it.

Share this post


Link to post
plums said:

I don't know if this is outside the scope of "vanilla compatibility", but I have a joystick with 28 buttons, and chocolate doom doesn't seem to recognize the higher ones. I'm not sure how far up it will read. chocolate-doom-setup.exe does recognize all buttons, and I can move with the joystick, so I'm pretty sure it's not the fault of the hardware.

The current limit is 20 buttons, though your use case definitely ought to be supported. Ideally there shouldn't be any limit on the number of buttons. But it's tricky. I'll explain why.

As you probably know, Vanilla Doom only supported four buttons. Modern joysticks and gamepads include many, many more buttons than this, so Chocolate Doom increases this to 20.

The reason it's tricky is that there is a hack used in Vanilla Doom to make the player always run: if you set joyb_speed to a large value then it's like you're holding down the run key all the time. Chocolate Doom supports this hack so that its configuration files are compatible with Vanilla (any value over 20 is interpreted as "always run").

So there's a problem: if you set joyb_speed=28, should that mean "run when joystick button 28 is pressed" or "always run" (like Vanilla). I think the latter, but it sucks that this means some gamepads can't be supported. Ideally we want both.

All problems in computer science can be solved through another level of indirection, and I think that's the solution here: it should be possible to change the button values (for joyb_speed, etc.) to be "virtual buttons", and then define a mapping from these "virtual" buttons to physical ones. It should be possible to implement this such that the setup tool does this all invisibly behind the scenes without the user needing to know anything about it. It's probably going to require a bit of work and almost certainly won't be in 2.0.0, but I definitely want to solve this problem.

Share this post


Link to post

Well like I said, there's a fairly easy workaround and it's not the usual way in which I play, so no rush to fix it on my account. This is certainly not the first game in which I've had problems with this controller. I'd recommend clamping down on the values accepted by the setup program to match the game though, at least for the time being, but you've likely thought of this already.

Are you handling the always run hack in the same way that Doom did (some kind of overflow I think?), or just looking for a special case and applying the same end result?

Share this post


Link to post

The Vanilla hack works because it overflows the 4-item array representing joystick button state. When it overflows it's reading junk memory and interpreting it as a button state. Different values work as 'autorun' in different versions of Doom, so > 20 is interpreted as an attempt to autorun.

Share this post


Link to post
Quasar said:

I can investigate the crash.

Great, thanks!

Since the other problem was merely a configuration issue, I recall my impression that chocolate-strife is not ready yet. :)

Share this post


Link to post

This patch fixes the removal of auxiliary files in the clean rule:

--- a/chocolate-doom-chocolate-doom-2.0.0-beta3_orig/data/Makefile.am
+++ b/chocolate-doom-chocolate-doom-2.0.0-beta3/data/Makefile.am
@@ -13,6 +13,8 @@ iconsdir = $(prefix)/share/icons
 icons_DATA = @PROGRAM_PREFIX@doom.png   \
              @PROGRAM_PREFIX@setup.png
 
+CLEANFILES = $(icons_DATA)
+
 @PROGRAM_PREFIX@doom.png : doom.png
 	cp doom.png $@
 
--- a/chocolate-doom-chocolate-doom-2.0.0-beta3_orig/man/Makefile.am
+++ b/chocolate-doom-chocolate-doom-2.0.0-beta3/man/Makefile.am
@@ -35,6 +35,12 @@ hereticdocs_DATA = INSTALL.heretic CMDLINE.heretic
 hexendocs_DATA   = INSTALL.hexen   CMDLINE.hexen
 strifedocs_DATA  = INSTALL.strife  CMDLINE.strife
 
+CLEANFILES = $(man_MANS) \
+             $(doomdocs_DATA) \
+             $(hereticdocs_DATA) \
+             $(hexendocs_DATA) \
+             $(strifedocs_DATA)
+
 chocolate-doom.6: ../src $(MANPAGE_GEN_FILES)
 	./docgen -g doom -m doom.template ../src ../src/doom > $@
 
--- a/chocolate-doom-chocolate-doom-2.0.0-beta3_orig/src/Makefile.am
+++ b/chocolate-doom-chocolate-doom-2.0.0-beta3/src/Makefile.am
@@ -229,6 +229,10 @@ screensaver_DATA = @PROGRAM_PREFIX@doom-screensaver.desktop
 @PROGRAM_PREFIX@doom-screensaver.desktop: doom-screensaver.desktop
 	cp doom-screensaver.desktop $@
 
+CLEANFILES = $(execgames_SCRIPTS) \
+             $(app_DATA) \
+             $(screensaver_DATA)
+
 .rc.o:
 	$(WINDRES) $< -o $@
 %.o : %.rc
--- a/chocolate-doom-chocolate-doom-2.0.0-beta3_orig/src/setup/Makefile.am
+++ b/chocolate-doom-chocolate-doom-2.0.0-beta3/src/setup/Makefile.am
@@ -30,6 +30,8 @@ EXTRA_DIST=                                     \
 appdir = $(prefix)/share/applications
 app_DATA = @PROGRAM_PREFIX@setup.desktop
 
+CLEANFILES = $(app_DATA)
+
 @PROGRAM_PREFIX@setup.desktop : setup.desktop
 	cp setup.desktop $@
 
And while at it, please rename configure.in to configure.ac, the former will no longer be supported in future versions of autoconf/automake.

Share this post


Link to post

Thanks. I've applied your patch, albeit with some slight modifications. configure.in is also fixed.

Share this post


Link to post
fraggle said:

This is really interesting, thanks!

I wonder if it would be possible to script the DOSbox debugger in some way? Theoretically it would then be possible to dump a file containing eg. the positions of all objects in a level at every tic. This could then be compared with positions in Chocolate Doom. It would be useful both as a regression testing and debugging tool.

I already have a script for doing regression testing against Vanilla over the Compet-N archive set, but this uses a "black-box" style method that is fairly coarsely grained. Having something finer grained that could identify the precise moment a desync occurs could be quite useful.

Sometime back, I gave Quasar a hacked strife exe and corresponding VB app. The hacked Strife.exe was modified to dump the state of the RNG, and the address of the function that called P_Random(). As it ran, it filled up the unused video buffer with this info. The screenshot routine was modified to dump this buffer to file, and reinitialize. Basically, you had to run in DEVMODE, and press the screenshot key every second or so, while the demo was running. Heh!

The VB program took the dumped files, put them together, and did a lookup against the caller addresses, converting them to A_Look(), A_Chase(), etc. By writing similar code in Chocolate, you could quite easily find most desyncs, usually down to the faulty action routine.

It's a watered-down, in-exe equivalent to the sync debugging code that I used to help Maes get his Java port, Mocha Doom, to play original Doom/Doom II/Final Doom demos without desync! I don't think he's released the sync-corrected versions yet - that was a few months ago, and I haven't heard from him for a while. We got all of Doom, Doom II, and TNT working, with one desync in Plutonia. We were nearly finished when I decided to re-write my sync code to have tons of features, and crap. Since then, I haven't heard much from Maes. Real-life and all.

But, yes, imagine it: a Doom port, completely ported to Java, playing synchronized demos! Maes didn't believe it was possible at first. Maybe, he'll chime in to this thread.

Anyway, Quasar got his code working, and synchronized at about the same time that I sent him my tools, so I don't know if he got any use out of them or not. I must admit that I was a bit put off that he did not respond to me afterwards - I put a lot of time researching Strife demo sync, building him that set of tools, writing documentation on how to use them, etc. When he released his first version, I looked for myself in the credits, but I guess, if he didn't use my code, there was no obligation. Not sure why he chose that path, but I'm glad he got his code working.

That being said, if you need it, I can dig it up from my HDD and send you a copy. It's Win32-based, though. However, I could also run it on my machine, and send you dumps of the final output, for you to compare to a dump from an instrumented version of Chocolate. It's easy to do the instrumenting in a source port. Let me know.

Let me just say: This is awesome! Great job!

Share this post


Link to post

I've released Chocolate Doom v2.0.0, in time to celebrate Doom's 20th anniversary. Thanks to everyone who tested this and reported bugs. I really appreciate all the help. Enjoy!

Share this post


Link to post

Thanks for the update, but why is chocolate-doom.exe a 2.8MB file in chocolate-doom-2.0.0-win32.zip? Looks like a compilation bug.

Share this post


Link to post

You're completely right. I will fix ASAP.

Edit: Fixed.

Share this post


Link to post

Is Hexen shareware wad supported?
A quick look at the code suggests not (also crashes when trying to run it).

Share this post


Link to post
fraggle said:

No. Sorry.

No worries, thanks for the reply.

If I fix start up errors when looking for missing graphics/sounds, is there a chance it will work? Or would a load of game code also need changing?
Just trying to determine if it's a relatively easy fix to get it working.
Cheers!

Share this post


Link to post

I think I tried a few months ago in the hope that it wouldn't be too much work to get working. I don't remember the details now, but I recall that it turned out to be more complicated than I hoped. You're welcome to try though. If you do get it to work then please let me know!

Share this post


Link to post
fraggle said:

I think I tried a few months ago in the hope that it wouldn't be too much work to get working. I don't remember the details now, but I recall that it turned out to be more complicated than I hoped. You're welcome to try though. If you do get it to work then please let me know!


OK I think I got it to work for my needs, it's a bit of a hack, also I made up what happens at the end of the demo, but seems to work.

Making updates in this fork:
https://github.com/emileb/chocolate-doom

Cheers, Emile.

Share this post


Link to post

Do linux users have proper midi support in this?

Had to change source code in older versions to use different midi backends via environment variable, due to lack of proper midi support (and lack of rendering midi like vanilla Doom).

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now