Blondie

The new software mlook code distorted the sky in widescreen resolutions. Added to the tracker: https://sourceforge.net/p/prboom-plus/bugs/229/

And since Memfis mentioned it (thanks, Memfis!), could somebody who still has Grazza's translucent things dehacked patches upload them somewhere, just in case Andrey decides not to implement a config variable? Grazza's old post contains broken links to both: http://www.doomworld.com/vb/showthread.php?s=&postid=593019#post593019 I still believe that PrBoom needs a way to universally disable transparent sprites internal to the engine, though, because having to use dehacked patches is inconvenient, unreliable, and confusing — particularly to anybody who isn't aware of them. Edit: Nevermind. Myk attached the file here: http://www.doomworld.com/vb/showthread.php?s=&postid=871780#post871780

That would work, although inconvenient. Wouldn't it just be easier to add a config variable that toggles sprite translucency in software mode? I don't see why this can't be done since transparent sprites are already universally disabled in GL mode. Edit: Or you could simply expand the preexisting compat option "comp_translucency" to apply to all complevels. Either way, I think that transparent sprites need to be universally togglable in the engine itself for software mode users with legacy hardware.

This is unrelated to what you guys were discussing, but would it be possible, e6y, to create a config variable to force transparency off for Boom's translucent sprites in software mode? I know that "comp_translucency" technically already does this, but the problem is that it doesn't work at either the Boom or MBF complevels, which are the two complevels I use for playing Boom-compatible WADs. The reason I ask is because I play on an old computer with a single-core CPU, and I get severe framerate drops whenever a lot of transparent sprites are on the screen at once, such as the plasma gun being fired at close range. Transparent sprites are already disabled at all complevels in OpenGL mode due to the sprites/walls sorting bug in GLBoom, but there is no way for me to achieve this in software mode other than to disable translucency altogether, which I don't want to do. A config variable like "sprite_translucency," however, would easily solve this problem for those of us who still use legacy hardware and prefer the software renderer. Thanks in advance.

Bug: Spectres flicker in certain situations when using the new shaders light mode. See the red key room in E1M6 DOOM.WAD as an example. Added to the tracker: https://sourceforge.net/p/prboom-plus/bugs/228/

Looks like it. Thanks, e6y!

Strange. I changed my DOOMWADDIR environment variable path from "C:\Games\DOOM\" (PWADs subfolder) to "C:\Games\DOOM\WADs\" (DTWID subfolder), and I still get the same issue: Here are my exact paths and command line as of now: This is definitely some sort of bug introduced by 2.5.1.4.test, because I do not encounter this problem with 2.5.1.3. If I remove the .deh file from the command line, it loads as expected. However, inclusion of a .deh or .bex file in the command line via my DOOMWADDIR path results in a crash. I'm using Windows XP SP3, if it makes any difference.

Just wanted to add that this bug appears to only affect environment variables. When loading a .deh file with an exact path, the game launches as normal. However, when I abbreviate per the path specified by my DOOMWADDIR environment variable, it crashes. I don't experience this issue with either iwads or pwads, only dehacked patches and boom extensions.

I'm encountering a bug with the latest prboom+ test release that causes a crash when loading a .deh or .bex file. Error message:

You can try using the default complevel and setting comp_moveblock to 1 in your cfg. You won't be able to disable Boom's ledge behavior, unfortunately, but it may solve the clipping issue you're experiencing.

Are you using complevel 11? If so, there is a bug at that complevel introduced by Lee Killough's recoded clipping behavior for MBF (monsters can respawn and resurrect on top of stuff). A compatibility option was later added with PrBoom that disables MBF's buggy clipping (comp_moveblock), but unfortunately, the complevels that acknowledge it also suffer from the ledge compatibility bug.

That's a really old PrBoom bug. If I remember correctly, it was introduced when high color modes were added. It actually affects all weapons, not just the plasma gun. Never_Again and myself both reported this to e6y on the PrBoom-Plus bugtracker, but it has never been addressed because fixing it would involve disabling color modes above 8-bit (I think?). The only two resolutions at which this bug does not occur are 320x200 and 640x400. However, the prevalence of the bug varies per resolution, as you've already noted with 640x480. If you want to use non-standard DOOM resolutions in software mode, my only suggestion would be to use a resolution where it is least noticeable and try to ignore it. Personally, I play at 848x480 with the default aspect ratio, and it doesn't bother me too much. Here's the link to my bugtracker report: http://sourceforge.net/tracker/?func=detail&aid=3004102&group_id=148658&atid=772943

All December 10th raven-branch releases are missing the exes. Was this an accident?

Fantastic! It looks like we've identified the culprit of the reduced framerate in directx boxed fullscreen resolutions: now that only the game image illuminates, excluding borders, directx 32-bit runs smoothly at all resolutions, including 1280x1024. However, 8-bit modes still illuminate the borders, and I suspect this could be what impacts directx 8-bit with the aforementioned stuttering, although I may be wrong. It's odd, though, that directx 32-bit outperforms windib 32-bit, since it's usually the reverse for me. Try 32-bit windib, instead of directx. On my machine, directx 32-bit performs as expected at all desired resolutions, now that fraggle addressed the framerate problem, but windib 32-bit still chokes on high resolutions. I'm running on XP32 with a 2.2ghz AMD Athlon, 2gbs DDR400 SDRAM, and a Sapphire ATI HD 3850 AGP video card.

Unfortunately, it's still present, and quite noticeably, in Chocolate Doom's 8-bit windib mode, although the severity appears to differ between each setup. In my case, the bug is so pronounced as to render this mode entirely useless, because the constant intermittent pauses during palette changes halts fluid gameplay altogether. The inclusion of a 32-bit mode has nonetheless provided a workaround, though.