PrBoom-Plus, ver. 2.5.1.4

OK, the problem occurs when I use:
C:\DOOM2\glboom.exe -file C:\DOOM2\strain.wad -deh C:\DOOM2\strain.deh -playdemo STR07-UV.LMP
(Or the equivalent when running it via Winzip from inside a zip file - my standard way of running demos.)

It doesn't occur when I use:
c:\doom2\glboom.exe -file strain.wad -deh strain.deh -playdemo STR07-UV.LMP

It's simplest if I just paste my cfg in here; I'll remove it once you've got it.

*removed*

Share this post


Link to post
Grazza said:

I wonder if this fix will break some demos recorded with Prboom -complevel 0/1. A compatibility option might be nice.

This is the case; I've found an example: Anima's h2311552. This is a demo that doesn't play back correctly with Doom2.exe.

My mistake, thanks. test4
For old not compatible behaviour of the demos on on the strain.wad\map07 and hr.wad\map18 just rename your pwad

Share this post


Link to post
entryway said:

My mistake, thanks. test4
For old not compatible behaviour of the demos on on the strain.wad\map07 and hr.wad\map18 just rename your pwad

Oh, so you've made it so this fix only applies in these two specific maps? That's not quite what I had in mind.

Essentially, you've corrected a bug in Prboom's compatibility with Doom2.exe, so surely this should be the default behaviour for playback of Doom(2).exe-format demos (possibly with a comp option to support Prboom demos recorded before the fix) and recording with -complevel 0/1 - as it means it is more likely to record demos that will play back with Doom2.exe.

If Anima decided to record again on hr2final map31, then with the fix, he would probably record something that played back with Doom2.exe. Without it, he would probably record another demo that desyncs with Doom2.exe. And of course there are doubtless other maps that have this type of issue.

Share this post


Link to post
Grazza said:

OK, the problem occurs when I use:
C:\DOOM2\glboom.exe -file C:\DOOM2\strain.wad -deh C:\DOOM2\strain.deh -playdemo STR07-UV.LMP
(Or the equivalent when running it via Winzip from inside a zip file - my standard way of running demos.)

It doesn't occur when I use:
c:\doom2\glboom.exe -file strain.wad -deh strain.deh -playdemo STR07-UV.LMP

done: test4

Share this post


Link to post
Grazza said:

Oh, so you've made it so this fix only applies in these two specific maps? That's not quite what I had in mind.

For each level which can be overrunig in the vanilla engine I should set magic number like this:

  {"HR.WAD",        18, 0x01C09C98},
  {"STRAIN.WAD",    07, 0x01D6CF98},
It's difficult to implement in general case (may be later) and I am lazy to set them for all master levels right now, but it is not heavy and I shall make it later of course. Also I can publish my Doom95.exe which shows this number and implement facility in PRBoom to set it through command line.

Share this post


Link to post
entryway said:

done: test4

I don't get the "Buffer overrunning ..." message during demo playback any more on these two maps (hr18 and st07), but I did get it when playing normally (not recording) on another map (belltoll map02, when pressing one of the switches near the end). However, it does not appear to be duplicable (presumably the issue that triggers it isn't) - it didn't occur at the same point when I played through it again.

I also get the "Buffer overrunning ..." message when watching h2311552.lmp, even though the buffer overrun emulation no longer operates when playing that one back.

entryway said:

It's difficult to implement in general case (may be later)

I got the impression that you had done so, based on the fact that h2311552.lmp desynched in just the same way that it does with doom2.exe, and the fact that hr18-348 played back OK with the wad renamed (so no map-specific fix was applying, presumably; command line: c:\doom2\glboom hrdup hrmus hr18-348.lmp). This was with the glboom.exe with the date-stamp 20 November 2005, 12:59:10.

Share this post


Link to post

It occurs only if numspechit > 8.

// keep track of special lines as they are hit,
// but don't process them until the move is proven valid

// 1/11/98 killough: removed limit on special lines crossed
line_t **spechit;                // new code -- killough
int numspechit;
The reaction on spechits overrun will be customizable in 2.2.6.22

Share this post


Link to post

can the famous no clipping bug from one of the master levels be emulated ?

there are some occurences in e1m3 too

Share this post


Link to post
Grazza said:

and the consensus seemed to be that this wasn't going to be possible at all, as it depended on the exact workings of the compiler.

It's soudns like my last work and probably I can emulate it too. Just support me. Nothing else.

Share this post


Link to post

I think that might be possible; the "impossible" has been proven wrong before (Map07 speed and pacifist, or Doom playing MIDIs, for example.)

Grazza said:
fixing the error when recording with MBF compat (the header is wrong) and trying to improve the behaviour at start-up (turn-snap in software mode; hard to get any sort of quick start with either),

What was that glitch? What about being able to turn before the screen is loaded?

and maybe giving the user more options with respect to mouse acceleration (like Chocolate-Doom does).

This is important; it's always been possible with the DOS engine if you get the proper mouse drivers and is a feature by default in Windows 98 when using a standard mouse. But aside from that, it lets the player have a good balance between turning and flipping around. Otherwise you need either a sensitivity that makes small movements too loose and thus not as accurate, or that requires more than a wrist-flick to turn 180°.

Share this post


Link to post
myk said:

What was that glitch? What about being able to turn before the screen is loaded?

Yes, there's that for a start - no movement before 0.22 seconds. But I also find that it is hard even to get movement to start at 0.22 seconds without some luck - if I have a key pressed down a moment too early, it louses up and I don't move until I release that key. That's why my demos often feature no movement until about 0.3 seconds (or worse), and why I sometimes switch to Doom2.exe even though it means -nosound.

Regarding mouse acceleration, I recall someone (maybe Jon Rimmer) mentioning that there had been a change in Prboom 2.2.3 in the way this was handled. Maybe one thing that could be done is to give the user the option of having it the old way or the new way. Sorry, but I haven't looked into this too closely, as I'm happy with the current mouse behaviour myself.

Share this post


Link to post

I'm afraid I have a desync to report:
2s01n006
This Boom 2.02 demo (on 2sectors.wad) plays back OK with the final version of test3 but desyncs with all versions of test4.

The differences in the change logs are as follows:

test3 (last version):
[-] Bugs in dehacked support. (so, e.g., Hacx works)
[-] Compatibility bugs
[-] original PRBoom: compatibility issues

test4 (first version):
[-] Compatibility: desync on hacx3215.lmp (issues in dehacked support)
[-] Compatibility: desync on Sam Woodman's HMP Max demos (HX17-459.LMP etc)
[-] Compatibility: desync on umbrella.wad\um3nm152.lmp. PRBoom doesn't spawn the boom-specific "specials" in demo_compatibility mode now. (generalized scrollers, sector effects)
[-] Compatibility: desync on compet-n hr18-348, hr18-851, hr182206, hr182425, hr184144, hf184238 (buffer overrunning)
[-] Compatibility: desync on all strain.wad\map07 demos (no exit)

Edit: In fact, all five of Donce's demos linked to in this post desync with test4, so perhaps a general problem with Boom demos has been introduced.
Edit2: Yes, it looks that way. I haven't yet found a Boom demo that plays back with test4. My Icarus demos, ic10p005 and ic23-153 (both Boom-format) desync for instance.

Share this post


Link to post

Oops - I hadn't noticed the edit with the new test version until today.

Everything seems to work as intended: Boom demos play back again (I've only tested a couple though), and the two options regarding spechits function as described (tested with st07 and h231 demos).

I've made a few feature requests at the sf site. Just suggestions for things that I think would be useful.

Share this post


Link to post

2.2.6.22

[+] PRBoom compatibility: two new options for spechit overflow detection. It detects desyncs like compet-n\hr.wad\hr18*.lmp, all strain.wad\map07 demos etc. Desyncs of this type are not fixable generally because it depends on many parameters: demo was recorded with or without sound, for example etc.
[+] Added -levelstat switch for levelstat.txt output like this:

    E4M1 - 0:15.91 (0:15)  K:  8/63   I:  5/21  S: 0/2
    E4M2 - 0:10.97 (0:25)  K:  8/76   I:  6/22  S: 1/3
    E4M3 - 0:08.86 (0:33)  K:  1/140  I:  1/5   S: 0/22
    E4M4 - 0:32.43 (1:05)  K: 19/60   I: 11/23  S: 0/2
    E4M5 - 0:22.89 (1:27)  K: 10/73   I:  0/29  S: 0/2
    E4M6 - 0:23.66 (1:50)  K: 21/97   I:  0/4   S: 0/3
    E4M7 - 0:09.94 (1:59)  K:  6/97   I:  1/18  S: 0/4
    E4M8 - 0:33.94 (2:32)  K: 39/106  I:  1/6   S: 0/1
[+] New key binding for warp directly to the next stats screen. <End> by default.
[!] Option "step of speed change" has been restored. Two modes are available: stepwise and automatic.
[-] PrBoom dehacked support: wrong processing of Bits parameter if its value is equal to zero. No more desync on HACX demos.
[-] PrBoom compatibility: PRBoom doesn't spawn the boom-specific "specials" in demo_compatibility mode now (generalized scrollers, sector effects). No more desync on umbrella.wad\um3nm152.lmp.
[-] PrBoom compatibility: MF_JUSTHIT fix. No more desync on Sam Woodman's HMP Max demos (HX17-459.LMP etc).
[-] PrBoom: fix for turn-snapping bug on fullscreen in software mode. "..\Advanced HUD settings\Movements\Fix Turn-Snapping issue"
[-] PrBoom: deathmatch starts as unknown things with a complevel of 0, 1, 2 or 3.
[-] GlBoom: problems with transfering not flipped sky texture (line type 271) to tagged sectors. On war_3.wad\map14 for example.
[-] Mistake of processing of the "quick rewind" key if the player dies.

Share this post


Link to post

Great! Already downloaded and started trying it out. :)

Prboom-plus now has so many features, I'd say it deserves a news post. (Actually, it's long overdue.)

Share this post


Link to post

Grazza said:
I'd say it deserves a news post.

Let's wait for mouse acceleration first!

Share this post


Link to post

I don't understand. Why some people require mouse acceleration in games and why they do not like acceleration which it is possible to adjust through Control Panel.

I don't use an acceleration neither in doom, nor in quake1,2,3. And I use no_mouse_accel_fix.reg for WinXP.

REGEDIT4

[HKEY_CURRENT_USER\Control Panel\Mouse]
"SmoothMouseXCurve"=hex:00,00,00,00,00,00,00,00,00,a0,00,\
00,00,00,00,00,00,40,01,00,00,00,00,00,00,80,02,00,00,00,\
00,00,00,00,05,00,00,00,00,00
"SmoothMouseYCurve"=hex:00,00,00,00,00,00,00,00,66,a6,02,\
00,00,00,00,00,cd,4c,05,00,00,00,00,00,a0,99,0a,00,00,00,\
00,00,38,33,15,00,00,00,00,00

Share this post


Link to post

entryway said:
I don't understand. Why some people require mouse acceleration in games and why they do not like acceleration which it is possible to adjust through Control Panel.

Well, I have no way to change it from the Control Panel on Windows 98, just a pointer speed that has little or no effect on PrBoom. Plus even if I did I guess that'd modify the mouse in most contexts, when only the game should be affected.

I see the web is full of messages and articles about acceleration issues on XP or 2000, but that's from the persective of people who had experienced a non-accelerated mouse for games like Quake 2 on previous versions of Windows for those games. I had that issue when switching from Doom DOS to Doom Windows 98, till I started liking acceleration for the combination of slow small movements and fast long movements.

So, unlike XP users I'm playing on an environment where Windows games do not have acceleration, but DOS ones do. I can force the DOS engines to have no acceleration by planting a DOS mouse driver from autoexec.bat, but don't really want to use that. On the other hand, I have no way to accelerate the Windows DOOM engines (except Chocolate Doom now.)

Share this post


Link to post

bug report :

It crashes when you set game speed over 1000.

Either prevent the crash or make 1000 the maximum ?

Share this post


Link to post
VinceDSS said:

It crashes when you set game speed over 1000.

Permanently?

Share this post


Link to post

When I try to get over 1000, It crashes me back to winXP and closes prboom.

Share this post


Link to post

Crashes on my system, too; I'm thrown back to Win98. This is when running prboom.exe, and I'm nearly unable to test glboom because due to some mysterious reason it recently started to run VERY slowly, even at 320x200 I have no more than 3 fps when MAP01 loads (and speed is set to 100).

EDIT: I re-extracted the contents of prboom-plus-2.2.6.22-win32.zip to Doom2 dir, and now I'm able to go all the way up to 10000. But glboom is still unusably slow.

Share this post


Link to post
VinceDSS said:

When I try to get over 1000, It crashes me back to winXP and closes prboom.

I confirm. It happens in original PrBoom too. Only in version 2.2.6.

Share this post


Link to post
Donce said:

I'm nearly unable to test glboom because due to some mysterious reason it recently started to run VERY slowly, even at 320x200 I have no more than 3 fps when MAP01 loads

what's your system?

Share this post


Link to post

2.2.6.23

[+] Dehacked support: Monsters infight.
[-] PrBoom: It crashes when you set game speed over 1000.
[-] "-warp" switch didn't work. (the bug was introduced in 2.2.6.22)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now