coelckers / prboom-plus Goto Github PK

This was reported by maxmanium a while ago (see this: https://www.doomworld.com/forum/topic/110955-building-glboom/ ) , and I noticed this today as well.

Prboom_plus.exe does not get built along with glboom_plus.exe. According to mental this was actually done on purpose, but I think adding it might be a good idea since some people do want to use it.

There is also another issue, the .exe was renamed which is very misleading. The executable that gets built is NOT prboom_plus.exe but glboom_plus.exe, just renamed. If there is no desire to support building prboom_plus.exe as well, this can just be closed I guess.

But I do believe the .exes should have their original names restored...

So, I have managed to compile a build with yesterday's master .zip, and although things are in place, there are some issues.

Notably, Portmidi does not play any music once switched to it. Music simply stops. The soundfont is also missing after the building process finishes, although it can easily be grabbed from 2.5.1.5 or the web.

Essentially what the title says. I've always found it a bit disappointing that the more conservative ports only allow it to be increased and not decreased. Lower gamma correction is pretty cool for playing the IWADs and IWAD styled WADs.

It would also be much appreciated to have the ability to also decrease the level of gamma. As far as I'm aware you cannot currently do this, which means you might have to cycle through all levels multiple times occasionally until you find something fitting - unfortunately, that means going all the way to level 32 in the case of some GlBoom sector light modes.

I think more sector light modes would be another great addition. As it stands GlBoom only offers 4 so far, FOG-BASED, SHADERS (essentially PrBoom's take on emulating software sector lightning, but it's not as good as it is in GZDoom, things in the distance tend to look too dark... ), GLBOOM, and GZDOOM, which appears to essentially be GZDoom's "Standard" sector light mode.

I think it would be fair if this had the output of svn log added as e.g. a ChangeLog file.

This was reported yesterday against the prboom-plus Debian package (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961031). There is already a patch available for the first issue (251 on Sourceforge). For the latter two it makes probably sense to limit the number of tics which are meant to be sent over network to a reasonable amount, e.g. 35 (i.e. a second worth of gameplay, such a lag would make the network game unplayable anyway).

Dear Maintainer,

Description:
"An issue was discovered in e6y prboom-plus 2.5.1.5. There is a buffer
overflow in client and server code responsible for handling received UDP
packets, as demonstrated by I_SendPacket or I_SendPacketTo in
i_network.c."

URLs:

• https://logicaltrust.net/blog/2019/10/prboom1.html
• https://sourceforge.net/p/prboom-plus/bugs/251/
• https://sourceforge.net/p/prboom-plus/bugs/252/
• https://sourceforge.net/p/prboom-plus/bugs/253/

Essentially a GZDoom "Truecolor Software Render" equivalent. This is likely a lot of work to get implemented, but I think it would be worth the investment in the future.

There are currently more software video modes (8-bit, 15-bit, 16-bit, 32-bit, and of course OpenGL), but... they all look the same, except for 16-bit I think, that one supposedly adds a green tinting effect for some reason.

The OPL emulatior implementation in Chocolate Doom has been replaced with Nuked OPL3 v1.8 for better performance and accuracy. It might be a good idea to do the same here.

The secret notification in PrBoom has always been placed in a very unintuitive spot compared to other ports.

I think it's finally time to make it more visible by placing the menu entry elsewhere, where it can be easily discovered. It's in such a bad place many people still don't know how to enable the notifications up to this day, let alone that PrBoom even has such a feature.

A long-standing issue that I once brought to entryway's attention who shrugged it off as "a Prboom's bug". Affects the software renderer in resolutions other than 320x200 and 640x400. Most evident when the plasma gun bobs up and down while you walk.

Own ticket on the original tracker
https://sourceforge.net/p/prboom-plus/bugs/136/

Blondie's ticket ibid
https://sourceforge.net/p/prboom-plus/bugs/160/

Discussed several times on DW:

Gray bar on top of the chaingun?

In the original Prboom-plus thread:
example 1
example 2
RjY's explanation

Example pics:

As a workaround I'm using a custom prboom-plus.wad, with three edited sprites of the plasma gun and the chaingun (the center of the bottom line of each painted black): prboom-plus.zip

I have noticed that using the OpenGL renderer results in Boom's translucent things to render as solid. I investigated the reason for this and found an old thread from 2012 that @fabiangreffrath made: https://sourceforge.net/p/prboom-plus/bugs/218/

According to Blondie:

"Boom's translucent things (imp fireballs, plasma, teleporters, etc.) are permanently disabled at all complevels in OpenGL mode because GLBoom cannot sort sprites and walls at the same time."

Fortunately, Blondie provides a DEH patch that can force translucency to be enabled/disabled, but I suspect this is just supposed to be a bandaid solution.

Upon being asked about how to solve the issue, Blondie replied

"You'll have to ask Andrey for the specifics. I reported the "smooth sprite edges" bug years ago to confirm if it was another manifestation of the sorting issue, and indeed it was. I also requested a config variable years ago to toggle GL sprite translucency, but it was never implemented. Doesn't matter, though, because those dehacked patches work just as well."

I thought I'd bring the topic up again, in hopes that someone has an idea of how to solve the root cause

When using -warp 2 1 in the command line to start on episode 2 with the normal doom.wad iwad, after completing the level it took me to E1M2 instead of E2M2. See attached save, which is right at the exit. This result is present in PrBoom-Plus 2.5.1.7um but not the last original release, 2.5.1.5.test, even when using the same savefile.
prboom-plus-savegame0.zip

I figured it might be useful to have this option for compiling as well, similar to Raze, if it's possible.

Full explanation on Doomworld forums
There was supposed to be a community debate on whether friendly monsters should count as monsters for purpose of 100% kills completionism, but no one seems to care. Still, the inconsistencies and glitches outlined in that post should be fixed - your choice how you wish to handle it.

Greetings,

I noticed pretty big performance hits in prb2517, especially in larger maps, which I've traced back to the switchover to cmake.

Here's an example, using prb2517 from this commit: bfcc1f7 (i.e. the most recent one I found that still had the old project files).

compiled with ./bootstrap --> ./configure --> make:

compiled with cmake:

The difference is even more pronounced in gl graphics:

compiled with ./bootstrap --> ./configure --> make:

compiled with cmake:

Could be something as simple as compiler flags?

This is on mac, by the way, os x 10.14.6. I'm happy to provide more system details if it would help.

I've recently been made aware of Crispy's feature of being able to restart demo recordings with a keypress (the "Restart current map" key), first introduced here.

I've been attempting to introduce the same feature into prboom+ basing myself on Crispy's implementation, but I'm running into a particular crash and also parts of the code I'm not sure I fully understand. These are my commits so far into a new branch of my fork

When you're recording a demo, and the restart demo key is pressed, the program crashes in the following fashion:

P_GetNodesVersion: using normal BSP nodes
gld_Precache: MAP01 done in 71 ms
G_CheckDemoStatus: Demo recorded
P_GetNodesVersion: using normal BSP nodes
Z_Free: freed a pointer without ZONEID
I_ShutdownMusic: removed /tmp/prboom-plus-music-COiMTN
I_ShutdownSound:

note the Z_Free: freed a pointer without ZONEID . I'm also uncertain what the demowarp variable from crispy does, and if it has anything to do with this problem since I haven't introduced it yet.

Can't seem to figure out how to fix this. I was hoping maybe @fabiangreffrath could enlighten me on how best to approach the problem of implementing demo restarts and also how to fix that crash. Looking forward to your replies, trying to learn as I go here.

Hello.

I've used prboom-plus v2.5.1.4 for a while now, and in that version, I was able to assign MB4 to some actions in key-bindings (in particular: strafe). However, with prboom-plus v2.5.1.5 and onwards, this is no longer possible. Pressing mouse-4 in the key bindings has no effect.
I'd love to try the new versions but I'm stuck in 2.5.1.4 because of this lost feature.

PS - Mouse 4 is the button commonly found close to the thumb in modern mice. It has the function of "browser-back".

PrBoom+'s own free replacement sprites and sounds are currently based on the worm demon from FreeDoom. If we could just embed GZDoom's CC-licensed substitutes in prboom-plus.wad, we could get rid of both the non-free original assets and the free low quality alternatives.

I think this is a similar issue that other ports used to have as well. I noticed this a while ago but constantly forgot to bring it up. Now I finally did.

Basically, when using VSync, the game can be seen displaying previous frames, Some actions make this more obvious than others. It's most easily noticed when pressing exit switches, when a previous frame is visibly displayed before the melt screen comes. This can also be observed when loading a save file.

I am wondering whether the fixes could be ported to PrBoom somehow. In Crispy this also fixed input lag with VSync & uncapped framerate when the order of certain render actions were switched (before something else broke after version 5.3 or 5.4 or something and input lag returned... ).

gm.sf2 with mus_fluidsynth_chorus and mus_fluidsynth_reverb set to 0 sounds much better than the current defaults.
Bumping the sample rate to 44080 would also fix an issue with the music on Eviternity map 30.

gm.zip

Will help to keep track of/ eliminate dependencies, also to facilitate ports to other platforms (such as Playstation Vita, Switch, etc.). And to provide an easier way to keep up with changes to various platforms, for instance, at the time of this post, on MacOS, compiling requires using --disable-gl, by default it fails.

(creating an issue to correspond to the existing discussion on the Doomworld forums, re: CMake)

Followed these steps

rm -fr ~/.prboom-plus
clone https://github.com/coelckers/prboom-plus.git
cd prboom-plus/prboom2
cmake .
make
./glboom-plus -iwad DOOM2.WAD

options > general >
screen resolution > 1920x1080
video mode > opengl

press Escape > new game > hurt me plenty
press Tab

Expected

• lines around textured 2d floors
• grid when pressing G

Actual

• can see textures but no lines
• no grid when pressing G
• no change when pressing O (no lines)
• no change when toggling textures on automap (binded it to T, no lines)

Comment
Interestingly pressing M shows the markings.
This problem disappears entirely when the "video mode" is set to anything other than "opengl" but I want to use opengl.
When built and followed same steps with https://aur.archlinux.org/packages/prboom-plus/ - the automap lines appeared fine.
I'm not sure which commit introduced this issue but can see if I can pinpoint it - if it's any help.

Please let me know if you can if there's anything I could test for, or if you know what might be the problem, or if I'm doing something wrong here.

Cheers.

Hi,
PrBoom+'s source code is currently a pain to work with. This is - among others - due to the multitude of different and inconsistent coding and indentation styles applied by a variety of different code authors over the past two decades.
I'd suggest to apply a cesura here and now by deciding for a single consistent coding style to apply to all code covered by the project.
We should use tools like e.g. clang-format or gnu indent to define a style and provide the corresponding configuration along with the source code.

Cheers,
Fabian

Prompted by @fabiangreffrath in the corresponding Chocolate Doom issue.

The internal v1.2 demo of DTH1.WAD desyncs at about 3:18 with v2.5.1.7um. Sector 107 drops down before the player runs into it, thus the player cannot access the blue key in the secret alcove up above.

Looks like the behavior of linedef special 22 (W1 Floor Raise to Next Higher Floor and Chaneg Texture) was different in v1.2. The floor stays at the level of the teleporter platform the player runs off from in vanilla v1.2 and Choco/Crispy with commit 5b4f916 applied, and the demo plays to the end successfully (it doesn't complete the level but it was not intended to).

Note that the above-mentioned commit builds upon and improves on cph's fix in prboom-plus' current p_spec.c:486. Incidentally it also corrects prboom-plus' inaccurate v1.2 emulation on 1_ON_1.LMP that accompanies 1_ON_1.WAD. Currently prboom-plus raises some sections of the target walkway too high even though that doesn't break the demo - see my post in the linked Choco issue for details including a diagram of the area under discussion.

Also of note: SmileTheory's commit ea3b89b - Moving floors don't make stop sounds in v1.2. Some other commits in the same pull request may be relevant.

I would like to know the locations of the inputs...
I am trying to add support for mouse buttons but I cannot find the location of the keyboard/mouse inputs for it to work. If anyone could point me there that would be great!

Figured I'd leave this here as well.

This is something that I have experienced on a few occasions back in 2.5.1.5. Apparently if the game crashes when the gamma level is changed, it does not get reverted back to its original value, leaving you with the garbage on the desktop and having to get rid of it manually.

Something should be done here, to prevent this from happening and ensuring it gets restored even when the game crashes.

Please, could you check out Boom WR/W1 generalized crusher linetypes?
None of them work in PrBoom++ 2.5.1.7um and they were missing from Boom 2.02 already.
All the SR/S1/GR/G1/DR/D1 generic crushers do work.

It seems that most sourceports have done a fix of their own for them.
From Eternity 3.37.00 changelog:

After a complaint was registered on the Doomworld forums and an email was sent
to me personally by the same person about the little-known fact that BOOM
generalized walk-over crusher line types are no-ops, I repaired them for
demo_version >= 335. It is evident enough that the lines are intended to work
if they have been placed in a map.

Jim Flynn must have left the case for them out of the switch in
P_CrossSpecialLine, and this is not very surprising since they were apparently
the very last generalized line category implemented by the BOOM team. God rest
your soul, Jim.

A test wad of all WR/W1 and some S1 gen. crushers, Doom2 map01:
gencrushers.zip

Thanks.

Generated prboom-plus.wad is 413'182 bytes in size for Windows builds (32- and 64-bit), but it occupies 413'161 bytes for Linux and macOS.

A reminder to myself to figure out this difference.

Greetings. I downloaded latest sources of PrBoom-Plus (master branch) and built 64-bit binary on macOS. Then i recorded UV-MAX demo of one map. This demo plays back correctly with that binary however gets desynced if played on Windows via 2.5.1.5 binaries. I also built 64-bit macOS binary from "official" sources (svn repo) and it played demo back correctly too. I even compiled 64-bit binary for Windows from master branch sources and tried to play this demo back on it but also got desync.

What could cause this?

Demo and WAD in attachment below. Recorded with "complevel 9", iwad "doom2.wad". Desync happens after 5m 30s

entx3320.zip

It appears that the last build you synced from the prboom plus svn was r4526. If so, probably would be wise to sync with the most recent version (r4531 as of this writing)

e0d4316 seems to have broken SDL music, at least on Linux. Fluidsynth works, but selecting SDL will result in no music playing at all. I don't know why this is, but I thought it would be good to report it right away. Reverting to the commit right before it resulted in SDL working again.

When compiling I get this:

r_demo.o: In function G_ReadDemoFooter': /home/gareth/oth/prg/prboom-plus/prboom2/src/r_demo.c:1078: warning: the use of mktemp' is dangerous, better use mkstemp' or mkdtemp'
g_game.o: In function G_LookupMapinfo': /home/gareth/oth/prg/prboom-plus/prboom2/src/g_game.c:2671: undefined reference to Maps'
/home/gareth/oth/prg/prboom-plus/prboom2/src/g_game.c:2671: undefined reference to Maps' g_game.o: In function G_LookupMapinfoByName':
/home/gareth/oth/prg/prboom-plus/prboom2/src/g_game.c:2684: undefined reference to Maps' /home/gareth/oth/prg/prboom-plus/prboom2/src/g_game.c:2684: undefined reference to Maps'
d_main.o: In function D_DoomMainSetup': /home/gareth/oth/prg/prboom-plus/prboom2/src/d_main.c:1840: undefined reference to ParseUMapInfo'
f_finale.o: In function F_Drawer': /home/gareth/oth/prg/prboom-plus/prboom2/src/f_finale.c:663: undefined reference to FMI_Drawer'
f_finale.o: In function F_StartFinale': /home/gareth/oth/prg/prboom-plus/prboom2/src/f_finale.c:90: undefined reference to FMI_StartFinale'
f_finale.o: In function F_Ticker': /home/gareth/oth/prg/prboom-plus/prboom2/src/f_finale.c:233: undefined reference to FMI_Ticker'
collect2: error: ld returned 1 exit status
Makefile:552: recipe for target 'prboom-plus' failed
make[3]: *** [prboom-plus] Error 1
make[3]: Leaving directory '/home/gareth/oth/prg/prboom-plus/prboom2/src'
Makefile:684: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/gareth/oth/prg/prboom-plus/prboom2/src'
Makefile:451: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/gareth/oth/prg/prboom-plus/prboom2'
Makefile:369: recipe for target 'all' failed
make: *** [all] Error 2

The Linux version of PrBoom+ seems to be out of sync, considering this is the port's new home. Can you provide a guide to install this version or a .deb/appimage file please?

prboom-plus, own build from latest src, screen_resolution "320x200" in config

Crispy, own build from latest source, hires off

The pictures are cropped roughly to the LCD monitor's borders. Sorry for the quality, had to take the pictures with my phone to demonstrate the difference in the pillarboxing, the games' internal screenshot functions would be useless for that.

The prboom-plus screen is much too wide at 320x200 (or multiples thereof like 640x400). Using 320x240 in prboom-plus' config fixes the aspect ratio to match that of Crispy (and Choco) but that res is too high for my taste. ;)

Nvidia K2000 video card on AOC 2367 monitor (1920x1080 native res). Win 7 x64 Pro SP1. The Windows desktop and both games run at 1280x720@60 Hz. Both games use the same SDL2 backend so there's something wrong with how prboom-plus treats 320x200.

The non-fork version of prboom-plus on Linux only builds a single binary, "prboom-plus", that can run in software or gl mode from there. When I built this repository, it first surprised me by running slow with just ./prboom-plus, then I noticed the extra binary that does what I really want.

It feels like this is a regression.

I've been experimenting with a personal wad that allows me to play all the Doom 1 episodes in a continious playthrough but there's a minor issue exclusive to prboom plus that gzdoom doesn't have related to the map screens.

When I IDCLEV to a map with Umapinfo enabled and finish it the intermission map of the previous episode displays.

Then when i go to start the next map the regular map shows up but with leftovers from the first.

This also applies to going from episode 2 to episode 3 where the map doesn't get cleared of blood spots from the previous map and the "you are here" arrow points to the wrong part of the map.

Here is the wad I've been using to test this:
umaptest.zip

Transition to CMake removed ability to do make install.

I'm seeing some bugs when using the mouse-wheel-up/down for binds.
First I tried binding mouse-wheel-down to "USE". But after scrolling once with my finger (about 4-5 scroll-instances), the game no longer let's me "USE" anything until I die or restart the level.
Then I tried binding mouse-wheel-down to swap to the Chaingun. But after scrolling a few times, I can no longer swap to the Rocket Launcher or BFG (bound to "Q" and "F" on my keyboard, respectively), and if I swap to any other weapon (for example the shotgun), the game immediately swaps again to the Chaingun, for the rest of the level.

My guess is, because the 4-5 scroll-instances happen extremely fast, the game thinks that the scroll-down "key" is permanently "pressed-down".
I'm used to playing with 2.5.1.4, and this was not a problem in that version.

PS: I'm running the prboom-plus-2.5.1.7um-win32 release from 16 June 2019 on Windows 7.

PS2: I tested some more, and the problem also happens in the 2.5.1.5 version, but not in 2.5.1.4

When you start Episode 2 of Ult. Doom, it starts you at E1M2 instead of E2M1 and Episode 3 starts at E1M3 instead of E3M1, and so on. Issue also present with GlBoom.

Steps to recreate: (using 25 years on Earth as an example wad)
1.Use portmidi as midi player
2.Load up the wad normally and use idclev to get to map29
3.Start the game again, this time with -warp 29
4.Compare how the pitch bends in the music sounds

Alternatively, in Three is a crowd:
1.Use portmidi as midi player
2.Start the game with the wad loaded
3.use idmus10/idclev10
4.use idmus03/idclev03
5.use idmus10/idclev10
6.Compare how MAP10's pitch bends sound before and after playing MAP03's midi

I am assuming the reason there's a discrepancy between starting normally and idcleving compared to using -warp in 25yoe is that the title screen midi has the property that 3iac's MAP03 midi has.

I read from some people that the INI/EMAPINFO format is outdated and now uses stuff such as braces. But the document still shows INI.

Hi!

I'm the original PrBoom guy and still host the SVN repository of it at https://svn.prboom.org/repos/

The last activity there was Sep 27th 2019 by entryway but since the end of 2017 it was almost inactive (besides some updates by @fabiangreffrath in 2018 via entryway). There seems to be quite some activity here though. Can anyone tell me who is currently working on it and doing releases? What is considered the canonical source nowadays?

I would like to update the stuff I have access to (sourceforge and prboom.org) to point to current stuff.

Maybe there is also interest in a prboom organization on github and using github pages for prboom.org?

Looking forward to a reply.

Whenever I exit this version, the game minimizes itself into a windowed mode and stay frozen like that for up to 8 or 10 seconds sometimes.

There's a setting to change the button used to toggle overlay mode for the automap (key_map_overlay in the config file), but it's not in the key bindings menu. It would be a nice convenience to be able to change this from the menu rather than having to figure out the correct number to put in the config file.

Expected

Automap markers move with the rest of the automap in follow mode in every direction when the player moves - regardless of the aspect ratio.

Actual

The map markers appear to "hover" or "slide" over the map in 16:9 ratio either towards "East" or "West" depending on which direction the player is headed. It resembles the parallax scrolling effect when moving. Especially noticeable on larger maps. It makes the feature almost unusable in 16:9 aspect ratio.

When the aspect ratio is set (or detected) to be 4:3 the markers appear to work correctly.
When only moving "North" or "South" (according to the automap) then the markers appear to move correctly in both aspect ratios.

How to reproduce it

1. glboom-plus -iwad DOOM2.WAD -warp 12 -nomonsters
2. Set aspect ratio to 16:9
3. Press Tab
4. Press M
5. Move right and left (on the map)
6. Notice the automap mark "hovering" right and left faster than the rest of the map
7. Move up and down (on the map)
8. Notice no "hovering"
9. Set aspect ratio to 4:3
10. Move right and left (on the map)
11. Notice no "hovering"

Please let me know if there's anything I should test or if I'm doing something wrong here.

We might probably want to integrate the main work of this fork [0] which includes a fullscreen-desktop mode, i.e. instead of changing the display's actual physical resolution the screen content is scaled up to match its own native resolution.

The sum of changes this port adds to the src/ directory [1] is as follows:

diff --git a/src/MUSIC/flplayer.c b/src/MUSIC/flplayer.c
index 163b6b1..d8d65eb 100644
--- a/src/MUSIC/flplayer.c
+++ b/src/MUSIC/flplayer.c
@@ -108,6 +108,7 @@ static const char *fl_name (void)
 static int fl_init (int samplerate)
 {
   const char *filename;
+/*
   #ifdef _WIN32
   #ifndef _MSC_VER
   DWORD WINAPI GetVersion (void);
@@ -118,7 +119,7 @@ static int fl_init (int samplerate)
     lprintf (LO_INFO, "Fluidplayer: Win9x is not supported\n");
     return 0;
   }
-#endif // _WIN32
+#endif // _WIN32 */ // SDL2 program will not run on Win9x anyway - DTIED
 
   TESTDLLLOAD ("libfluidsynth.dll", TRUE)
 
diff --git a/src/SDL/i_sshot.c b/src/SDL/i_sshot.c
index 85d0b58..91e5818 100644
--- a/src/SDL/i_sshot.c
+++ b/src/SDL/i_sshot.c
@@ -52,16 +52,37 @@
 #include "z_zone.h"
 #include "lprintf.h"
 
+int renderW;
+int renderH;
+
+void I_UpdateRenderSize(void)
+{
+	if (V_GetMode() == VID_MODEGL)
+	{
+		renderW = REAL_SCREENWIDTH;
+		renderH = REAL_SCREENHEIGHT;
+		return;
+	}
+
+	SDL_GetRendererOutputSize(sdl_renderer, &renderW, &renderH);
+	return;
+}
+
 //
-// I_ScreenShot
+// I_ScreenShot // Modified to work with SDL2 resizeable window and fullscreen desktop - DTIED
 //
 
 int I_ScreenShot(const char *fname)
 {
   int result = -1;
   unsigned char *pixels = I_GrabScreen();
-  SDL_Surface *screenshot = SDL_CreateRGBSurfaceFrom(pixels, REAL_SCREENWIDTH, REAL_SCREENHEIGHT, 24,
-    REAL_SCREENWIDTH * 3, 0x000000ff, 0x0000ff00, 0x00ff0000, 0);
+  SDL_Surface *screenshot = NULL;
+
+  if (pixels)
+  {
+	  screenshot = SDL_CreateRGBSurfaceFrom(pixels, renderW, renderH, 24,
+		  renderW * 3, 0x000000ff, 0x0000ff00, 0x00ff0000, 0);
+  }
 
   if (screenshot)
   {
@@ -76,8 +97,11 @@ int I_ScreenShot(const char *fname)
 }
 
 // NSM
-// returns current screern contents as RGB24 (raw)
+// returns current screen contents as RGB24 (raw)
 // returned pointer should be freed when done
+//
+// Modified to work with SDL2 resizeable window and fullscreen desktop - DTIED
+//
 
 unsigned char *I_GrabScreen(void)
 {
@@ -85,6 +109,8 @@ unsigned char *I_GrabScreen(void)
   static int pixels_size = 0;
   int size;
 
+  I_UpdateRenderSize();
+
   #ifdef GL_DOOM
   if (V_GetMode() == VID_MODEGL)
   {
@@ -92,16 +118,17 @@ unsigned char *I_GrabScreen(void)
   }
   #endif
 
-  size = REAL_SCREENHEIGHT * REAL_SCREENWIDTH * 3;
+  size = renderW * renderH * 3;
   if (!pixels || size > pixels_size)
   {
     pixels_size = size;
     pixels = realloc(pixels, size);
   }
 
-  if (pixels)
+  if (pixels && size)
   {
-    SDL_RenderReadPixels(sdl_renderer, NULL, SDL_PIXELFORMAT_RGB24, pixels, REAL_SCREENWIDTH * 3);
+	SDL_Rect screen = { 0, 0, renderW, renderH };
+	SDL_RenderReadPixels(sdl_renderer, &screen, SDL_PIXELFORMAT_RGB24, pixels, renderW * 3);
   }
 
   return pixels;
diff --git a/src/SDL/i_video.c b/src/SDL/i_video.c
index 1e1d4ea..81178de 100644
--- a/src/SDL/i_video.c
+++ b/src/SDL/i_video.c
@@ -111,6 +111,7 @@ int gl_depthbuffer_bits=16;
 extern void M_QuitDOOM(int choice);
 int use_fullscreen;
 int desired_fullscreen;
+int fullscreen_desktop;
 int render_vsync;
 int screen_multiply;
 int render_screen_multiply;
@@ -965,6 +966,12 @@ void I_InitScreenResolution(void)
     if ((p = M_CheckParm("-nowindow")))
       desired_fullscreen = 1;
 
+	// DTIED
+	// Command-line option to use fullscreen desktop mode in software renderer
+	fullscreen_desktop = 0;
+	if ((p = M_CheckParm("-fsdesktop")))
+		fullscreen_desktop = 1;
+
     // e6y
     // change the screen size for the current session only
     // syntax: -geom WidthxHeight[w|f]
@@ -1167,7 +1174,10 @@ void I_UpdateVideoMode(void)
     init_flags = SDL_WINDOW_OPENGL;
   }
 
-  if ( desired_fullscreen )
+  // Fullscreen desktop for software renderer only - DTIED
+  if (fullscreen_desktop && desired_fullscreen && V_GetMode() != VID_MODEGL)
+	  init_flags |= SDL_WINDOW_FULLSCREEN_DESKTOP;
+  else if (desired_fullscreen)
 	  init_flags |= SDL_WINDOW_FULLSCREEN;
 
   // In windowed mode, the window can be resized while the game is
diff --git a/src/i_capture.c b/src/i_capture.c
index 3094032..f85602c 100644
--- a/src/i_capture.c
+++ b/src/i_capture.c
@@ -78,6 +78,8 @@ int cap_frac;
 // %f filename passed to -viddump
 // %% single percent sign
 // TODO: add aspect ratio information
+//
+// Modified to work with SDL2 resizeable window and fullscreen desktop - DTIED
 static int parsecommand(char *out, const char *in, int len)
 {
 	int i;
@@ -86,13 +88,14 @@ static int parsecommand (char *out, const char *in, int len)
 	{
 		if (*in == '%')
 		{
+			I_UpdateRenderSize(); // Handle potential resolution scaling - DTIED
 			switch (in[1])
 			{
 			case 'w':
-          i = doom_snprintf (out, len, "%u", REAL_SCREENWIDTH);
+				i = doom_snprintf(out, len, "%u", renderW);
 				break;
 			case 'h':
-          i = doom_snprintf (out, len, "%u", REAL_SCREENHEIGHT);
+				i = doom_snprintf(out, len, "%u", renderH);
 				break;
 			case 's':
 				i = doom_snprintf(out, len, "%u", snd_samplerate);
@@ -551,6 +554,7 @@ void I_CapturePrep (const char *fn)
 
 // capture a single frame of video (and corresponding audio length)
 // and send it to pipes
+// Modified to work with SDL2 resizeable window and fullscreen desktop - DTIED
 void I_CaptureFrame (void)
 {
   unsigned char *snd;
@@ -579,7 +583,7 @@ void I_CaptureFrame (void)
   vid = I_GrabScreen ();
   if (vid)
   {
-    if (fwrite (vid, REAL_SCREENWIDTH * REAL_SCREENHEIGHT * 3, 1, videopipe.f_stdin) != 1)
+    if (fwrite (vid, renderW * renderH * 3, 1, videopipe.f_stdin) != 1)
       lprintf(LO_WARN, "I_CaptureFrame: error writing videopipe.\n");
     //free (vid); // static buffer
   }
diff --git a/src/i_video.h b/src/i_video.h
index 98b1b24..b4d8e11 100644
--- a/src/i_video.h
+++ b/src/i_video.h
@@ -101,6 +101,12 @@ void I_StartFrame (void);
 
 extern int use_fullscreen;  /* proff 21/05/2000 */
 extern int desired_fullscreen; //e6y
+extern int fullscreen_desktop; //DTIED
+
+void I_UpdateRenderSize(void);	// 
+								// Handle potential
+extern int renderW;				// resolution scaling - DTIED
+extern int renderH;				//
 
 // Set the process affinity mask so that all threads
 extern int process_affinity_mask;
diff --git a/src/p_pspr.h b/src/p_pspr.h
index 8df8537..f1fbad0 100644
--- a/src/p_pspr.h
+++ b/src/p_pspr.h
@@ -82,7 +82,7 @@ typedef struct
   fixed_t sy;
 } pspdef_t;
 
-typedef enum
+enum
 {
     CENTERWEAPON_OFF,
     CENTERWEAPON_HOR,
diff --git a/src/p_setup.c b/src/p_setup.c
index a14adef..05fb9e2 100644
--- a/src/p_setup.c
+++ b/src/p_setup.c
@@ -221,7 +221,7 @@ static dboolean CheckForIdentifier(int lumpnum, const byte *id, size_t length)
 {
   dboolean result = false;
 
-  if (W_LumpLength(lumpnum) >= length)
+  if (W_LumpLength(lumpnum) >= (int)length)
   {
     const char *data = W_CacheLumpNum(lumpnum);

[0] https://github.com/DerTodIstEinDandy/PrBoom-Plus-Fullscreen-Desktop
[1] git diff -w 30b6dd2f4a51c40f5ea14687fb71dfdd4b3acb1e -- src/ from current HEAD.

Chorus and reverb usually make the music sound awful when played back through Fluidsynth in PrBoom, and the worst part is that there are no menu entries to turn them off, they have to be manually turned off in the config once found.

The majority of MIDIs are not designed with these in mind, so there's no real good reason to keep them ON by default.

Hi there, me have a trouble, sound synchronize is very creepy, also chaingun and other sounds.

There video when all is normal
https://youtu.be/WPnHEFxznLs

Essentially, this refers to the Xbox Doom IWADs as well as the Unity versions of them. Currently, PrBoom only supports the OG IWADs and the BFG Edition ones, it would be cool to have more ports supporting the other versions of the IWADs. The Xbox ones are currently supported only by Chocolate and Crispy I think.

The second part is about supporting the older versions of Doom and Doom 2 with their respective gameplay shenanigans. Considering the nature of the port, I think it would be a worthwhile endeavor to have them supported, especially by a more advanced port, and support for 1.666 and 1.2 is already in place. Chocolate/Crispy support almost all versions now, with v0.99-1.1 being work-in-progress.

Method of reproducing this issue:
Step 1:Get a wad file with a UMAPINFO lump, I.E. DBP25.
Step 2:Enter a map that was defined via UMAPINFO(in DBP25's case, maps 1-11 and map 33)
Step 3:Save
Step 4:Load save

Alternate step 3/4:warp to the map using the idclev cheat

It can get pretty annoying hearing the start of a music track over and over when you're playing a map, rather than hearing the whole of it as you retry and/or load saves.

So apparently a number of people, including myself now, have noticed that the resolution of the mouse has notably decreased following the latest changes to the input code.

By default, the game acts as if -shorttics is enabled, and -longtics does nothing to remedy this. I suspect the culprit to be somewhere in the PR that added Chocolate-like mouse behavior since this was the last change to alter input code so far. Enabling the setting does increase the mouse resolution a lot, but it still isn't the same as before.

Would it be possible to make the old behavior toggeable? It seems not everyone is fond of this change. I tried fiddling around with settings in case I missed something, but so far I've had no luck.