PrBoom Turn-Snapping Bug

In PrBoom, when you start recording, the player snaps to a different position when you make your first move, even if you don't turn your mouse before the screen finishes bleeding. Now I know this was brought up before on this forum, and I remember someone saying that it isn't existent in the modified 2.2.6, but it is. So I was wondering if someone could take a look at the source code and fix it once and for all.

Thanks,
Phil

This generally happens if you have been holding a key down before recording starts. If you avoid doing that, there generally isn't a problem. That is irritating, of course, since it makes it harder to get a quick start.

I recall Quasar saying that he had fixed this in Eternity.

Actually keyboard events will be caught by the menu code until the first level tic. The issue is actually with the mouse code. When a program calls the SDL method to set the mouse position, it causes feedback mouse movement events to get sent to the program (I don't think this should actually happen and might be a bug in SDL, but it's there and has to be dealt with). I fixed it (I hope!) in Eternity by disabling SDL mouse event processing completely until the first real gametic happens. That way any mouse positioning done during video init is ignored. Prboom needs to do the same thing, apparently.

That must be a different issue then. I've never had any mouse-related problems at the start of recording with prboom, but I get the problem I described pretty much every time if I press a key too early (I immediately abandon the recording if that happens).

With schepe's modified Eternity (3.31 beta 5), I always got some odd rotation movements in the first few gametics, but I assumed that was put in deliberately to mark it as not a Doom2.exe demo.

One thing I've noticed with the original exe is that if you use novert, you often start off at an angle. In fact, the first gametic of Vile's 30nm2956 is "GB50 TR33", which I presume is the same issue.

On my system, if I don't hold the forward mouse button down while warping into a level I lose the ability to turn with the mouse and of course have to jump out.

Never had that problem until I upgraded to 2.2.3 from 2.2.0

I went back to 2.2.0 and the problem is now still there.

It is a bit annoying when you are trying to record a demo.

Hopefully a future version will fix that.

Edit: I meant to say when I upgraded to 2.3 from 2.2

grazza: on the original .exe it's generally regarded as a feature, not a bug :). If you watch virtually any short compet-n speedrun you'll notice this 'quickstart' is used, the player will already be at an angle and straferunning when the screen clears. You can turn the mouse and press some movement keys near the end of the init sequence and they will be used. If you *don't* do quickstart, the first 0.22secs of the demo will be wasted time of the player standing still on the start point. On short, highly optimised runs, 0.22secs is a big deal.

Yes, except that in 30nm2956, the next six gametics are all WT, and the next movement isn't until gametic 8 (0.22s).

I tested this by recording a couple of test demos in Doom2.exe where I did absolutely nothing at all (no key-presses, mouse stationary) after launching the BAT file to make the recording (so no input during the init sequence). I got a movement in the first gametic, followed by a series of WT tics. Actually, novert only changed what was in the first gametic - the turning occurred in both cases. With novert it was TR58. Without novert it was GB50 TR60. The numbers vary a bit, and this behaviour also occurs when I use the keyboard (rather than the mouse) to launch the BAT file to make the recording.

So there's obviously something going on, not directed related to quickstart. This is on XP, and it may well be dependent on the mousedriver and sensitivity.

oh, right, I see. yeah, i've always seen that intermittently. never pinned down a cause and it's amazingly annoying; sometimes yoy start up, do a good quickstart, and wind up pointed in entirely the wrong direction. blah. just q and restart. it happened to me for ten years playing doom, never did work out what caused it. doesn't seem to happen using dosemu on linux so far, though, fingers crossed.

Well I'm not sure if it's the same problem Grazza is talking about, but a couple of years ago I did investigate the problem that ultdoomer described. As I recall, it's caused when PrBoom changes the video mode and "grabs" the mouse. The mouse cursor gets warped from wherever it is to the middle of the screen, which causes a big jump mouse-event to be added to the mouse queue, I fixed it by simply clearing out the mouse event queue right afterward. I also fixed a few of the other demo quirks in PrBoom that annoyed me (such as the inability to overwrite an existing demo) and produced "JrBoom". You can download it here or get the source here. I didn't really delve too much into the Doom engine though, so these changes are basically hacks, but they worked well enough for my needs.