PrBoom-Plus, ver. 2.5.1.4

[Maes]

Regarding nuts.wad, Jodwin prompted me to try PrBoom-Plus claiming that nuts.wad now ran seamlessly like any other WAD, which would mean that there's a massive improvement in the monster handling code over any other source port out there (AFAIK, monster AI complexity is not exactly linear but rather quadratic).

I tried it on both the normal and gl version with the default settings, and it just slowed to a crawl as soon as the monsters were awakened, just like any other source port would do.

I initially called BS or theorized that the benefit only works on multi-core CPUs (I have a single-core Athlon), but then I asked Jodwin to send me his cfg files and then it worked smoothly for me too....thinking it was the graphics in GL mode, I upped them again but it still ran smoothly.

No idea what caused the initial slowdowns :-/

So...does this mean we're getting official nuts.wad speedruns now? :-p

[myk]

Maes said:
No idea what caused the initial slowdowns :-/

There's an option that makes monsters check if their buddies are in trouble, so they may go help them (help_friends). This eats up a lot of processor power as each active monster is making this check against the others. Jodwin probably had default_compatibility_level 9 (Boom behavior) in his CFG, and Boom doesn't apply that option, which was added later, for MBF.

The default behavior should be default_compatibility_level -1 (latest) with help_friends 1 (enabled).

[Maes]

Then this option must be present in other Boom-compatible ports as well?

I guess it falls into the more general problem of N-body simulations.

I once had to deal with a program simulating gravity ineractions between animated objects, and going over a few hundred was problematic due to the quadratic complexity. There are however optimization methods for this sort of problems, it would need some clever adaptation for Doom monsters however.

[myk]

Maes said:
Then this option must be present in other Boom-compatible ports as well?

Not necessarily, as it's an MBF option and Boom supporting engines that aren't also heavily MBF-based (as PrBoom and Eternity are) only take bits and pieces from MBF, such as the sky transfer effect that allows more than one sky type per level. Slowdowns on other engines might be due to other reasons, though.

[GreyGhost]

After several weeks of grumbling to myself and re-adjusting settings in the master volume panel, I finally took the time to find out what's altering the Software Synth mixer input level behind my back - so far I've turned up three culprits. PrBoom-Plus (2.5.0.2) is the worst offender - setting the input level to zero - while Chocolate Doom and PrBoom both reduce the input level, though not by much. Is there a work-around for this issue or is it an addition to the to-do list?

[myk]

What OS are you using? The SDL engines never do that to me, but I'm using Windows 98 and a Sound Blaster 32. I do know that PrBoom 2.02, which I don't really use, ties its sound volume to my system's, messing with it.

[GreyGhost]

I'm using XP Pro (SP3) and Realtek HD integrated audio. It appears that PrBoom-Plus is setting the SW Synth input level to about 33% while running and zero when closing down. It's something I first noticed when playing midi tracks in XWE or IrfanView resulted in dead silence - other midi players that use the Wave input aren't affected.

[Graf Zahl]

That's an effect I only had with Allegro so far. SDL sound always has been working fine for me.

[Maes]

So other that PrBoom-Plus, are there any other source ports that can/could handle nuts.wad (or similar maps) without going into an O(n^2) hell? To my surprise I discovered that even "normal" PrBoom can handle nuts.wad with the help_friends option off, while ZDoom and its derivatives seem to ignore it and go into a slowdown hell.

Vanilla and chocolate are able to run it "smoothly", if it weren't for the fact that most sprites aren't even displayed :-p

[entryway]

software prboom ~= prboom+ - about 120 fps (timedemo)

GL glboom about 3-10x slower in comparison with glboom+ on nuts.wad

glboom+ is faster than prboom+ (about 50%)

so there is no difference between prboom and prboom+ in case of software, but with GL renderer glboom+ is much faster

[Maes]

Still, other than for MBF compatibility and that togglable option, why does ZDoom slow to a crawl on nuts.wad? Given enough CPU horsepower, even vanilla and chocolate doom can play nuts.wad in realtime, but ZDoom has a quadratic slowdown, as does PrBoom with that option on. Monster handling should be (almost) linear except if similar obscure options are applied in other ports.

I would exclude sprite drawing alone, because until the monsters are awakened, even ZDoom is able to smoothly draw the 1000s of sprites on a 3 GHz system. Once awakened however it becomes VERY slow (even in the automap), so it's not the rendering subsystem.

[entryway]

Maes said:

I would exclude sprite drawing alone, because until the monsters are awakened, even ZDoom is able to smoothly draw the 1000s of sprites on a 3 GHz system. Once awakened however it becomes VERY slow

On LongDays.wad gzdoom is 1 fps BEFORE awakening.

[Maes]

Noticed, which is weird because the total monster count is more or less that of nuts.wad, although the scale of the level and the monster arrangement is different (nuts.wad had two independent rooms, not all 10000 monsters in one room). The layout of the level is also different, with most of the monsters being in plain view in an area that's actually larger than the whole of nuts.wad

In any case, I guess that with such monster counts every minor flaw or inefficiency in a Doom engine comes to light dramatically.

[Quasar]

Toggling any of the AI comp and monster options in EE only makes a 2-3 FPS difference at most in the running of nuts.wad. On my system (Athlon 64 2 GHz) the first room runs about 2.8 FPS with help_friends, and about 4 FPS without. The option controlling monsters giving up pursuit of targets seems to make an additional small difference.

None of the options makes a large difference however. And none of them make a dent in the second room, which in EE running with a 16 MB heap slows down to 0.75 FPS due to thrashing of the zone heap (too many bullet puffs and arch-vile flames). Performance is significantly better with a 32 MB or greater heap, however.

[entryway]

The new version of PrBoom-Plus could be found on:
http://sourceforge.net/projects/prboom-plus/

Change Log

2.5.0.3 @ 2009 Jul 11

[+] Simple shadows, from Doomsday.

[+] New "Fog Based" sector light mode which is very similar to software mode. If it doesn't work correctly, try updating your drivers or replacing your ATI, because per-pixel fog (GL_NICEST) doesn't work with some ATI cards or their drivers.

[+] New map_always_updates config variable that can be toggled between updating unexplored parts in automap mode or the classic behavior.

No multisampling in automap mode.

Speed improvement in OpenGL mode: ~25% on nuts.wad, 7% generally.

Automap drawing optimisation in GL mode: 220 fps instead of only 30 on map05 @ dv.wad after IDDT IDDT.

[-] Fixed middle texture bug on Claustrophobia 1024 map06, sector 39.

[-] Fixed desynch on longdays.wad (-emulate 2.5.0.1/2 for viewing demos recorded with buggy versions).

[Creaphis]

Bah. I just went through the trouble of configuring 2.5.0.2, like, yesterday.


Regardless of that I appreciate your efforts.

[Doom_user]

The "Fog Based" sector light mode kicks ass. I've been waiting for something like it for years.

[entryway]

Doom_user said:

The "Fog Based" sector light mode kicks ass. I've been waiting for something like it for years.

Anyway it has some problems, but I prefer to accept these problems instead of shitty plain sector brightness. Dark levels are awesome now. And you can see near walls even with brightness 0

[Grazza]

Creaphis said:

Bah. I just went through the trouble of configuring 2.5.0.2, like, yesterday.

No problem. Keep the cfg file(s) and just replace the exe(s) and anything else that has changed (normally it's just the exes).

[entryway]

If I try to edit the first post of this topic I have following message, heh

The administrator has specified that you can only edit messages for 1051920 minutes after you have posted. This limit has expired, so you must contact the administrator to make alterations on your message.

[Creaphis]

Okay, 2.5.0.3 runs Nuts3.wad a little bit TOO well. It's kinda freaky.

[GreyGhost]

<unsolicited testimonial> Also works very nicely with map 5 of Holy Hell - which normally lurches about drunkenly on my less-than-top-of-the-line-with-integrated-video system. Thought I'd launched map 1 by mistake. </unsolicited testimonial>

BTW - I use this freebie to syncronise config files.

[myk]

That might be of use, although I've never had any problems keeping a constant CFG file for any Doom source ports, as Grazza suggested, since the engines just add any new settings in their default value without messing with anything else. This has historically allowed me to easily transfer my preferred settings between related engines, such as from ZDoom v1.22 to ZDaemon, Doom to Chocolate Doom, ZDoom to Skulltag, or PrBoom to PrBoom+, if not vice versa.

[Reaper978]

The only thing I dislike about PrBoom is the fullscreen hud.

Is there any way to get it like Zdoom's? This one's just a bit crowded and wonky for me.

Also, the sound didn't work when I tried a demo. Hrm...

[Grazza]

Reaper978 said:

The only thing I dislike about PrBoom is the fullscreen hud.

Is there any way to get it like Zdoom's? This one's just a bit crowded and wonky for me.

Not completely sure what you mean, but I'm guessing the Boom-style HUD, which IIRC Andrey's default cfgs have in "distributed" style. Press the F5 key a few times to cycle through the various layout options.

[Reaper978]

Thanks for letting me know about that.

[TimeOfDeath]

I keep getting this error:

P_StartButton: no button slots left!

What does it mean? The error shows after prboomplus crashes. It happens at the same part in a map - there are a bunch of shootable switches - played with complevel 9.

[myk]

See here. If you're getting that in Boom compatibility we can only guess Boom didn't raise that particular limit.

[TimeOfDeath]

Gah.
Thanks myk. I should've tried searching.

[Xenaero]

Something interesting...

When I create a DOOMWADDIR system variable to point to my WADs directory (because I like organized things) that contain all of my IWADs, Prboom+ recognizes them all, save for doom.wad. I checked the md5sum in case that was the problem, and verified that it IS inside the folder, but for some crazy reason, it won't recognize it. The md5 came back as matching the proper version, so what I did next was interesting. I copied doom.wad to my prboom+ folder and behold, it works!

So I guess it doesn't like it when doom.wad is outside the prboom+ folder?

EDIT: I found out I could edit the prboom-plus.cache file! DOOM.WAD had a value of "3, 0, 1" listed, so I looked at the other IWADs, and after changing that to "0, 0, 1", it shows up in the launcher as a usable IWAD. :)