PrBoom-Plus, ver. 2.5.1.4

Dead port for a dead game. :(

Hello. After a bit of hacking I added fullscreen desktop mode to the latest PrBoom-plus test version (2.5.1.5 r4532).

Add -fsdesktop command line argument to enable the feature and select any software fullscreen mode.
This doesn't work with OpenGL renderer.

Example:

prboom-plus.exe -width 320 -height 240 -fullscreen -fsdesktop

This way, you should see all the pixels large and sharp with any desktop resolution, just like in Chocolate Doom :D

I edited video capture code, so you can also record desktop resolution videos in all the pixelated glory (but it will be SLOW on high res monitors :p)

Download the binaries for Windows Vista and higher. Microsoft Visual C++ 2015 Redistributable Update 3 is required!

Source code

Thanks to @Graf Zahl for Visual Studio 2015 project and source cleanup.

Hope it will be interesting to somebody! Feedback is appreciated.

Are you speaking about this fork? https://github.com/coelckers/prboom-plus

That experimental fork, used by the first versions of Delta Touch, awfully broke demo playback / recording and level progression for Doom registered / The Ultimate Doom (it wrongly warps to E1M[y+1] after the player completes E[x]M[y]), just for your information.

21 hours ago, Litrivin said:

Are you speaking about this fork? https://github.com/coelckers/prboom-plus

 

That experimental fork, used by the first versions of Delta Touch, awfully broke demo playback / recording and level progression for Doom registered / The Ultimate Doom (it wrongly warps to E1M[y+1] after the player completes E[x]M[y]), just for your information.

Yes, I figured that out. I only used project settings from it to fix compilation, the actual source code is retrieved from https://svn.prboom.org/repos/branches/prboom-plus-24/prboom2/

Hence, it's PrBoom-plus 2.5.1.5 r4532 with only a few changes necessary to make fullscreen desktop work (hopefully these changes are sufficient for now).

Git repo should be on my TODO list, I guess...

EDIT:

It is done, here's the GitHub project page. Download links in the previous post are updated!

Suggestions are welcome.

There's a small visual glitch on the weapon sprites, it's most noticeable on the plasma. At the tip of the plasma rifle I get a slim white line of pixels that flashes as the player moves. Unfortunately It's difficult to see in this static screenshot with zooming in, resolution appears to be reduced for attachments. Doesn't appear to happen in glboom-plus, zdoom, choco etc. Beyond changing resolution are their any settings which will reduce this effect? 

I've also have it, it seems to happens randomly while sprite moving. Here it is:

Looks like a scaling bug. What happens if you switch to the automap, and then switch back? Does the line turn black or go away?

No change when map is toggled for me

Previous discussion:

kb1, as Szymanski mentioned, it does not help.

To be more clear: for me, this bug appears only while weapon is bobbing, in static position everything fine. To capture this screenshot I have recorded a video and get picture from it. Probably it's a screen resolution dependent thing. 

I would've probably never noticed this if it wasn't for someone pointing it out.

It doesn't bother me though as I rarely use the Plasma Gun anyway. It's also most noticeable if you actually look for it from what I can tell, so it doesn't impact my play at all. It's just a minor thing, nothing else.

Rounding error in the column drawers. Specifically when you inverse-map the screen coordinate back to texture coordinates, arithmetical errors may cause the calculation to go outside the range [0,columnheight-1]. In this case it wraps around to the bottom of the weapon sprite, instead of being clamped. If you take a screenshot and use a colour picker on it, you will find the erroneous colour at the top of the weapon is the same as the colour of the weapon sprite, at the bottom of the screen at the same x-coordinate.

Older post (for archiving purposes):

dumbplayer.c: In function ‘db_registersong’:
dumbplayer.c:138:11: error: too few arguments to function ‘dumb_read_mod_quick’
     duh = dumb_read_mod_quick (dfil);  
           ^~~~~~~~~~~~~~~~~~~
In file included from dumbplayer.c:68:0:
/usr/include/dumb.h:421:6: note: declared here
 DUH *dumb_read_mod_quick(DUMBFILE *f, int restrict_);
      ^~~~~~~~~~~~~~~~~~~
dumbplayer.c: In function ‘db_render’:
dumbplayer.c:204:5: warning: ‘duh_render’ is deprecated [-Wdeprecated-declarations]
     nsampwrit = duh_render (dsren, 16, 0, db_volume, db_delta, nsamp, dest);
     ^~~~~~~~~
In file included from dumbplayer.c:68:0:
/usr/include/dumb.h:309:6: note: declared here
 long duh_render(DUH_SIGRENDERER *sigrenderer, int bits, int unsign,
      ^~~~~~~~~~

I am trying to add basic CMake support (as attached), however I'm having problems compiling. CMake seems to include all the files just fine, but I quickly noticed this code does not compile for some weird reason:

/home/gustavo6046/.build/prboom-plus-2.5.1.4-src/src/MUSIC/midifile.c:64:52: note: in definition of macro ‘ntohl’
                              (((unsigned long int)(x) & 0xff000000U) >> 24)))
                                                    ^
/home/gustavo6046/.build/prboom-plus-2.5.1.4-src/src/MUSIC/midifile.c:612:37: error: request for member ‘format_type’ in something not a structure or union
     format_type = ntohs(file->header.format_type);
                                     ^
/home/gustavo6046/.build/prboom-plus-2.5.1.4-src/src/MUSIC/midifile.c:67:49: note: in definition of macro ‘ntohs’
         (/*(short int)*/((((unsigned short int)(x) & 0x00ff) << 8) | \
                                                 ^
/home/gustavo6046/.build/prboom-plus-2.5.1.4-src/src/MUSIC/midifile.c:612:37: error: request for member ‘format_type’ in something not a structure or union
     format_type = ntohs(file->header.format_type);
                                     ^
/home/gustavo6046/.build/prboom-plus-2.5.1.4-src/src/MUSIC/midifile.c:68:54: note: in definition of macro ‘ntohs’
                               (((unsigned short int)(x) & 0xff00) >> 8)))
                                                      ^
/home/gustavo6046/.build/prboom-plus-2.5.1.4-src/src/MUSIC/midifile.c:613:42: error: request for member ‘num_tracks’ in something not a structure or union
     file->num_tracks = ntohs(file->header.num_tracks);
                                          ^
/home/gustavo6046/.build/prboom-plus-2.5.1.4-src/src/MUSIC/midifile.c:67:49: note: in definition of macro ‘ntohs’
         (/*(short int)*/((((unsigned short int)(x) & 0x00ff) << 8) | \
                                                 ^
/home/gustavo6046/.build/prboom-plus-2.5.1.4-src/src/MUSIC/midifile.c:613:42: error: request for member ‘num_tracks’ in something not a structure or union
     file->num_tracks = ntohs(file->header.num_tracks);
                                          ^
/home/gustavo6046/.build/prboom-plus-2.5.1.4-src/src/MUSIC/midifile.c:68:54: note: in definition of macro ‘ntohs’
                               (((unsigned short int)(x) & 0xff00) >> 8)))

A shitloadington of similar errors (that are akin to programmer mistakes, except this code SHOULD compile) can be seen when I try to compile some other packages too, but here and there something works.

My question is, WHY does this happen? And why is it happening?

prboom-plus-2.5.1.4-cmake-fix1.zip

Look for a missing semicolon above the errors, or possibly in an include file.

Actually I think the problem is in using "." instead of "->" for pointers.

Anyway, what is PACKEDATTR for? Clang does not seem to support it. May I remove it?

Are you trying to build the released sources? Please try to build a more recent SVN snapshot, e.g. this one:

http://cdn-fastly.deb.debian.org/debian/pool/main/p/prboom-plus/prboom-plus_2.5.1.5+svn4531+dfsg1.orig.tar.xz

Thanks!

What I am actually trying to do is to compile PRBoom-plus, while providing a CMakeLists for it.

17 hours ago, Gustavo6046 said:

What I am actually trying to do is to compile PRBoom-plus, while providing a CMakeLists for it.

That's understood. It's just that you mentioned the PACKEDATTR macro and I remembered some build issue with this macro back then:

come on guyz, i wanna know if there is a future plan for prboom? and whats this project going to be, seriously?

prboom has always been my favorite port for:

* good vanilla accuracy(not so perfect as chocolate, but it has other advantages)

* perfect support for ever-popular boom standard

* great speed for populous maps

* decent graphics, not so beautiful as zdoom but good enough, and much better than chocolate

* plenty of features for playing, demo playback and game behavior tuning

for me, being a perfect barebone port is good enough for prboom. what i like to see is:

* tidy up the code so its easier to read and maintain

* fix known bugs and desyncs(but as the nature of software, fixing bugs often introduces new ones)

* adding new features and extensions are optional, as long as they don't change gameplay compatibility

* possible even further optimization for speed? even though today's computers are very fast, i am from the quake world so i am always freaking out for ever increasing framerate.

On 18/04/2018 at 1:49 AM, noshutdown said:

* possible even further optimization for speed? even though today's computers are very fast, i am from the quake world so i am always freaking out for ever increasing framerate.

Conversely for many of us the first FPS we played a lot of was hard-capped to 35 fps. :-)

(FTAOD, I'm kidding; of course speed improvements are always a good thing if only to handle the most extreme cases of monster count and geometry...)

On 4/18/2018 at 4:49 AM, noshutdown said:

* great speed for populous maps

 

* possible even further optimization for speed?

Yeah, it could use some improvements in the performance department. I first noticed this in a few levels from Ancient Aliens, the very large open areas combined with sheer amounts of enemies and high quality assets don't do a very good job. Far from something more serious but it could use some tweaking nonetheless.

Tweaking? I'm going to assume that this is wishful thinking, vs. a knowledgeable assessment. In a Doom port, there are many thousands of tasks being done in each frame. With today's video resolutions, there are many millions of pixels being drawn in that frame: 1-sided walls, floors and ceilings, 2-sided walls, sprites, HUD elements. There's monster AI, including navigation, pursuit, collision detection, sight-checking, melee, missile, and line attacks, frame changing. There's the mixing, positioning, and attenuation of multiple sounds. There's data caching, possible network communication, demo file reading and writing.

These tasks involve the calling of many hundreds of functions, as seen in the source code of the port. Each of these functions has been looked over by dozens of programmers for over 20 years. These functions have been profiled, modified, and re-profiled, many many times to create the most efficient, fastest possible code.

Can it be improved? Sure - any program of considerable size can most always be improved somewhat. PrBoom+ is currently one of the fastest engines around.

Having said that, any engine can always be brought to its knees when it is fed a massive map. You describe hi-res textures, massive architecture, and large monster count. Each of those textures must be pulled from memory - an act that serves to consume large amounts of the computer's limited number of memory cache lines. That massive architecture must be parsed each frame, to accurately render the scene. Each of those monsters must move each frame, and perform other actions regularly. None of that work can be avoided.

Modern maps are many times larger than the maps of 1993. A texture that's twice as big requires 4x the memory, and 4x the cache lines. IWad maps averaged 100 monsters or so. Many modern maps sport thousands of monsters, each of which contributes to slowing down the engine somewhat.

I don't doubt that there are still some areas in the source that can be more optimized. But the low-hanging fruit has already been picked, for sure. You can't just "do a little tweaking." Improvements nowadays require elaborate profiling rigs, and lots of research, some trial-and-error, and most of all, massive testing against hundreds of PWads of all shapes and sizes, that incorporate clever designs, and possibly include some tricks, from a list of dozens of known hacks. Any port change or enhancement must work with all of them.

I am sure that any good tweaking suggestions would be most welcome. At some point, you have to consider that maybe the map is a bit too ambitious, and needs to be toned down a bit. Question: Do these maps have properly-built REJECT tables? That alone can make a big difference in monster-laden maps with many sectors.

I believe that these days, the only way to get more speed out of the engine would be to rewrite the renderer from the ground up to make full use of multithreading. That appears to be the only area where little to no work has been done so far.

Or buy a new computer. I had absolutely no performance problems with either PrBoom+'s software renderer and GZDoom's hardware renderer - even with GZDoom's true color software renderer - in those abovementioned Ancient Aliens maps and need to throw a lot more demanding stuff at the engine to make it dip below 60 fps. But then I use a modern desktop system with a powerful CPU, not some 10 year old toaster, which still appears to be quite popular, as GZDoom's recently published user survey suggests. One thing should be clear even in 2018: If you want to play games, do not go cheap on the hardware. You may save a little money initially but over time it won't pay off. Better spend a few $100 more and enjoy the better performance. The hardware speed evolution has become so minimal that you can get 10 years out of a good system, provided you replace a few components, like graphics card and hard drive, once or twice over that time period. I decided some 5 years ago to spend $200 more than I actually planned to get a true high end CPU in my rig, and it was one of the best decision ever made. The system is still far above average performance-wise, and over the last 5 years I only had to replace the main HD with an SSD and the old graphics card with a new one that's compatible with DX12 and Vulkan to make the system ready for today's software.

13 minutes ago, Jerry.C said:

 One thing should be clear even in 2018: If you want to play games, do not go cheap on the hardware.

 

Most new games, especially AAA titles, and some modern PWADs, sure. But there are thousands of games and thousands of PWADs that don’t demand cutting edge computing, not just old ones either; and they’re still games, and it’s perfectly fine to enjoy them on a toaster. The GPU rat race isn’t for everyone.

I agree with you about the GPU "rat race". I am perfectly happy with my current Geforce 1060 which I managed to buy before the prices went up. I also do not play AAA titles because they normally cost too much. I am busy enough catching up with older games that are now more affordable and for which some lower cost hardware suffices.

That said, I spend roughly $1000 initially for my computer 5 years ago and $170 on an SSD 3 years ago and $240 for the new graphics card last year - and unless the system suffers from a fatal breakdown I may enjoy it for 5 more years without having to consider it obsolete. Had I spent half of those $1000 initially I would have had to buy a new system by now because it'd just be too slow for what I use it normally, ultimately spending more money on less product.

And one of the benefits is that I can actually play large and complex Doom maps without running into performance issues. And this type of map won't go away because an increasing number of people will have a system that can play them.

I wonder though how this performance discussion started in the first place... I guess this is what I deserve for not keeping my mouth shut...

Either way, the performance "issues" I mention were very far from anything even remotely significant, just a decrease that I managed to notice in a few maps... which resulted in someone angrily lecturing me on how renders work...

And I'm not playing on a 10yrs old toaster, but not on a high end machine either... A Skylake i5, 8GB of RAM and a GTX 950 was as much as I could get for my imaginary budget back in 2015. "Imaginary" for other reasons I won't mention. It serves me well enough for what I do (which really isn't much anyway) so far since I no longer have the time or the funds for the newest AAA titles in which I don't exactly have any interest, and I missed over a decade of games anyway so there's a lot to catch up. Despite this, I'm planning on upgrading the GPU sometime in the future, a 950 really isn't going to take me anywhere, but thanks to cryptomining they're now way beyond affordable, for me anyway.

My main "performance" issue with PrBoom is something very different, but also leads to perceived stuttering:

Thanks to the utterly obtuse options menu I do not even know if I can get the engine to force vsync. As a result it runs at uncapped frame rate, with which larger maps can cause frame rate spikes and dips. That doesn't result in smooth visuals because this unevenness comes through completely unfiltered. In GZDoom I have a vsync switch at an easy to find place in the menu and with that on I get ultra-smooth visuals in nearly every map I play, independently of the renderer being used. (Let's ignore frame rate killers like Blade Of Agony for now, ok...? ;) )

On 4/28/2018 at 3:44 AM, Agent6 said:

I wonder though how this performance discussion started in the first place... I guess this is what I deserve for not keeping my mouth shut...

 

Either way, the performance "issues" I mention were very far from anything even remotely significant, just a decrease that I managed to notice in a few maps... which resulted in someone angrily lecturing me on how renders work...

I hope you're not describing my post. The performance discussion started when you suggested that PrBoom+ "could use some tweaking" (your comment was not really the first.) My bad, I guess, but here's what I heard:

"Man, DoomGuy can only run 35 mph while carrying 100 rockets, and 8 weapons? Jeez, he needs to work out a bit more." :)

I wasn't angry, though it can be an insult to a developer, to hear that his/her engine needs tweaking. But what I did want to say was that, vanilla Doom itself, other than a couple of dog functions, was pretty well optimized when the game was released. And, since the source was released, it's only gotten better. Now, PrBoom+ and most all modern Doom ports are well-oiled, highly efficient machines. They have been very thoroughly tweaked and optimized, probably more so than most any other game you can think of.

At some point, you have to start blaming the computer, or the map. It's like asking a tank to do 180 miles-per-hour: At some point, the laws of physics come into play. As Jerry.C says, the next step might be in running multiple processors, or multiple threads. But that's not optimizing - instead, that's throwing more horsepower at the problem.

And, I did ask: Did the maps in question have proper REJECT tables built? That can make the difference between laggy and smooth performance, especially when there's a lot of monsters and a lot of sectors. Run a nodebuilder that can also build proper REJECT maps, and see if performance improves.

Hey, quick question here. Is there a way to enable the crosshair for slot 1 weapons? I always found it a bit strange when it disappeared for melee weapons. And it also kind of throws me off if, say the Chainsaw is replaced by a new ranged weapon and it's missing the crosshair compared to the rest of the arsenal.

crosshairs! >.<