Chocolate Doom

[fraggle]

Scet said:

What version of VC do you have entryway? VC2003 and 2005 should in theory be compatible with anything for GCC,

This isn't true by any stretch of the imagination. MSVC is not C99 compliant, for example.

entryway said:

i have both vc6 and vc2005, but it has no practical importance. long long does not transform into __int64 because of it. etc. 507 warnings like signed/unsigned mismatch, conversion from 'const double ' to 'int ', possible loss of data and differs in parameter lists will not disappear too - these are mistakes of choco-doom only.

Are you referring to the old version you were using? I turned on the same warnings in gcc and fixed a lot of these.

[Scet]

fraggle said:

This isn't true by any stretch of the imagination. MSVC is not C99 compliant, for example.

That's possible, I was referring more to C++ than C. I terms of C++, VC6 and VC2005 are worlds apart. This is just going by what people say though, I don't really like MS's IDEs. On another forum I belong to, Gamedev, almost all beginner C++ problems are solved by getting them to give up on VC6 and stop using MS specific keywords/libraries.

[fraggle]

ultdoomer said:

I have a desync to report: Level 26 in 30nm2956.lmp, the C-N NM record. PrBoom-plus plays it back correctly, and it's a C-N demo, so I assume there's something wrong with Chocolate Doom.

Bizarrely, I can't reproduce this. Perhaps a Windows-related issue? Once I get a Windows dev system back up (should be within the next week), I'll be able to investigate this better.

[ultdoomer]

Are you using r736? See grazza's last post in this thread.

[fraggle]

ultdoomer said:

Are you using r736? See grazza's last post in this thread.

I'm using revision 759 (which is the latest version). I can't see anything in the ChangeLog since then which might have caused something like this, though.

[myk]

Who is it we have to bribe to get these later versions? The latest I have is from the Doomwire site.

One might as well think v0.1.4 is the latest version. I don't understand why the MultiPlayer betas branched off or why these obscure "r" builds aren't even mentioned on the Chocolate Doom site, and it's confusing anyway, regardless of any underlying rationale.

[RTC_Marine]

You'll have to visit the #chocolate-doom irc channel on irc.oftc.net, the latest build is in the topic.

It is confusing to me aswell, even though I'm the one who creates the builds, there is no "official" version out that has the latest fixes and stuff from the repository unfortunately.

[Grazza]

Why not a simple link from the place you'd expect to find it - i.e. the Chocolate-Doom homepage, and marked "latest beta" or "latest test version"? What possible harm could that do? It would certainly reduce confusion.

[fraggle]

myk said:

Who is it we have to bribe to get these later versions? The latest I have is from the Doomwire site.

One might as well think v0.1.4 is the latest version. I don't understand why the MultiPlayer betas branched off or why these obscure "r" builds aren't even mentioned on the Chocolate Doom site, and it's confusing anyway, regardless of any underlying rationale.

Yes, I agree :-)

[funduke]

fraggle said:

I'm using revision 759

Please give us non-programmers a binary version.

It seems to have been already requested in other words by Grazza and Myk (though chances are good, that their rogramming skills are higher than mine), so this is just my agreement to that.

Greetings
Funduke

[RazTK]

You can get the latest revision binaries here.

[funduke]

RazTK said:

You can get the latest revision binaries here.

Thank you!

Greetings
Funduke

[Csonicgo]

The build-chocolate-doom script isn't working on the latest ubuntu at all. Something about a syntax error, sh: ")" unexpected. Dunno what to do with that.

[fraggle]

Csonicgo said:

The build-chocolate-doom script isn't working on the latest ubuntu at all. Something about a syntax error, sh: ")" unexpected. Dunno what to do with that.

Try again :-) I fixed the script.

[myk]

We were using Chocolate Doom r736 for DM 1-on-1s and it often randomly shut down, mostly without a message, except occasionally when one of the two (the server, I believe) would note that the other client disconnected (timed out). Otherwise it would go back to the command prompt without any error message or output.

Server command line:
chocolate-doom.exe -server -nomonsters -deathmatch -skill 5

Client command line:
chocolate-doom.exe -connect [server IP]

[Quasar]

Usually when EE shuts down in this manner, it is due to a silently handled exception, examples would include division by zero or a segfault on a subordinate thread (ie in one of SDL's threads). Catching these can be quite difficult and requires having a debugger attached at the time the exception occurs.

Of course this could be something entirely different, but it sounds suspiciously similar to me.

[RazTK]

myk said:

We were using Chocolate Doom r736 for DM 1-on-1s and it often randomly shut down, mostly without a message,...

I believe it has something to do with this (Note: It doesn't only occur in DOOM2 MAP08). I hope fraggle will fix it soon.

[myk]

RazTK said:
I believe it has something to do with this

You're probably right. I went to a couple of DOOM II levels, did IDFA, and started shooting stuff, and in both cases it eventually terminated in the same way.

[fraggle]

myk said:

You're probably right. I went to a couple of DOOM II levels, did IDFA, and started shooting stuff, and in both cases it eventually terminated in the same way.

Random shot in the dark: what happens if you run with -nomusic? Does it still crash?

It's hard for me to debug Windows bugs at the moment because I don't currently have a working Windows install; however, my new hard drive has now arrived and I should be able to get one up and running again real soon.

[RazTK]

fraggle said:

Random shot in the dark: what happens if you run with -nomusic? Does it still crash?

Still happens, same crash.

[myk]

fraggle said:
Does it still crash?

Yes, it does; the problem doesn't seem to be there. And disabling sound in general didn't help, either.

[Quasar]

I'm going to go way out on a limb and say this is probably one of the various thinker deletion problems that were addressed via changes in BOOM. It may not be possible to fix some of these without sacrificing compatibility, since demos can be sensitive to the behavior of ostensibly deleted thinkers (of course such demos may not reliably play back under all circumstances either).

DOS Doom was less sensitive to these problems because DOS4GW sucked. It also ran in an operating system with drastically different memory allocation coincidences.

Again this is out on a limb, but an educated limb at least.

[myk]

Quasar said:
I'm going to go way out on a limb and say this is probably one of the various thinker deletion problems that were addressed via changes in BOOM.

I doubt it, since the bug seems to be present only in the newer versions. The error is relatively quick; the game hardly lasts one or two minutes. On previous versions I could play for long periods with no such terminations (other than an occasional and mysterious consistency error during multiplayer while using a PWAD, maybe).

[fraggle]

myk said:

I doubt it, since the bug seems to be present only in the newer versions. The error is relatively quick; the game hardly lasts one or two minutes. On previous versions I could play for long periods with no such terminations (other than an occasional and mysterious consistency error during multiplayer while using a PWAD, maybe).

Yeah I agree, this didn't happen in previous versions.

What was the last version before this started happening? And the first version where it started? I can at least look at the logs and see what changed between those versions.

[myk]

fraggle said:
What was the last version before this started happening? And the first version where it started?

It seems that r691 has the same problem, and that r569 does not.

[RazTK]

r638 has the problem too.

[Quasar]

Yeah I suppose that's a good point. It may just be heap corruption. This is often caught by the thinker code first since mobj_t's are the most-allocated structure at runtime, and since the thinker_t, being at the start of its memory block, is highly sensitive to being corrupted by a block overflow.

This is why ZONEID was a good thing :P

[fraggle]

Quasar said:

Yeah I suppose that's a good point. It may just be heap corruption. This is often caught by the thinker code first since mobj_t's are the most-allocated structure at runtime, and since the thinker_t, being at the start of its memory block, is highly sensitive to being corrupted by a block overflow.

This is why ZONEID was a good thing :P

Perhaps it would be a good idea to run Z_CheckHeap if a segmentation fault occurs or I_Error is called?

[Quasar]

Z_CheckHeap will help you verify whether or not it is heap corruption, but won't help you figure out where the error is coming from.

This is why I added two more ways to check and print out information about the heap in EE: first, a complete text dump. This too can crash, but the info it does reveal will usually help locate where the corruption is occuring. Second, a real-time log that records all memory ops (mallocs, frees, reallocs, tag changes, etc). Of course the usefulness of these depends largely on the BOOM zone heap's ability to record the source file and line of all memory operations.

[RazTK]

myk, please test r770, it doesn't seem to have the problem anymore.

Edit: Okay, it does. :-\