PrBoom+ 2.6.66 (Jun 20, 2023)

8 hours ago, seed said:

 

Hm, so the SW rendered is pretty much bonked for the time being. Eh, not a big deal as it performs worse in large/complex maps with lots of enemies anyway. OpenGL would have definitely been though, but if it still performs well that's good.

I wouldn't call it "bonked". It's roughly 20% slower when I tested Frozen Time, i.e. 27 fps vs. 34 fps in 1920x1080. And that map's probably the worst case scenario out there. For comparison, ZDoom's software renderer manages less than 10 fps on the same map.

8 hours ago, seed said:

 

Do you plan on updating the MIDI players? I've noticed a while ago than Fluidsynth is definitely worse in PrBoom+ than in GZDoom, and according to a topic on github, OPL2 is also worse than it is in other ports (+ worse performance and less accurate). Not going to ask about Portmidi as I have never used it in other ports apart from PrBoom.

The main problem here is not the MIDI players but the cheap-ass sound interface SDL provides. GZDoom uses OpenAL as its backend which isn't a primitive raw stereo buffer but an actual 3D sound API with good support for modern standards and a professional quality mixer.

TBH, the only way I see to 'fix' the sound would be to rip out the current sound system and put in GZDoom's, but that's not only a huge undertaking but also would require quite a bit of work on the resource management and introduce a large amount of C++ code into the project (don't even think about backporting that code to plain C, that's simply not possible - it makes full use of polymorphism and abstraction.) and that seems to be sacrilege if some people were to be believed.

8 hours ago, seed said:

 

Has the SDL in this version been updated since 2.5.1.5?

I actually haven't checked, it may even use an older version from 2.5.1.4.

6 hours ago, dew said:

Basically, yeah. 0xff as the first byte is the way to go. But Eternity already does this, so it's not an "invalid" value. But Eternity then adds its own identifier string to the header, and anotak proposes that pr+ would do the same with its own string.

I didn't know that Eternity already used it. No problem putting a bit more info into the header or use 0xfe, for example.

A real identifier would be best, of course.

7 hours ago, Altazimuth said:

Not UMAPINFO, all the other fucktillion random ramblings. We need to keep FOCUSED.

Agreed here. I don't mind discussing the potential implications of certain features, but for now the focus is UMAPINFO and after that most likely the map format itself, i.e. whether to support Hexen and/or UDMF, and add the needed features to support them.

If someone really wants to try to graft GZDoom's sound system on this code, for example, be my guest. It's going to be a lot of work and IMO would definitely be worth it from a technical perspective - having true 3D sound makes a massive difference, but it goes far beyond my current plans.

@Graf Zahl Will Episodic format for Doom 2 be available in future. TheMightyHeracross posted the UMAPINFO for Eviternity above but he said it doesn't work.

Might as well just get this example WAD out before I go to bed even if it's not exactly "later today" like I promised. Here's my base resource WAD stripped down about as bare as I can make it. "UMAPINFOBugExample.wad" is the main WAD here; it's without "Episode = Clear", but there's a separate WAD file in the same ZIP file (with the not-at-all-longwinded filename "UMAPINFOBugExampleAddon_EpisodeEqualsClear.wad") whose only lump is a copy of the UMAPINFO with "Episode = Clear" added, which you can load after the main WAD to force that line's presence. This way you can see that the episode selection isn't working in either case, but the difficulty selection also breaks down when "Episode = Clear" is present.

There's some GZDoom bugs exhibited in this sample WAD too, but I'll open tickets for that on the relevant forum tomorrow.

20190617_UMAPINFOBugExample.zip

31 minutes ago, ReaperAA said:

@Graf Zahl Will Episodic format for Doom 2 be available in future. TheMightyHeracross posted the UMAPINFO for Eviternity above but he said it doesn't work.

Of course it will be available, it's probably just a minor oversight in that convoluted menu code that went all the wrong way implementing the differences between Doom 1 and Doom 2.

1 hour ago, Graf Zahl said:

I wouldn't call it "bonked". It's roughly 20% slower when I tested Frozen Time, i.e. 27 fps vs. 34 fps in 1920x1080. And that map's probably the worst case scenario out there. For comparison, ZDoom's software renderer manages less than 10 fps on the same map.

 

The main problem here is not the MIDI players but the cheap-ass sound interface SDL provides. GZDoom uses OpenAL as its backend which isn't a primitive raw stereo buffer but an actual 3D sound API with good support for modern standards and a professional quality mixer.

 

TBH, the only way I see to 'fix' the sound would be to rip out the current sound system and put in GZDoom's, but that's not only a huge undertaking but also would require quite a bit of work on the resource management and introduce a large amount of C++ code into the project (don't even think about backporting that code to plain C, that's simply not possible - it makes full use of polymorphism and abstraction.) and that seems to be sacrilege if some people were to be believed.

 

I actually haven't checked, it may even use an older version from 2.5.1.4.

Thanos for the info.

Definitely not the case of using the SDL from 2.5.1.4. Just checked the archive and there's SDL2 libraries insine.

2.5.1.4 is SDL1. Which is good because if 2.5.1.4 and other SDL1-based ports are of any indication, that would have meant borked mouse support on newer Windows versions.

To be honest I would f*cking love to see Hexen support in the future, and a better sound system, but that's understandably well out of the scope of the project for the time being.

6 hours ago, seed said:

To be honest I would f*cking love to see Hexen support in the future, and a better sound system, but that's understandably well out of the scope of the project for the time being.

Eternity Engine has a better chance of implementing Hexen support in future. Heretic is 95% working (beatable from start to end) in Eternity dev builds and I believe Hexen would be next.

Do any of you get the issue with this version of PrBoom+ when you exit the game the game will go into a windowed mode and freeze there for around 5 seconds before the window closes?

No. When I quit it shows the ENDOOM screen and when I click into that it closes immediately.

Just to follow up on what I was saying earlier about opening bug reports on the UMAPINFO implementation in GZDoom, I've gotten around to making the bug reports. Five of them, in fact:

• [GZ 4.1.3] UMAPINFO-defined episodes don't show skill select
• [GZ 4.1.3] UMAPINFO: InterMusic inconsistencies
• [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well
• [GZ 4.1.3] UMAPINFO "Episode = clear" and ordering weirdness
• [GZ 4.1.3] SIGIL UMAPINFO thinks every E5 map is E5M9

Obviously not entirely relevant to PrBoom+/UMAPINFO 2.5.1.7 discussion, but relevant to UMAPINFO discussion as a whole, I suppose.

Why not limit UMAPINFO to PrBoom+current? It's a new feature, unavailable in older engines, it should not be available in legacy complevels. If you still want to play vanilla-like, you have all the MBF compatibility options in the menu which you can turn off. No need to use "-complevel 2" all the time. Just consider the wad designed for PrBoom+ and other MBF+UMAPINFO compatible ports (this should be Eternity if you want demos). I guess I should fix EE to actually run PrBoom+current demos…

Speaking of user configurations, it would be super nice to add support for the OPTIONS lump in PrBoom+. MBF has it, Eternity too, but PrBoom skipped inheriting it for some unknown reason. Several MBF and Eternity wads use it to make sure the gameplay works as intended.

I saw some ramblings about Eternity and demo headers in this thread. Do I need to do anything to be compliant? I'd love to see some PrBoom+UMAPINFO demos to test in Eternity…

I'm planning to add support for UMAPINFO in Eternity. It's very tempting to just integrate it into EDF, but I'll have to be wary about namespacing: UMAPINFO is not our creation, so we need to steer clear of collisions. Probably anything added by Eternity for Eternity to UMAPINFO will have to be prefixed with something (e.g. "ee-").

Does GZDoom support UMAPINFO? (I guess it does, seeing the post above)

2 hours ago, printz said:

Why not limit UMAPINFO to PrBoom+current? It's a new feature, unavailable in older engines, it should not be available in legacy complevels. If you still want to play vanilla-like, you have all the MBF compatibility options in the menu which you can turn off. No need to use "-complevel 2" all the time. Just consider the wad designed for PrBoom+ and other MBF+UMAPINFO compatible ports (this should be Eternity if you want demos). I guess I should fix EE to actually run PrBoom+current demos…

Because it'd block playing mods with older complevels. Imagine BTSX came with an UMAPINFO and someone wants to record demos on it using strict vanilla gameplay settings. Currently this is doable, but with your approach it wouldn't be.

This s what I mean when I say it freezes in a windowed mode when I close it.

Peculiar, I'm not seeing the game still running in the taskbar.

The game freezes like this for a few seconds then the games shows up in the task bar after a few more seconds

Here's another screenshot.

On 6/22/2019 at 3:08 PM, Graf Zahl said:

 

Because it'd block playing mods with older complevels. Imagine BTSX came with an UMAPINFO and someone wants to record demos on it using strict vanilla gameplay settings. Currently this is doable, but with your approach it wouldn't be.

Technically, PrBoom+ should not allow the recording of a Doom v1.9 demo when interpretting UMAPINFO. The idea is that a 1.9 version demo should be able to be played back in vanilla Doom.

That provides 3 choices for PrBoom+:

1. Record the demo, but apply a different version number.
2. Disallow the creation of a 1.9 demo, and force a PrBoom+ demo.
3. Record a v1.9 demo, and disable UMAPINFO.

Entryway worked pretty hard to prevent the recording of v1.9 demos anytime a non-vanilla option is in effect, so that effort should probably be continued.

That's why the presence of UMAPINFO is an added flag. But it is independent of the active complevel. You cannot play an UMAPINFO-based demo with an incompatible engine.

2 hours ago, Graf Zahl said:

That's why the presence of UMAPINFO is an added flag. But it is independent of the active complevel.

Can you elaborate? What kind of flag are you describing?

2 hours ago, Graf Zahl said:

You cannot play an UMAPINFO-based demo with an incompatible engine.

What do you mean by that? Does the port prevent v1.9 demos from being recorded? Does it force PrBoom+ to write PrBoom+ demos only when the UMAPINFO flag is set?

If so, that sounds like a solid plan. What we don't want are v1.9 demo files being generated that don't play in, say, vanilla, or Chocolate Doom, etc. In other words, if the demo is stamped "19", it must be compatible with some version of vanilla 1.9. The situation is already messed up, since a 1.9 demo could be from Final Doom, Ultimate Doom, etc.

Id Software should have changed the version number when they altered the game logic, and released different versions of 1.9. So, it's already a mess...and we need to make sure that we don't create a bigger mess!

PrBoom+ demos contain a footer that has lots of info about the loaded IWAD and PWADs, game settings, etc. Maybe the UMAPINFO flag could be added there (it's not strictly necessary, since the loaded PWAD contains the UMAPINFO lump.)

KBDoom demos contain the loaded WADs, as well as MD5s for each WAD, which would ensure that the exact WADs are properly loaded. I don't know if PrBoom+ does this.

Anyway, Graf, it sounds like a nice, proper implementation - good job! It would have been easy to implement badly. I appreciate your diligence and your approach.

@Graf Zahl glad to see you've taken up taking the care of prboom-plus, especially the potential move to CMake.

Also, what sort of help do you need with making a macOS release? I've made a pull request to fix configuring and building with OpenGL support on mac, which should make life a bit easier while the project's stuck with autotools, and maybe I could be of more help with it.

The thing I'd need most is time. Sadly that's the one thing I'm rather short of. Splitting my programming time between work, GZDoom, this and other things I work on is not easy, something will have to be put on hold - and I'm afraid to say that this is the project that's suffering the most from lack of time I can allocate for it.

So if someone could help me out I'd appreciate it a lot.

A CMake transition is such a thing where time is the factor holding me back the most. I find the Visual Studio project quite unwieldy - the original PrBoom+ comes with ones for two ancient (21 and 14 year old) MS compiler versions - I converted the latter one to a modern version of the compiler - but I notice it every time when working with native VS projects how limiting they are for cross-platform development. But building a working CMake project is not the easiest task, thanks to its screwed up scripting language. Sadly there  isn't anything better out there. :(

On 6/22/2019 at 7:42 PM, printz said:

MBF has it, Eternity too, but PrBoom skipped inheriting it for some unknown reason.

I remember these conversations. The most convincing argument against OPTIONS was that it was tied to the old MBF config syntax and selection of keys.

I don't think this is a problem, unless implementing an additional parser is too much for the people involved. Some of the things that OPTIONS allowed to change won't even apply to a modern source port, but they can be ignored, as well as the things that can, but shouldn't be controlled by the wad. Overall, the lump could be treated as just another definition lump in its own format, with a fixed selection of possible keys.

On 6/22/2019 at 10:08 PM, Graf Zahl said:

Because it'd block playing mods with older complevels. Imagine BTSX came with an UMAPINFO and someone wants to record demos on it using strict vanilla gameplay settings. Currently this is doable, but with your approach it wouldn't be.

I always considered it the weirdest way to go about it. In my humble, complevels should remain complevels, i.e. emulation modes that are precise, and UMAPINFO should be an engine feature in some of these modes. This feature can include an assortment of flags to control the game's behavior, and, if the player's freedoms are of concern, the ability to override said flags from the menu. But if someone runs a wad with a complevel, they should be expecting thorough emulation, maybe aside from a selection of cosmetic features deemed safe (like sky transfers).

Then again, Doom source ports are a mess.

On 10/6/2019 at 12:07 AM, Da Werecat said:

I always considered it the weirdest way to go about it. In my humble, complevels should remain complevels, i.e. emulation modes that are precise, and UMAPINFO should be an engine feature in some of these modes. This feature can include an assortment of flags to control the game's behavior, and, if the player's freedoms are of concern, the ability to override said flags from the menu. But if someone runs a wad with a complevel, they should be expecting thorough emulation, maybe aside from a selection of cosmetic features deemed safe (like sky transfers).

I think about it a bit differently. The map progression is a meta structure above the actual gameplay and a person's choice about what compatibility mode to use should not have an impact on a game's defined progression.

These are options in two entirely different dimensions and trying to linearize them will only cause problems, especially if it can be easily avoided.

On 10/6/2019 at 12:07 AM, Da Werecat said:

 

Then again, Doom source ports are a mess. 

No, not really. Build engine ports are a real mess, with none working right. Most of the existing Doom ports at least do what the packaging says. And despite the wide variety in their goals they have stayed surprisingly compatible with each other.

1 hour ago, Graf Zahl said:

No, not really. Build engine ports are a real mess, with none working right.

Eh, GDX and NBlood at least seem to be doing well, overall.

Duke ports on the other hand... with only eduke32 still going (and even that seems to be approaching a dead end thanks to the disastrous codebase), it doesn't look all that sunny.

Dunno about meta, considering that a demo expecting a different map progression is not a demo for the same engine. It simply won't work. I'm sure that technically it's been resolved already, but I don't think it's very intuitive.

Must be easier to maintain though?

1 hour ago, seed said:

Duke ports on the other hand... with only eduke32 still going (and even that seems to be approaching a dead end thanks to the disastrous codebase), it doesn't look all that sunny.

There is also RedNukem, which is a fork of an older build of Eduke32. It reverts a lot of the physics/clipping changes made to back to vanilla as it aims to be a demo-compatible port. Its made by NukeYKT (the same guy who made NBlood).

51 minutes ago, seed said:

 

Eh, GDX and NBlood at least seem to be doing well, overall.

NBlood is just EDuke32 under the hood, so overall it's the same - mainly the fact that it has no true color rendering mode (sadly the same issue with the Fresh Supply port which I find quite disappointing.) EDuke32 disabled that half a year ago and managed to get the code broken more and more because it couldn't be tested anymore.

And with GDX being Java and having a rather basic feature set it's not really that promising a project aside from supporting two more obscure games.

51 minutes ago, seed said:

 

Duke ports on the other hand... with only eduke32 still going (and even that seems to be approaching a dead end thanks to the disastrous codebase), it doesn't look all that sunny.

Correct. The Build engine's backend code base is an unmitigated disaster. I've been trying to make some sense of it to fix the performance problems with VSync enabled and it's no exaggeration to say that there isn't a single part in that huge pile of code which isn't fucked up. No matter where I look there's some obstacles - it's like walking through an old house that has fallen into disrepair with crumbled walls lying around in every room and every corridor.

The Duke Nukem game code doesn't really fare any better, but it's far less of a concern than the backend because it's merely the front end and not the foundation everything is built upon.

And coming back to NBlood, yes, the game code itself is of an entirely different quality (magnitudes better, in fact) but it still has to make do with a backend that's for all intents and purposes broken and lets its problems filter up to the game's surface.

Regarding the dead end, my stance here is that this code base needs a totally different approach - instead of trying to keep it alive it needs to be demolished into little pieces and then be rebuilt from the ground up by replacing the rotten parts and stitching the rest together again with a better foundation. But that really needs a different type of programmer than the ones currently working on it. EDuke32 has been going for 13 years and never went beyond the effort to keep it going.

21 minutes ago, Da Werecat said:

Dunno about meta, considering that a demo expecting a different map progression is not a demo for the same engine. It simply won't work. I'm sure that technically it's been resolved already, but I don't think it's very intuitive.

Of course you cannot keep the same format when playing with a new meta feature being added - that's why there is another identifier to block use of such demos in a non-supporting context. But what you CAN do is play a map set with complevel 2 gameplay settings and a newly defined progression - and I see no reason why that should be blocked by an overly strict interpretation of the complevel concept. Yes, strictly speaking that's a new complevel, but do we really want 15 more of them just for a single feature? That'd be the alternative.

1 hour ago, ReaperAA said:

There is also RedNukem

E: Nvm confused things.

2 hours ago, ReaperAA said:

 

There is also RedNukem, which is a fork of an older build of Eduke32. It reverts a lot of the physics/clipping changes made to back to vanilla as it aims to be a demo-compatible port. Its made by NukeYKT (the same guy who made NBlood).

Don't overestimate what it changed. The backend is up to date, all he did was stripping down the game features to the bare DN3D 1.5 feature set so that it becomes demo compatible again. The backend for EDuke32, RedNukem and NBlood is virtually identical, save for the fact that NukeYKT added some demo compatibility checks in the engine that haven't been filtered back upstream yet, but you can compile EDuke with it as well and wouldn't notice any difference.

4 hours ago, Graf Zahl said:

Yes, strictly speaking that's a new complevel, but do we really want 15 more of them just for a single feature?

You mean like duplicating every existing complevel, but with UMAPINFO enabled?

Yes, that'd be the alternative if we want to allow playing UMAPINFO mods with older complevels.