recording problem

Hi all!

The actual DSDA update motivated me to play Doom again. And of course I chose my favourite map: Scythe Map26 :) I'm working on a maxrun with -fast, and it's not as hard as I thought. I did four exits within the last three hours. I'm recording with prboom 2.2.4.

The problem is, three of the demos are desyncing:
- my first exit is 5:43 and the playback is ok. But the demo itself is damn ugly :/
- then I got a very nice 4:30 and a 5:08, but both demos are crashing around 4 mins - all demos so far were recorded with -complevel 0
- after that I changed to -complevel 3, but the first successful run (4:59) also desyncs.

Any idea what to do?

Greetings,
Angus

Might be a map-related problem. IIRC, Richie also had similar problems on this map when trying to record a Max.

BTW, the version of prboom that I use to record with is the glboom.exe in Andrey Budko's version (with -complevel 0 by default). I don't recall ever getting one of these mystery desyncs with that (nor for that matter with with the standard glboom.exe 2.2.4.). That includes sc26, though I've only ever recorded short demos on that map (Speed, Pacifist and NM).

I've put a copy of my glboom.cfg here in case it's any help. My understanding, though, is that if you use -complevel 0, it ignores all other compatibility settings and uses everything it's got to provide maximum compatibility with Doom2.exe.

Thx, Grazza. I'll try the other versions.

I guess it has to do with the crusher/teleport system. In my first exit I turned it on later than in my other tries. And there are no revenants teleporting after pressing the switch. In all the other recordings I pressed it as fast as possible, and after the first time the crusher crushes there are several revenants left loitering between the crusher and the teleporter. And when these bad guys teleport the things are not as they should be.

I'm a bit frustrated now, after a corrupt 4:24 :( But I won't give up. Cause it is much fun to play :)))

Yes, crushers and teleporters do seem to be a common feature in maps where people have had problems like this. Cycloid had some problems like that in one of the Blind Alley maps (and even I managed to get a desync there, albeit when I switched to prboom.exe - specifically, the player would emerge from a teleporter at slightly the wrong angle).

If you want to try other demo formats and need to use a Windows port, then you could try prboom 2.02 (I've used that a fair bit with no problems) or the new WinMBF (no idea how stable that is for recording though - you'd be exploring unknown territory there). In either case, the demo should (if successful) still play back with prboom 2.2.4 and with the equivalent DOS port.

Of course, if this weird teleporter/crusher/desync problem was introduced in Boom, then none of that will be of any help. There's always "doom2 -nosound". Or with PC Speaker sound effects. ;)

I had no luck with glboom. I also read Richie's txt-files. He was finally successful without any -complevel x. I tried this too, but I don't like the different monster behaviour.

The last hour I went back to prboom with -complevel 0 and played it the 'safe' way by pressing the crusher switch as late as possible. I did two exits. The first was around 5 minutes with one revenant left, the second was ok (4:52). Even this way is slower, the result is more enjoyable than a corrupt demo. I will go on with it in the next days.

Scythe MAP26 is one of my favourites too (to watch, that is) - I'm very much looking forward to your new demos. :)

Grazza said:

I've put a copy of my glboom.cfg

Strange parameter in your config:
gl_tex_filter_string "GL_LINEAR"
Why not GL_LINEAR_MIPMAP_LINEAR for example? Or _NEAREST for bilinear filtering.
If speed of your computer suffices for ChessBase Fritz, I do not think that there will be any problems with a filtration %)

I was right. About 15 exits this evening and no desyncing demo :)

entryway said:

Strange parameter in your config:
gl_tex_filter_string "GL_LINEAR"
Why not GL_LINEAR_MIPMAP_LINEAR for example? Or _NEAREST for bilinear filtering.

Thanks for the tip; it makes quite a difference in some places, and doesn't seem to harm performance. I'm not too well up on what all this stuff means, and the prboom documentation didn't say anything about it (or if it does, it is quite well hidden).

If speed of your computer suffices for ChessBase Fritz, I do not think that there will be any problems with a filtration %)

Hmm, Fritz doesn't have very demanding minimum requirements; it just grabs all the resources it can get.

Grazza said:

it makes quite a difference in some places, and doesn't seem to harm performance. I'm not too well up on what all this stuff means, and the prboom documentation didn't say anything about it (or if it does, it is quite well hidden).

Very strange that this settings stands by default. May be it's necessary to inform prboom team.

Hmm, Fritz doesn't have very demanding minimum requirements; it just grabs all the resources it can get.

But you could win against Fritz running on the slow machine. It would be not fair! Modern computer engines such as Shredder, Junior and Fritz are stronger than the person.

Grazza said:

the prboom documentation didn't say anything about it (or if it does, it is quite well hidden).

It's in the boom.cfg.html and README.command-line.txt documents. Not especially hidden, but not where I would have expected to find info on the glboom.cfg options.