Chocolate Doom

Danfun64 said:

Also, the game still crashes in mp mode.

Thanks. And which platform did you run this test on (since you have multiple different ones)? Please post a copy of stdout/stderr for this run too.

You're correct re: chungy's request; however, it would still be useful if you could post checksums of your IWADs - I for example cannot reproduce this issue so it would be useful to eliminate any WAD differences as a possibility.

I didn't think this would be necessary, but I'll do it anyway.

doom.wad

http://i.imgur.com/WQ7a3Ep.png?1

doom2.wad

http://i.imgur.com/gkLsaJp.png?1

They match the md5 checksums from doomwiki.org

I have two computers. The first is a laptop that has Xubuntu 15.10 64-bit and Windows 10 Home 64-bit. The second has Windows 7 32-bit (I refuse to upgrade that computer to Windows 10 because I don't think it will be able to handle metro.)

At one point, thinking that my modem was at fault, I disconnected the desktop from it and tried the two windows on one computer method again, and it still gave a similar draw error message. I simply don't know why my computers refuse to cooperate when it comes to multiplayer.

I can't reproduce this either, between 32-bit Windows XP and 64-bit Linux. I should probably get myself a Windows 10 install DVD and load up a VM with it.

I see "crispy_doom" in your path. Are you absolutely positive this thread so far has been about only Chocolate Doom? As fraggle mentioned earlier, there may be bugs introduced into Crispy and those should properly be reported to fabian. :)

I think his IWADs are just in that folder, jesus people :-)

I prefer crispy doom. Since the bug seems to be shared with chocolate doom, I have the chocolate doom exes in my crispy doom folder until the bug is fixed.
Tomorrow I will provide video verification of the bug.

I installed Windows 10 64-bit in a VM just to try to replicate this. Successfully launched co-op an deathmatch games with it, WinXP 32-bit, and Linux 64-bit all joining a serveer. Didn't matter which computer started the server.

This is quite odd. I don't know any other particulars of your setup that is affecting the results.

Danfun64 said:

I prefer crispy doom. Since the bug seems to be shared with chocolate doom, I have the chocolate doom exes in my crispy doom folder until the bug is fixed.
Tomorrow I will provide video verification of the bug.

Please post the stdout/stderr of your latest run from both ends as well, as I asked.

Thanks for checking the checksums. I know this is tedious but I'm trying to eliminate as many possibilities as I can, since it seems that neither I nor others are able to independently reproduce the problem.

At one point, thinking that my modem was at fault, I disconnected the desktop from it and tried the two windows on one computer method again, and it still gave a similar draw error message. I simply don't know why my computers refuse to cooperate when it comes to multiplayer.

Please stick with the "two players in separate windows" method since it eliminates a whole bunch of different possibilities (different OS, different build, etc.)

Something strange just happened. In the linux side of my laptop I decided to test out the latest git release. For whatever reason, the multiplayer worked there. I went back to the latest stable on linux and it worked also on there. I tested the windows side again, and I got the bug again.

...the next thing I am going to try is cross compiling the latest git build and testing that. This might have been fixed by changing something in the config generation code.

edit:...or I could just use the autobuilds from http://latest.chocolate-doom.org/...

edit 2: does anybody have a good libsamplerate-0.dll?

edit 3: So basically, while trying to solve one bug, I found another. The purpose of the autobuilds is nullified if it doesn't come with every dll necessary to load the game.

The Windows autobuilds are currently broken. I'm already aware of this.

But please don't use latest builds or your own versions; instead use the latest release from the website. If we use a well-known binary then it will be easier for me others to reproduce the problem. Building your own binaries introduces more variables into the equation and makes the problem harder to debug.

If you can provide the information from my previous comment it may be helpful.

For whatever reason, loading the latest autobuild and then the latest stable build helps to fix the problem. Chocolate multiplayer seems to be working now.

...????

...oh, and Crispy multiplayer still has the (one client crashes silently while the other shows a black screen but works fine otherwise) bug, but that's another issue...which already exists...

I mentioned this on the Chocolate Doom dev list, but I figure I'll announce it here too. The first release of sdl2-branch will be Chocolate Doom v3.0:

https://groups.google.com/a/soulsphere.org/forum/#!topic/chocolate-doom-dev-list/tfr-FKhfBKU

The branch is still in development though, so this won't be released for a while yet. You can track the current status on the wiki.

Question: is there anything worth emulating in this vanilla Doom stack limitation? Or does it crash most of the time? Is the "unpredictable" non-reentrant behaviour already in, thanks to code being identical?

printz said:

Question: is there anything worth emulating in this vanilla Doom stack limitation? Or does it crash most of the time? Is the "unpredictable" non-reentrant behaviour already in, thanks to code being identical?

Easier said than done. How fast the stack fills up largely depends on the compiler and its settings. You can't make it so that it's reproducably 'stable'.

Is this something you can produce a DeHackEd file to replicate, or was it just random poking at the binary?

chungy said:

Is this something you can produce a DeHackEd file to replicate, or was it just random poking at the binary?

As I understand it, you just have to modify the barrels to explode on their first death frame, and that can be done in Dehacked.

Anybody feels like Chocolate-Doom's framerate is lower than older versions? I ran a Chocoalte-Doom executable that I found and it's one year old, when I play, I feel the game runs faster. When I ran them with -timedemo and they returned 202 and 203, but to my eye it looks different, the older one is more smooth. Maybe a fix made the framerate lower?

https://www.youtube.com/watch?v=nXkQwQ14qZo

If you can't see it from the video, download my older exe and compare it with the latest:
http://www.mediafire.com/download/ix2afx3bt9on35o/cdhp-r2758-win32.zip

I haven't been playing for months.

Maybe related to this bug which was fixed last year? But that should have made your frame rate better, not worse.

axdoom aren't both versions running/capped at 35 fps?

VGA said:

axdoom aren't both versions running/capped at 35 fps?

I activated the FPS overlay in Fraps and with the old version of Chocolate-Doom, it displays 60fps. With the new version, it displays 35fps.

Here's my uninformed guess:

I'm assuming your monitor runs at 60hz, whereas Chocolate Doom runs at 35hz. This means that there's a time lag between when Chocolate Doom updates to its next frame and when your monitor actually displays it. This delay is erratic (albeit periodic on a short timescale) and basically goes as follows:

tic 1: 5 ms late (1/35 is 28ish ms, 2/60 is 33ish ms)
tic 2: 10 ms late
tic 3: 14 ms late (!)
tic 4: 2 ms late
tic 5: 7 ms late
tic 6: 12 ms late
tic 7: 0 ms late (7/35 = 200 ms, 12/60 = 200 ms, so they sync up here and repeat from the beginning)

And it could actually end up worse than this: at tic 4, the game wants to push a new frame at t-plus 114 ms (4/35), and the monitor is going to update at t-plus 116 ms (7/60). If the game takes more than 2 ms to update the game state and render the frame to the SDL buffer or whatever, which seems likely, then it will miss the window for the screen update entirely, and it will actually be like 19 ms late.

Maybe the old rendering loop that rendered each frame twice somehow made this frame lag smooth out? I don't really know why that would happen but it's not impossible?

(On a somewhat-related note, I've actually pondered before of the feasibility of hacking Chocolate Doom to have interpolation like PrBoom-plus et al have, and then forcing the game to render at a locked 30 fps. The result would obviously be a lower frame rate, and you wouldn't even see every tic onscreen, but at least the frame time would be constant and it might appear visually smoother and more consistent with the DOS/CRT experience.)

I've done something similar before, but not in 60 fps, so I made a little video comparing a demo when recorded (in prboom-plus) at 30 fps versus at 35 fps like normal, and then converting both to 60 fps by the usual method of just duplicating frames.

Can't really tell a difference from watching...

axdoom1 said:

Anybody feels like Chocolate-Doom's framerate is lower than older versions? I ran a Chocoalte-Doom executable that I found and it's one year old, when I play, I feel the game runs faster. When I ran them with -timedemo and they returned 202 and 203, but to my eye it looks different, the older one is more smooth. Maybe a fix made the framerate lower?

I have expirienced the very same problem. fps is much lower an anything above 640x480. the same in crispy doom. it's just uncomfortable to play, it's even faster to just use dosbox

ABRACADABRA said:

I have expirienced the very same problem. fps is much lower an anything above 640x480. the same in crispy doom. it's just uncomfortable to play, it's even faster to just use dosbox

Yes, it is very uncomfortable. What is your system's configuration?

In my case, I have a laptop with an Intel i5-3230M CPU @ 2.60GHz and an Intel HD Graphics 4000 with 64MB of dedicated video memory.

If you set your bit depth to 16-bit instead of 32-bit, is the experience more comfortable?

Linguica said:

I've done something similar before, but not in 60 fps, so I made a little video comparing a demo when recorded (in prboom-plus) at 30 fps versus at 35 fps like normal, and then converting both to 60 fps by the usual method of just duplicating frames.

https://www.youtube.com/watch?v=mqzamLmqoDc

Can't really tell a difference from watching...

I've wondered for a while if 30fps would work out, nice to actually see that in action.

Like Ax said on YT, the result seems to be mostly noticeable in the weapon bob. A lot of little twitches get smoothed out — the first two seconds for example, the pistol on the right moving upwards for a single frame. But I think you'd be hard-pressed finding specific differences without having the footage side-by-side.

I wonder though if it'd feel different to actually play at 30fps, instead of simply watching it.

Well, I think Linguica has already given a rather compelling explanation here. Please read through it again, I think it makes great sense:

https://www.doomworld.com/vb/post/1552090

Sure, I read that! I'm just putting in a vote of interest. It's one thing to understand it, another to actually experience it first-hand.

So I tried to fix my problem by myself. I didn't take the time to understand Doom's code and tried to add some I_Sleep(##) in the following piece of code:

    while (!PlayersInGame() || lowtic < gametic/ticdup + counts)
    {
	NetUpdate ();

        lowtic = GetLowTic();

	if (lowtic < gametic/ticdup)
	    I_Error ("TryRunTics: lowtic < gametic");

        // Still no tics to run? Sleep until some are available.
        if (lowtic < gametic/ticdup + counts)
        {
            printf("lowtic: %i	gametic: %i	ticdup: %i	counts: %i	entertic: %i\n", lowtic, gametic, ticdup, counts, entertic);

            // If we're in a netgame, we might spin forever waiting for
            // new network data to be received. So don't stay in here
            // forever - give the menu a chance to work.
			if (I_GetTime() / ticdup - entertic >= MAX_NETGAME_STALL_TICS)
            {
                return;
            }

            I_Sleep(1);
        }
    }

(BTW, there are tabulations in this code. This doesn't respect the way that Chocolate-Doom must be coded. Like it is said in HACKING.txt. The line " NetUpdate ();" starts with tabs and it has a space after the function name before "()". The line "if (lowtic < gametic/ticdup)" starts with tabs too.)

If you examine this code, you'll see that I added a "printf". It magically fixed my framerate issue. I tried to use Sleeps instead, but it couldn't fix it. I have no idea how printf fixed it.

I'm leaving my new exe here in case ABRACADABRA wants to try it to see if it also fixed his issues with the framerate:
http://www.mediafire.com/download/wfqep7cwqo7xbzg/chocolate-doom-framerate-fix.zip

Note: Trying to compile Chocolate-Doom with Visual Studio 2015 will results in errors like "error LNK2019: unresolved external symbol __imp____iob_func referenced in function _ShowError" and is only caused by this new version of VS, they changed the definition of stdin, stdout and stderr.

I'm not convinced by Linguica's theory yet.

axdoom1 said:

If you examine this code, you'll see that I added a "printf". It magically fixed my framerate issue. I tried to use Sleeps instead, but it couldn't fix it. I have no idea how printf fixed it.

I don't like magic :)

What happens to your framerate if you just comment out the I_Sleep() line? (and make no other changes)

Removing the I_Sleep didn't fix my problem. I tried I_Sleep with different values like 2, 5, 10, 15, 25, 27, 30 and 40. At 30 and 40, the game can draw up to 2 dots using -devparm, but with lower values I didn't see any changes. I thought I_Sleep would change something, because the only effect that printf should have is to slow down the code a bit because writes to the console are slow.

axdoom1 said:

Removing the I_Sleep didn't fix my problem. I tried I_Sleep with different values like 2, 5, 10, 15, 25, 27, 30 and 40. At 30 and 40, the game can draw up to 2 dots using -devparm, but with lower values I didn't see any changes. I thought I_Sleep would change something, because the only effect that printf should have is to slow down the code a bit because writes to the console are slow.

Another possible explanation may be that the compiler identified "dead code" there and optimzed it away, and by adding your printf() statement you brought that code back to relevance?