PrBoom-Plus, ver. 2.5.1.4

Grazza said:

and trying to improve the behaviour at start-up (turn-snap in software mode)

done

Share this post


Link to post

test build
(!) Option "step of speed change" has been restored. Two modes are available: stepwise and automatic.
(-) Bugs in dehacked support. (so, e.g., Hacx works) Tested only with hacx3215.lmp
(-) PrBoom: Turn-snapping bug on fullscreen in software mode. "..\Advanced HUD settings\Movements\Fix Turn-Snapping bug"

Share this post


Link to post
entryway said:

(!) Option "step of speed change" has been restored. Two modes are available: stepwise and automatic.

This works fine - thanks.

(-) Bugs in dehacked support. (so, e.g., Hacx works) Tested only with hacx3215.lmp

The one specific issue I was aware of appears to be fixed, and the fact that hacx3215 now works must be a very good sign indeed.

Share this post


Link to post

Unfortunately, there still seems to be a slight glitch with Hacx compatibility. See this post. I don't know what the cause is, and maybe it's just something that works a tiny bit differently. Presumably it's something that is wrong in all Boom-based ports.

Share this post


Link to post
Grazza said:

Unfortunately, there still seems to be a slight glitch with Hacx compatibility. See this post. I don't know what the cause is, and maybe it's just something that works a tiny bit differently. Presumably it's something that is wrong in all Boom-based ports.

I fixed this but am not totally sure the fix has no side effects.
test2

Share this post


Link to post

Where can I get demos which desync in prboom 2.2.6? (not monster_avoid_hazards desyncs)

Share this post


Link to post
entryway said:

I fixed this but am not totally sure the fix has no side effects.
test2

I tested the following Hacx demos with this new version:
All Sam Woodman's HMP Max demos: OK!
hacx3215: desyncs on map03 (edit: this was an error on my part - it is OK)


It seems you hit the nail on the head, and the fact that this impacts hacx3215 is not really a surprise - fixing a bug introduced in Boom or MBF will naturally lead to desyncs with Boom or MBF demos.

I'd suggest therefore making this fix only apply for -complevel 0 and -complevel 1, and thus leaving Boom and MBF compatibility intact.

What does this fix affect? Is it just something in the dehacked support? If you let me know what it changes, I can test it with some more demos where it might make a difference (STRAIN, for instance).

entryway said:

Where can I get demos which desync in prboom 2.2.6? (not monster_avoid_hazards desyncs)

I can only think of the following:
compet-n: hr18-348, hr18-851, hr182206, hr182425, hr184144, hf184238;
DSDA: h2322437 (on the HR2 beta).

Share this post


Link to post
Grazza said:

hacx3215: desyncs on map03

works fine for me.
glboom.exe -iwad doom2.wad -file hacx.WAD -deh HACX.DEH
(not -deh HACX_F.DEH)

What does this fix affect? Is it just something in the dehacked support? If you let me know what it changes, I can test it with some more demos where it might make a difference (STRAIN, for instance).

.\linuxdoom-1.10\p_inter.c\void P_DamageMobj(...)

    ...  
    if ( (P_Random () < target->info->painchance)
	 && !(target->flags&MF_SKULLFLY) )
    {
	target->flags |= MF_JUSTHIT;	// fight back!

	P_SetMobjState (target, target->info->painstate);
    }
    ...
.\prboom-2.2.6\p_inter.c\void P_DamageMobj(...)
    ...
    if ( (P_Random () < target->info->painchance)
	 && !(target->flags&MF_SKULLFLY) )
	P_SetMobjState (target, target->info->painstate);
    ...
    target->flags |= MF_JUSTHIT;	// fight back!
 

Share this post


Link to post
entryway said:

works fine for me.
glboom.exe -iwad doom2.wad -file hacx.WAD -deh HACX.DEH
(not -deh HACX_F.DEH)

Oops yes, sorry. I was being dopey there and forgetting the previous issue. One day I'll learn how to do two things at once. :p

Any chance of explaining the change in more non-coder-friendly form?

Share this post


Link to post
Donce said:

Here you can find a demo that was recorded with doom2.exe, plays back with it but desyncs with PrBoom or Eternity.

Share this post


Link to post
Grazza said:

Any chance of explaining the change in more non-coder-friendly form?

From what I gather from the code, in linuxdoom, monster fight back when hurt, in prboom, they fight back when shot at.

Share this post


Link to post
Donce said:

Here you can find a demo that was recorded with doom2.exe, plays back with it but desyncs with PrBoom or Eternity.

test3
glboom -file umbrella.WAD -playdemo UM3NM152.LMP

PRBoom doesn't spawn the boom-specific "specials" in demo_compatibility mode now. (generalized scrollers, sector effects)

Share this post


Link to post
entryway said:

This new version is missing some of the things that were in the previous version. Namely:

[!] Option "step of speed change" has been restored. Two modes are available: stepwise and automatic.
[-] PrBoom: Turn-snapping bug on fullscreen in software mode. "..\Advanced HUD settings\Movements\Fix Turn-Snapping bug"

At least, these menu options are gone.

The "Umbrella" fix works fine for me.

Share this post


Link to post
Grazza said:

This new version is missing some of the things that were in the previous version. Namely:

Yes, because I fixed this desync today at work. Without the latest source codes.
test3

Share this post


Link to post
entryway said:

Where can I get demos which desync in prboom 2.2.6? (not monster_avoid_hazards desyncs)

One more, as mentioned in my post here: Teeth-32 (on Teeth). Edit: also all demos on STRAIN map07, because the exit doesn't work.

If you're looking for more things to add as options in Prboom-plus, then one possibility is to make it more forgiving of tag errors. There have been quite a lot of maps released in the last couple of years with such errors, presumably due to them only being tested in Zdoom (although intended to be for Doom(2).exe, limit-removing or Boom-compatible). I'm not 100% sure it is a good idea to add in this compatibility option, but it would make these maps playable (or playable as the author intended). Examples include excorpse, tremor, hellcore (map01 and maybe others too) and I think dmdjm02 too. There's also Cchest2 map24, though the issue there wasn't tags, but a switch that couldn't be pressed because it was behind a scrolling texture.

Share this post


Link to post
entryway said:

Well, you're working quickly :)

I never play with PrBoom, but I often use it for demo playback (and analysis), so kudos.

Share this post


Link to post
Grazza said:

One more, as mentioned in my post here: Teeth-32 (on Teeth). Edit: also all demos on STRAIN map07, because the exit doesn't work.

please, submit it there

If you're looking for more things to add as options in Prboom-plus, then one possibility is to make it more forgiving of tag errors.

and there

But at the moment I am "preparing" my Doom95.exe for "cooperative" with me and I'll try to fix hard-core desyncs at a hr18* on the nearest days.

Share this post


Link to post

entryway said:
But at the moment I am "preparing" my Doom95.exe for "cooperative" with me

What does this mean?

Share this post


Link to post
myk said:

What does this mean?

*reverse engineering*
For logging some parameters.

Share this post


Link to post

I have fixed *generally unfixable* desyncs in all demos on the strain.wad\map07 and hr.wad\map18.
Hehe, I am The One! :)

Share this post


Link to post

great job man,

maybe you could share your discoveries with eternity, prboom and chocolate doom :)

besides that, some suggestions :
- when playing back demos, allow one key to warp directly to the next stats screen (useful for gathering stats w/o having to wait for the end of the map)
- add one option for timetable txt output like this one :

Map Time Added Kills Items Secrets Health Armor MMH Alive
--- ---- ----- ----- ----- ------- ------ ----- --- -----
MAP01 00:50.62 00:50 100% 66% 100% 100% 66% 51% 0
MAP02 01:25.00 02:15 84% 57% 100% 132% 100% 50% 0
MAP03 01:43.05 03:58 89% 30% 100% 200% 160% 62% 0
MAP04 01:14.60 05:12 89% 54% 100% 148% 166% 110% 0
MAP05 03:00.45 08:12 89% 85% 100% 125% 193% 75% 0
MAP06 03:24.31 11:36 86% 52% 100% 200% 200% 7% 0
MAP07 01:18.40 12:54 100% 28% 100% 200% 200% 124% 0
MAP08 03:34.77 16:28 87% 80% 100% 200% 168% 164% 0
MAP09 05:32.40 22:00 85% 80% 100% 146% 131% 38% 0
MAP10 07:17.60 29:17 83% 69% 100% 200% 200% 62% 0
MAP11 04:27.51 33:44 93% 63% 100% 188% 138% 80% 0
MAP12 05:26.88 39:10 96% 80% 100% 148% 56% 49% 0
MAP13 06:47.91 45:57 96% 34% 100% 200% 138% 35% 0
MAP14 02:45.77 48:42 85% 100% 0% 133% 161% 51% 0
MAP15 07:45.82 56:27 83% 88% 90% 174% 176% 49% 0
MAP31 02:57.91 59:24 84% 10% 100% 187% 45% 37% 0
MAP32 01:10.85 60:34 42% 100% 100% 200% 200% 179% 0
MAP16 04:55.91 65:29 66% 80% 100% 182% 182% 82% 0
MAP17 06:20.62 71:49 86% 78% 100% 197% 198% 49% 0
MAP18 04:52.14 76:41 64% 50% 100% 200% 200% 64% 0
MAP19 05:30.05 82:11 95% 32% 100% 155% 200% 74% 0
MAP20 06:17.94 88:28 84% 66% 100% 200% 200% 120% 0
MAP21 03:40.42 92:08 60% 72% 0% 200% 200% 51% 0
MAP22 02:00.14 94:08 89% 25% 100% 194% 92% 82% 0
MAP23 04:59.94 99:07 70% 54% 100% 200% 175% 11% 0
MAP24 07:52.71 106:59 97% 69% 100% 200% 200% 72% 0
MAP25 03:11.40 110:10 66% 100% 100% 82% 95% 52% 0
MAP26 06:17.54 116:27 93% 74% 100% 97% 82% 61% 0
MAP27 06:45.74 123:12 94% 75% 87% 200% 2% 64% 0
MAP28 06:47.20 129:59 83% 72% 100% 136% 136% 14% 0
MAP29 07:19.28 137:18 92% 84% 0% 89% 38% 7% 0
MAP30 01:51.51 139:09 1500% 77% 0% 200% 200% 84% 9
--- ---- ----- ----- ----- ------- ------ ----- --- -----

Total time: 139:09
------

this comes from AdamH, when he checked the 30fanet1 for living monsters.
It is better aligned when in a regular TXT

Share this post


Link to post

VinceDSS said:
maybe you could share your discoveries with eternity, prboom and chocolate doom :)

He's doing that; all fraggle and Quasar (plus cph if they ever update prboom again) have to do is take it from the source found on sourceforge.

Share this post


Link to post

test4

[-] desync on compet-n hr18-348, hr18-851, hr182206, hr182425, hr184144, hf184238
[-] desync on all strain.wad\map07 demos

Buffer overrunning in the vanilla doom2 engine for these levels will not only be found out but also emulated.

Share this post


Link to post

I've fixed the link in the above post so that it now points to the new test version, rather than the previous one. :)

For the STRAIN map07 demos, the program pops up a message (in a new window) about the problem at the point where the exit would have failed. I'm not sure if you meant to leave that in for this test version.

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

Share this post


Link to post
Grazza said:

For the STRAIN map07 demos, the program pops up a message

in which demos? I test it only with STR07-UV.LMP from struvlmp.zip and STRN-BS7.LMP from strn7455.zip

glboom.exe -file strain.wad -deh strain.deh -playdemo STR07-UV.LMP
glboom.exe -file strain.wad -deh strain.deh -playdemo STRN-BS7.LMP

STRAIN.WAD 13,502,597 03.07.97 14:51

Share this post


Link to post

The message is:

Buffer overrunning in the vanilla doom2 engine for this map has been detected but not supported.The demo can be desync soon.Thanks and I've shut up.

It occurs in both demos that I've tested: st07-237 (in stmax-av.zip) and str07-uv (in struvlmp.zip). The demos do play back OK - they just get interrupted by this message, and once the message is cleared, they continue.

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.

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