PrBoom+ 2.6.66 (Jun 20, 2023)

[SmileTheory]

5 hours ago, Graf Zahl said:

I just tried out the new CMake project that got added. With 32 bit Windows everything works fine - but the 64 bit build refuses to start, claiming that the prpgram is invalid. Has anyone managed to get PrBoom+ compiled for Windows 64 bit in the past?

Since the error I get is very uninformative I cannot even say if there's something wrong with the compile setup or one of the DLLs.

 

`prboom2/ICONS/prbooms-plus.exe.manifest` specifies `processorArchitecture="X86"`.

 

I `#ifdef`'d the manifest out of `icons.rc` in my msys2 compatibility pull request, but perhaps just removing `processorArchitecture` would work?

[Graf Zahl]

Oh, that's really stupid. Comparing with other manifests I have, they all fill that field with a *.

Now I wonder why the compiler doesn't complain.

 

With that change it starts but all I got is a crash. That, however, can be debugged.

 

 

[Spectre01]

I'm happy to see this getting some traction. Advanced features or just general quality of life/visual improvements while maintaining demo compat would be amazing.

[SmileTheory]

9 hours ago, Graf Zahl said:

There's just one thing - the C/C++ question. No matter what may be improved here - all relevant code that could be taken is written in C++, and backporting this is clearly not an option because it'd be far too time consuming and error prone. So I have to ask: Would it be a problem for anyone depending on PrBoom if it migrated to C++ - with that I do not mean full-blown OOP, but merely renaming the source files and addressing the syntax differences between both languages? If the code base was C++ it'd be magnitudes easier to borrow code from GZDoom, Eternity or other ports because not everything would have to be downconverted to C again.

 

I'd mind.

 

There's already C++ code in the tree (`scanner.cpp` and `umapinfo.cpp`) and I don't mind if it keeps to itself or more is added, but I'd prefer the old source files remain C instead of polishing them a bit and pretending they were made for C++.

 

Not my project though, and I can always fork before it happens. :)

[Graf Zahl]

That wouldn't help much, the reason to convert would be to use C++ code more easily without wrappers and crap.

As one example, should Hexen map format support really happen, a lot more thinker classes will be needed. And that part is already clunky enough with its fake inheritance.

 

As for 'polishing' the existing code, I think if we want to keep the code base operable, that's a necessity. Too much of what is there is very, very dirty looking code. The main change for C++ would be some type casts, mainly for using the return values of memory allocation functions.

 

[seed]

On 12/30/2019 at 11:20 PM, Graf Zahl said:

Oh, that's really stupid. Comparing with other manifests I have, they all fill that field with a *.

Now I wonder why the compiler doesn't complain.

 

With that change it starts but all I got is a crash. That, however, can be debugged.

 

https://github.com/coelckers/prboom-plus/commit/7c7991fcff48312929f230fbadd3f8e51d0afd3a

 

Looks like you found the culprit. But why does it crash only on x64 boss?

 

I've also noticed the CMake stuff. UBoom+ daily builds coming soon™ :) ?

[Graf Zahl]

I cannot say why it crashes. The crash occurs inside an external DLL which I currently cannot debug. So in order to get working I have commented out that part until I can investigate. But ultimately I'm not sure I want to keep that mess of a music system. I think it'd be to anybody's benefit to add the one from GZDoom instead because it's far more compact and presents a unified interface to the using application without burdening it with such trivialities as detecting the proper format and choosing the right player. GZDoom's music code also features all the needed things to allow loading sounds in more common formats than DMX, so using that would be an added benefit.

I already used that in two other projects and it worked beautifully in both.

 

It'd be a bit of work adding the configuration code for it, though. Here I cannot borrow from GZDoom because the underlying system is too different.

 

[seed]

Sounds so good, *excitement intensifies*.

[seed]

Meanwhile, during my wandering I remebered something: SDL.

 

I remember you saying something similar to the effect of being interested in swaping the backend with something else, if you get to that point or something. Do you have any ideas about what could be used as a potential replacement? I'd sure love to finally see at least some parts of the current backend being dumped and replaced with something better (I'm looking at you crappy sound).

 

Having the music system replaced would already be a step forward, and potentially open the doors to greater things.

[Da Werecat]

Does that mean removing a 2-second lag every time a new sound is being loaded?

[seed]

40 minutes ago, Da Werecat said:

Does that mean removing a 2-second lag every time a new sound is being loaded?

 

That sounds more like a precaching issue.

 

Speaking of which, I don't think PrBoom even has that currently, never found an option anywhere.

[Graf Zahl]

The sound system in PrBoom is the least sophisticated of all Doom engines. It got virtually no significant improvements and forwards the raw sound data from the WAD directly to the mixer, using other formats would rather increase time here because they need to be converted first - but that can be mitigated with a proper precacher.

 

Of course, getting a two second delay hints more at a system side problem. Reading from a file should not be that slow and the sound system as-is also doesn't do anything more with the sound than loading it into memory.

[seed]

And it also offers zero amortization, so for instance, firing the Plasma or opening a Revenant closet with 32 sound channels enabled is just ear rape in it.

 

Of course that doesn't mean SDL should be blamed by default - try doing these 2 easy thing in Eternity for instance, which also uses SDL, and the result is nowhere near as bad as it is in PrBoom. What we currently have in PrBoom is probably the result of a poorly designed or antiquated system (which really should be nuked from orbit one day, and replaced).

[Graf Zahl]

The sound problems are not caused by SDL - the mixer is 100% appplication code, it only uses SDL for outputting it.

The sound system is essentially original Doom with a 4x channel increase, and that simply cannot work. If you want more channels the least you have to do is prioritize away some sound that play too often.

 

If I am really in the need to ditch it I'd probably use GZDoom's sound system instead with a few adjustments regarding the sound limits - which are a bit low thanks to an old ZDoom decision. The advantage would be that OpenAL provides a true professional 3D sound mixer which, even when restricted to a 2D plane and ignoring the height component (unfortunately unavoidable unless the entire sound design was refactored as well) sounds so much better than these old and primitive stereo mixers, especially if you have a good 5.1 system connected. I've noticed that with nearly every retro engine, be it Doom ports, Build ports or the real ancient deal - the ones sticking to the original sound mixers just sound so much inferior compared to modern sound engines... (mainly because the naive mixers they use are garbage, not because stereo is bad. Using a professional mixer makes an incredible difference because they are written by people who know how sound works and how not to let it degrade into ear-rape.)

 

 

[seed]

16 minutes ago, Graf Zahl said:

The sound problems are not caused by SDL - the mixer is 100% appplication code, it only uses SDL for outputting it.

The sound system is essentially original Doom with a 4x channel increase

 

Talking about minimalism and simplicity  . That's one helluva way to keep things that way, which is equally surprising as it doesn't make much sense to see how nothing changed all those years, no one bothered to make any improvements - be that Andrey or someone else.

 

It explains why using 32 channels feels like the game only does a simple 4x channel increase - because that's literally all it does. I suppose at this point there's multiple ways to go. I think the best choice would be going full beast mode with OpenAL and replacing the whole thing. I understand that's no easy feat, that much is not questioned, but it really does sound like on the long term, taking the more time consuming approach is going to pay off so much better. A swap with GZDoom's sound engine would be cool as hell.

[Graf Zahl]

Actually, in a case like this, plugging a working system (especially one where you know how it works...) into the whole thing tends to be a lot easier than trying to fix the code that is there.

Been there, done that on other projects. Often it happens that one is standing in front of a problem that seems as large as a mountain, but once you ask yourself, why not just nuking the mountain out of existence isn't the best solution. It often is.

 

But this is a prime example for my C++ concern above. I wouldn't bother backporting all that code to C. As it is it works, after porting it's like having written something new and needs to be debugged and fixed. The good thing is, it's a sound system made for Doom, so all the basics in there can be left as they are, so I surely believe it is doable. If it was a sound system for another game with different sound logic, things would be different.

 

[seed]

Groovy.

 

That's so awesome to hear, this stuff is really hyping me up boss.

[Graf Zahl]

You are getting excited about abstract plans? So far nothing has been decided yet. Of course a refactor of the low-quality sound code is definitely something worth investing work in. This could be a feature giving this fork some genuine boost.

 

 

[seed]

2 minutes ago, Graf Zahl said:

You are getting excited about abstract plans? So far nothing has been decided yet. Of course a refactor of the low-quality sound code is definitely something worth investing work in. This could be a feature giving this fork some genuine boost.

 

Well the interest is clearly there, so something will happen eventually.

 

What that something will be, only time will tell.

[Da Werecat]

4 hours ago, Graf Zahl said:

Of course, getting a two second delay hints more at a system side problem.

I've been getting it on 2 different laptops across 3 versions of Windows, although both of them have AMD hardware. I've also had vague recollection of seeing it in other SDL ports, but I must be going crazy, because right now I'm having trouble replicating it even in PrBoom+.

 

I'm sure it will return when I'm genuinely trying to play something.

 

Even before, it wasn't exactly a consistent issue, but noticeably attached to monster types waking up for the first time in the current session. It may be more pronounced in complicated levels that already strain the system a lot, I'd have to go over more wads to confirm this.

 

4 hours ago, seed said:

And it also offers zero amortization, so for instance, firing the Plasma or opening a Revenant closet with 32 sound channels enabled is just ear rape in it.

That is the worst part of PrBoom sound. It's just such an ear pain when too many identical sounds are getting played at the same time (although I didn't have much of a problem with plasma rifle in particular).

[Graf Zahl]

8 minutes ago, Da Werecat said:

That is the worst part of PrBoom sound. It's just such an ear pain when too many identical sounds are getting played at the same time (although I didn't have much of a problem with plasma rifle in particular).

 

Calling Printz's attention...

 

The most dangerous place in Doom is when the Icon of Sin goes poof. The mass of sounds that gets started with that can easily blow out some speakers with too many channels.

 

8 minutes ago, Da Werecat said:

I've been getting it on 2 different laptops across 3 versions of Windows, although both of them have AMD hardware. I've also had vague recollection of seeing it in other SDL ports, but I must be going crazy, because right now I'm having trouble replicating it even in PrBoom+.

 

SSD or magnetic hard drive?

 

[Da Werecat]

Just now, Graf Zahl said:

SSD or magnetic hard drive?

The latter.

 

Much more sophisticated games don't seem to have a lot of trouble handling their data, unless going too modern or less optimized. In those cases, there's clearly some bottleneck that causes hiccups roughly when it's time to dynamically load new content, but installing SSD (Doom folder is not currently on it) didn't change a great deal aside from loading times.

[seed]

12 hours ago, Da Werecat said:

(although I didn't have much of a problem with plasma rifle in particular).

 

Well, that depends on your audio setup too, I guess.

 

I'm using the less-than-ideal built-in speakers of my monitor, which are terrible for anything other than I dunno, watching shows or something. My last pair of speakers broke years ago and I never bothered to replace them (as if I had any money in the first place... ). All weapons sound flat with them (the SSG in particular, it has almost no depth), and the Plasma... well, the Plasma does what it does best, destroy them speakers. That alone prompted me to rip out the Plasma sfx from Sawdust and make a small wad which I've been using ever since when playing wads that don't come with custom sfx or whatever and I'm using PrBoom.

 

Again, it's less of an issue in Eternity and GZDoom since these ports have much better sound systems, but there's only so much you can do with such a setup, primitive audio, and a sound effect that is loud anyway.

[seed]

In other news, while getting pissed playing Doom I remembered about the VSync issues.

 

Do you have any potential fixes for this in your fork boss? I think I kind of discovered something else as well: Some of us felt like the mouse has some minimal acceleration/smoothing, even without VSync or whatever. Well apparently, in my experimentation I discovered that with VSync ON and capped framerate the mouse is stupid responsive and feels really raw, just like in GZDoom.

 

This is peculiar, to me at least. Why does the mouse feel different when using capped and uncapped framerate? With VSync it was understandable, but without?

[ketmar]

the easiest workaround for ear-ripping could be just limiting the amount of identical sounds playing simultaneously. i guess that the sound system already stores sound id for each channel (and if it isn't, it is as easy as storing one more number), so when new sound added, simple loop just checks if there are already 2 or 3 such sounds playing, and simply rejects the new one. there could be more smart prioritisation, but even with this simple thing it would be much better.

 

much less work than replacing the whole sound system, so somebody interested can write a simple patch.

 

(p.s.: yay, this post is full of simplicity!)

[seed]

1 hour ago, ketmar said:

the easiest workaround for ear-ripping could be just limiting the amount of identical sounds playing simultaneously. i guess that the sound system already stores sound id for each channel (and if it isn't, it is as easy as storing one more number), so when new sound added, simple loop just checks if there are already 2 or 3 such sounds playing, and simply rejects the new one. there could be more smart prioritisation, but even with this simple thing it would be much better.

 

much less work than replacing the whole sound system, so somebody interested can write a simple patch.

 

(p.s.: yay, this post is full of simplicity!)

 

Sometimes, complex problems have simple solutions  .

[Graf Zahl]

1 hour ago, ketmar said:

the easiest workaround for ear-ripping could be just limiting the amount of identical sounds playing simultaneously. i guess that the sound system already stores sound id for each channel (and if it isn't, it is as easy as storing one more number), so when new sound added, simple loop just checks if there are already 2 or 3 such sounds playing, and simply rejects the new one. there could be more smart prioritisation, but even with this simple thing it would be much better.

 

much less work than replacing the whole sound system, so somebody interested can write a simple patch.

 

(p.s.: yay, this post is full of simplicity!)

 

I already said, sometimes the easy solution may cause worse problems than doing it right. I had a look over the sound code and while it can certainly be fixed, the benefit of just replacing everything might be worth it. I already refactored the GZDoom sound code for inclusion into another project so for the most part what I have is sufficiently clean so that all I'd have to do is adding the interface code. In any case, I first want to do some preparations to get the music code into a state that I can maintain it as a separate project, I really have little desire to copy this much code around between projects, and then keeping it in sync - it is tempting to drop it into several private things that have sub-par music support, but for that it should be usable as a DLL on Windows or a separate library on Linux.

 

I'll make no promises, though. I haven't looked deeper into PrBoom's sound code yet and there may be surprises I'm not yet aware of.

But since I've already gone through the entire process of adding the entire sound system to another (non-Doom) project, I already have a good idea how much work this is - it cannot be harder than that to add it to another Doom related port where there's far less surprises to be found.

[ketmar]

6 minutes ago, Graf Zahl said:

I already said, sometimes the easy solution may cause worse problems than doing it right.

sure. but until it is replaced, that workaround can save some people from buying new speakers to replace blown-off ones. ;-) i didn't meant that solution to stay, only a temporary workaround. just dropped the idea here in case someone wants to start hacking Doom source, or has nothing better to do. from what i remember about original sound system, it should be an easy thing to try, no need to know anything arcane about the engine.

[seed]

9 minutes ago, ketmar said:

sure. but until it is replaced, that workaround can save some people from buying new speakers to replace blown-off ones. ;-) i didn't meant that solution to stay, only a temporary workaround. just dropped the idea here in case someone wants to start hacking Doom source, or has nothing better to do. from what i remember about original sound system, it should be an easy thing to try, no need to know anything arcane about the engine.

 

But it's somewhat of a waste of time IMO.

 

I'm fine waiting a bit longer for a new version with a new sound system, considering that the workaround can potentially have unwanted results.

[ketmar]

20 minutes ago, seed said:

considering that the workaround can potentially have unwanted results

not much. basically, only some "lost" sounds from plasma, explosions, alot of active lifts, or monster noises in hoarded places. the things you won't even notice. this is what other sourceport are doing anyway (maybe paired with distance/volume checking). just a way to put less pressure to Graf while he is busy. and i didn't meant that Graf should do it, i hoped that somebody will jump in with the patch. yeah, i still believe in miracles. ;-)