bradharding

Yes, it was intentional because I know DirectSound works. (I was only using the standard putenv() until yesterday.) But you're right, it may be worth setting it to false, and then I'll output to console if the variable has changed.

Windows 10 Home Build 1803, WASAPI, getting the "cartoon" sounds. I believe I got a similar report from a user after the release of SDL 2.0.6. After a bit of research on https://discourse.libsdl.org/ I force Windows to use the DirectSound driver (putenv("SDL_AUDIODRIVER=DirectSound")). Although that user hasn't got back to me, nobody else has reported anything similar. Edit: Switching to WASAPI in DR by not setting the SDL_AUDIODRIVER environment variable gives me the cartoon sounds.

Hi JhosephX. I've looked into this problem and the reason why its not working is because of how DoomRunner constructs the command-line. To run Plutonia 2, it'll do something like this: doomretro.exe -iwad plutonia.wad -file -deh pl2.wad Having that extra -deh there makes no sense to me. I'd recommend using another launcher, or opening doomretro.exe directly. (If both plutonia.wad and pl2.wad are in the same folder, you can just double-click on pl2.wad and you're away.)

Thanks for letting me know. Just checked myself, and they are indeed levitating. I'll look into it.

I disagree, but I'll consider a CVAR. :P I'll look into this. I might do it by implementing a different action that can be bound to the 3 key. No, sorry. I want to keep sound the way it is tbh. Thanks for the suggestion. I'll consider another CVAR.

I've decided to rerelease v2.7.1 with these fixes, rather than yet another point release so soon after the last one. Thanks again guys. Please let me know if you have any further issues.

DOOM Retro uses a subtle gradual lighting effect under all doors. It does it by using the light levels of the darkest and lightest adjacent sectors of the door, and in this case its sectors 49 and 97. I'll look into a solution, thanks. What might be better is to use the darkest adjacent sector, but don't get any lighter than the light level of the door. Shit. Back to it then. I'll check out the behavior of the shotguns too. Thanks again!

DOOM Retro v2.7.1 has been released, fixing player movement when using a gamepad.

Thanks for the report. I swear I tested using an Xbox 360 controller after implementing that feature... :/ Oh well, I'll work on a fix and upload a small point release as soon as I can. Controls can't be bound in that way in DR, as only one weapon can be bound to one control (eg. bind dpadright +weapon4) I'll consider implementing them as default, though. As for shotgun priority, the last shotgun to be selected is the one that will come up when using that bind.

After over 4 months of development, I'm happy to announce v2.7 of DOOM Retro is now available for download! This version sees the inclusion of E1M4B: Phobos Mission Control and E1M8B: Tech Gone Bad, some significant performance improvements, and much more. Please visit www.doomretro.com for the link and complete release notes. Big thanks go to John Romero, The Last Cabra, Death Egg, David Carlier and Julia Nechaevsky for their help and support.

Doom Retro will automatically load it afterwards as needed. You can check the load order by opening the console ingame.

Nothing has been intentionally changed in regards to movement. Vsync is enabled by default, however, which can introduce some input lag. Try entering vid_vsync off in the console.

I managed to fix this, tracing down the problem to P_PointOnLineSide() in p_maputl.c. The upcoming version of DOOM Retro will run this fine now.

Very unusual. I just tried it myself, and yep, -5%. I'll look into what's causing it.

I haven't been able to reproduce it.