Menu
▾
▴
#142 Demo ends at 2mb?
I was playing in deathmatch using a serial cable and it made three hours that I was playing recording a demo and we took a pause and the game exit, for no reason. The demo size was 2mb. The vanilla doom demo limit was turned off because I wanted to record a very long demo. We didn't press Q and we didn't touch to the computers. So I was wondering if their's a limit of 2mb even if the vanilla demo limit is turned off.
Discussion
Doom does't really have a demo limit that can be turned off, all you can do is increase the default -maxdemo value, which you must have done considering the size of the recorded demo. 2mb should be about enough for 3 hours, but it's not an exact science. If the closure occurred immediately after pressing the Pause button and the Pause button was not mapped to the "Finish recording demo" function, then I don't know.
@porschemonty Chocolate Doom allows the demo limit to be turned off. See the compatibility dialog in the setup tool.
It is plausible that you ran out of zone memory while recording. The demo buffer is stored on the zone memory heap, which has a default size of 16MB. It's possible you might get a crash when you reach about 4-5MB of demo.
The demo ended recording at exactly 2,048 mb and my friend and I didn't touch to the two computers.
I'm going to investigate this bug and I'll give you some news after.
Sorry about that. Amazing how one can see something a thousand times without actually "seeing it"
I think it depends on the stability of the network. Playing in multiplayer on a LAN or on Internet is stable, but playing with serial is a little bit less stable. So I tried to play a three player game on a Wi-Fi machine. It's not very stable because the game can stop nowhere for no reason. So I think this happened only because of the stability of the type of device I used to play multiplayer.
I'll close the bug because I can't test it anymore (I sold my laptop that had the serial port) and because it's probably just a zone memory error that occured when Chocolate-Doom was trying to double its demo buffer. The crash was on map24 which is one of the two biggest maps in Doom2 and we did all the levels before it so pieces of data could have remain in the zone memory so it would have made less memory avalaible.
Level size doesn't have any effect on demo recording, so it doesn't matter what level you were recording on, only the length of time you were recording for.
You're correct that it probably occurred when trying to double the demo buffer. As the zone memory is a limited size, the demo probably just grew too large to fit.
I'd rather keep this bug open because it is a legitimate bug that does need to be fixed. It shouldn't be difficult for me to reproduce.
I know the level size as no effect on the demo recording, What I mean is that when a level and ressources are loaded into the RAM, there's less space left for other things.
I did this bug report because there wasn't any Z_ error message telling me if no more memory could be found for the demo buffer. The mistake I did after this was that I didn't look in stderr.txt to see if there was something. I don't remerber if the file was there. After, I started Chocolate-Doom with -playdemo to see if the demo was working so if there was a file, it was erased.
I recorded a 4.54MB demo with -mb 32 so it's not a bug.
Chocolate-Doom doesn't have enough space to double a 2,048mb demo, so I wonder what's in the other 12mb of the 16mb of memory that Choco-Doom allocate at startup. Doom can run with 4mb of memory so I think the maximum demo size with 16mb of allocated memory should be 8,192mb because doubling this won't work.
I should do some tests to see which record the biggest demo between Vanilla and Chocolate with -maxdoom <size> (and -mb 8 for chocolate).
> Chocolate-Doom doesn't have enough space to double a 2,048mb demo, so I
> wonder what's in the other 12mb of the 16mb of memory that Choco-Doom
> allocate at startup.
Sound effects, mostly. trunk Chocolate Doom resamples sound effects to the native sample rate and stores the resampled versions in the zone heap. v2-branch actually changes this to use a separate caching system (the caching scheme caused problems with Strife, which uses long sound effects).
> I should do some tests to see which record the biggest demo between
> Vanilla and Chocolate with -maxdoom <size> (and -mb 8 for chocolate).
Thanks for the offer, but I don't think it's necessary. What needs to be done is to change the demo recording code to write the demo directly to disk instead of storing it in memory, then the problem will go away.
On a side note, I'm not sure what -maxdoom is; I've never heard of it before. And I'm not going to consider differing memory usages between Vanilla and Chocolate to be a bug :-)
Thanks
Sorry, I wrote -maxdoom instead of -maxdemo.
Now I see by what a big piece of the zone heap was used for. Make sure that when you'll change the demo recording code to write the demo directly into disk, change it only for when the demo limit is off.
In v2-branch, will the default heap size be decreased to 8mb? -mb 8 causes Doom to crash at the same place in a demo I did in nuts.wad and Chocolate-Doom (v2) doesn’t need 16mb anymore because the sound is not cached in the same zone heap. This will also fix most (if not all) medusa crashes that didn't happen in Vanilla.
> Now I see by what a big piece of the zone heap was used for. Make sure
> that when you'll change the demo recording code to write the demo directly
> into disk, change it only for when the demo limit is off.
Maybe; I'm not sure it makes any difference, really, or why you're so keen to have it implemented a certain way.
> In v2-branch, will the default heap size be decreased to 8mb? -mb 8 causes
> Doom to crash at the same place in a demo I did in nuts.wad and
> Chocolate-Doom (v2) doesn’t need 16mb anymore because the sound is not
> cached in the same zone heap. This will also fix most (if not all) medusa
> crashes that didn't happen in Vanilla.
If you have problems that are fixed by changing the zone heap size, I suspect the problem hasn't really been properly fixed. I'm extremely hesitant to start using that kind of reasoning. Correct behavior should not be predicated on the zone heap size.
If you change the way demos with Vanilla limit on are recorded, this will be a different behaviour between Chocolate-Doom and Vanilla because Chocolate-Doom saves it temporary into the zone heap during the recording and that's the way it's working in Vanilla. For demos recorded with the Vanilla limit turned off, the way that it's going to work doesn't matter (if it doesn't have a big impact on other things) because Vanilla didn't have this feature. It makes a difference if Chocolate-Doom doesn't work the same way as Vanilla, even if it's inside the program.
About the zone heap size, Chocolate-Doom uses a bigger zone heap that Vanilla. When I decrease it to 8mb in v2-branche, my demo ended with a Z_ error at the same place it crashed in Vanilla (this is no possible in the trunk version of Chocolate because the sound is cached in the same zone heap). I can also play in levels that cause a medusa crash when I use -mb 8 without crashing. I read in ChangeLog.txt that the default heap size was increased to 16mb, I don't see why it was increased. I don't have enough information to understand why it was changed.
I'm purist, Chocolate-Doom is the best port to reproduce Vanilla accurately and that don't have lots of features that are unuseful. Chocolate-Doom is simple like Vanilla, there isn't a bunch of extra features like other ports (features like -scanline or -longtics are fine because they are present in Vanilla). The aim is to accurately reproduce Vanilla Doom, so that also means it should crash at the same places and work the same way.
I think I said everything I had to say and the reasons why I don't like this, it's your port so I don't want to dictate you what to do with it. You surely have good reasons to do it like that or maybe this is too complicated and would cost you a lot of time. I understand that.
Thanks
> If you change the way demos with Vanilla limit on are recorded, this will
> be a different behaviour between Chocolate-Doom and Vanilla because
> Chocolate-Doom saves it temporary into the zone heap during the recording
> and that's the way it's working in Vanilla. For demos recorded with the
> Vanilla limit turned off, the way that it's going to work doesn't matter
> (if it doesn't have a big impact on other things) because Vanilla didn't
> have this feature. It makes a difference if Chocolate-Doom doesn't work the
> same way as Vanilla, even if it's inside the program.
I disagree - if the end result is the same, why is it important?
Even with the limit turned on, I can make it exit once a particular demo size is reached. Either way, the game exits and you have a demo on disk of a particular size. The same thing is already done for savegames.
> About the zone heap size, Chocolate-Doom uses a bigger zone heap that
> Vanilla. When I decrease it to 8mb in v2-branche, my demo ended with a Z_
> error at the same place it crashed in Vanilla (this is no possible in the
> trunk version of Chocolate because the sound is cached in the same zone
> heap). I can also play in levels that cause a medusa crash when I use -mb 8
> without crashing. I read in ChangeLog.txt that the default heap size was
> increased to 16mb, I don't see why it was increased. I don't have enough
> information to understand why it was changed.
I'd say it's a fortunate coincidence that decreasing the zone size to 8mb fixed the problem for you. For me, it's not a satisfactory solution and I'm not going to go tweaking the zone size in an attempt to maintain compatible behavior. For one, it's a fragile hack - if I add another call to Z_Malloc or Z_Free next week - it might suddenly break again. Another reason is that what works for a 32 bit compile probably doesn't work for 64 bit. If there are problems they should be investigated and fixed in their own right.
> I think I said everything I had to say and the reasons why I don't like
> this, it's your port so I don't want to dictate you what to do with it. You
> surely have good reasons to do it like that or maybe this is too
> complicated and would cost you a lot of time. I understand that.
Thank you for your comments, and I appreciate where you're coming from. I'm glad to have such passionate users of my source port.
Okay, I thought about the demo thing some more. Before you mentioned anything I was originally going to fix it the way I described - just abolishing the in-memory buffer and writing demos directly to disk. But as it seems to matter to you, I'll do it the way you ask and keep the memory buffer when the limit is turned on.
I'll see if I can get this done soon, perhaps tonight if I have time.