PrBoom+ 2.6.66 (Jun 20, 2023)

[P41R47]

17 minutes ago, JuanchoES said:

Huh? Im not saying that i have more input lag, im saying that im having less input lag with the newest built.

 

yes i understand that you have less with the exclusive_fullscreen, but you had a lot of input lag without it, so have you tried without it if the problem persist on my configuration?

As for the blurryness... i don't know, it looks like 640x400 with or without the exclusive_fullscreen on :/

Edited March 5, 2021 by P41R47

[Never_Again]

Latest Win32 dev build, as of commit ce65528 (March 4 2021).

 

Noteworthy changes since last dev build (March 2 2021):

* fixed hanging notes on exit when using Portmidi
* show current and next levels when typing IDCLEV cheat
* added a config key for "exclusive" i.e. mode-changing fullscreen

prboom-plus-20210304-w32.zip (TinyUpload)

prboom-plus-20210304-w32.zip (FileDropper)

 

Includes the 36 required DLLs. See the accompanying TXT file for details.

 

For a complete list of changes since last official release look here.

[fabian]

8 hours ago, JuanchoES said:

1- When youre using exclusive full screen you cannot go lower than 640x400 for some reasons

 

"Exclusive fullscreen" means that your screen's resolution is changed to match the game window's dimensions - instead of scaling up the game window to match the screen's current resolution. This means that you can only use resolutions that your screen reports to support. If your screen doesn't support a native 320x200/320x240 mode, there is no way you can select this resolution with "exclusive fullscreen".

[Gez]

And likewise for blurriness: if your screen purports to support 640x400, but actually kinda lies about it and only support it through a messy scaling mode that makes everything blurry, then you get everything blurry.

 

And screenshots will look just fine, since they're screenshots. You'd need to take a picture of your screen if you want to show how your screen makes things blurry; because the source picture will not have this blurriness.

 

Basically, there's a reason why using exclusive fullscreen mode is now discouraged.

[Never_Again]

Latest Win32 dev build, as of commit d36f06b (March 5 2021).

 

Noteworthy changes since last dev build (March 4 2021):

* UMAPINFO: if interbackdrop does not specify a valid flat, draw it as a patch instead

prboom-plus-20210305-w32.zip (TinyUpload)

prboom-plus-20210305-w32.zip (FileDropper)

 

Includes the 36 required DLLs. See the accompanying TXT file for details.

 

For a complete list of changes since last official release look here.

[ketmar]

to devs: can you, please, add changelog to umapinfo specs? it is hard to expect any correct implementation from other sourceports, when something is changed/extended without a notice. also, it would be nice to know that the spec was changed, without constantly watching commit logs.

 

p.s.: the spec doesn't say what to do with invalid syntax, are unknown keys allowed, how to skip them if they are, what to do with unexpected arguments, and so on. so it is impossible to write a compliant parser that won't break on sudden spec extension.

[GoneAway]

I think there should be an independent umapinfo spec repo (with reps from different ports) where changes can be reviewed and easily tracked.

[fabian]

5 hours ago, kraflab said:

I think there should be an independent umapinfo spec repo (with reps from different ports) where changes can be reviewed and easily tracked.

Right. However, as long as that one file in prboom-plus's doc/ directory is the entire de-facto spec, I agree with @ketmar that we should at least introduce a revision tracker with a changelog. 

[Shadow Hog]

Incidentally, should discussion of expansion to the spec be relevant again, I wonder if it'd be better off in the dedicated thread for the format moreso than the thread of this port implementing it - though at this point I guess it'd be moot, since this is the premiere port for it.

[Xaser]

Unknown keys will need to be ignored, otherwise it's not possible for ports to implement port-specific properties in the future (the closest-to-consensus plan on that was to have prefixed keys, e.g. "eternity_foobar" for an EE-only option). If something more formal-ish gets drafted, that oughta go in there somewhere.

[ketmar]

27 minutes ago, Xaser said:

Unknown keys will need to be ignored, otherwise it's not possible for ports to implement port-specific properties in the future

which is not the best decision, i believe. how could i catch typos then? ZDoom does exatctly that: silently allows almost everything. and now we have alot of mods with typos, unbalanced brackets, wrong operands, and so on (i've seen alot of those, and had to severely break k8vavoom parsers to accept such nonsense). adding something like "-strict" CLI arg won't work (if it is not the default mode, it won't be used), the engine should always reject wrong syntax. or we'll end up with the same mess as in ZDoom.

 

that's why i keep asking about parsing details: i'd like to have a way to distinguish port-specific extension keys, and reject all unknown "standard" keys (this is either a typo, or something i cannot support anyway). also, it is hard to catch stray commas without strict key checking:

a = b,c,

d = e,

f

now i need a parser with lookahead buffer, and it is still impossible to know if "f" is a key, or a value without doing semantic analysis. that whole problem could be solved with terminators, but alas, that ship has sailed. (unless you'll codify newline as a proper and required terminator in specs).

[Gez]

1 hour ago, Xaser said:

the closest-to-consensus plan on that was to have prefixed keys, e.g. "eternity_foobar" for an EE-only option

This would be fine. It means there's only a need to maintain a list of known prefixes in the specs, and then parsers can ignore unknown keys if they start with such a prefix, but warn for unknown keys otherwise.

[ketmar]

there are no keys with underscores in names yet, so i think that the spec can say something like this: "a key with underscore in name is a port-specific extension key, and can be ignored". this way there is no need to know all prefixes (at least for sourceports, editors should still know them, i guess).

[fabian]

Debian uses the 'X-' prefix in their packaging control files to indicate keys that are not (yet) standardized. This tells the parser that it's alright to ignore them if they are unknown. 

[El Juancho]

One question, why the original secret found sound is not in the fork anymore? Is there any tutorial to put it back?

 

[seed]

It was purged long ago, along with other things.

 

It was also ZDoom's specific sound, which has since been replace with the respawn sfx.

[ChopBlock223]

Right, it was like a sound which Randi Heit mixed together ages ago. Does the engine still support applying your own DSSECRET sound?

[fabian]

Yes, you just need to load a PWAD with your custom dssecret sound lump. 

[El Juancho]

2 hours ago, seed said:

It was purged long ago, along with other things.

  

It was also ZDoom's specific sound, which has since been replace with the respawn sfx.

Why? I really really dislike the new sound

[Gez]

4 minutes ago, JuanchoES said:

Why? I really really dislike the new sound

AFAIK it was concerns about the legality of distributing it because it does not have a clear license or credit. It was made by Randi Heit who confessed having forgotten from which tracker module she took the sample.

 

The fallback replacement is actually not a new sound, but an old one, since it's a sound that is included in the Doom IWADs, normally used for item respawn in multiplayer and therefore never heard in single player so it's okay to repurpose it as a secret found chime.

 

But if you load a wad with a DSSECRET lump, it'll override that, so it's quite easy to get whatever sound you prefer to play instead.

[wallabra]

1 hour ago, Gez said:

AFAIK it was concerns about the legality of distributing it because it does not have a clear license or credit. It was made by Randi Heit who confessed having forgotten from which tracker module she took the sample.

 

Then why does ZDoom use it? I mean, sure, Randi was one of the main people behind it, but if she is unaware of the actual source of the sample/instrument used in OpenMPT in making the sound effect, that legal dubiousness should extend to ZDoom as well, right? Even if it's a source port she is involved in, it should be no more 'privileged' in this regard than any other open project that makes this file available publicly and non-commercially in some or another way.

[P41R47]

10 minutes ago, Gustavo6046 said:

 

Then why does ZDoom use it? I mean, sure, Randi was one of the main people behind it, but if she is unaware of the actual source of the sample/instrument used in OpenMPT in making the sound effect, that legal dubiousness should extend to ZDoom as well, right? Even if it's a source port she is involved in, it should be no more 'privileged' in this regard than any other open project that makes this file available publicly and non-commercially in some or another way.

Maybe the original source of that sound was found before going on for the selleable license.

If not... well, thats could complicate things :/

[Gez]

Because ZDoom doesn't care about getting included in Debian's distribution or whatever. There's a lot of other non-free content that's bundled with (like the game fonts) that would also be a blocker anyway. The deal is that all the stuff GZDoom absolutely needs to run is free-software-compliant and included in the core resource archive (gzdoom.pk3), while all the non-free assets are in technically optional files (game_support.pk3, lights.pk3, brightmaps.pk3) that you can remove if, for example, you want to distribute GZDoom with your own custom-made standalone game.

[wallabra]

1 minute ago, P41R47 said:

Maybe the original source of that sound was found before going on for the selleable license.

If not... well, thats could complicate things :/

 

You mean of the samples used to create the sound that is subject matter, right?

 

And, no, I don't think it was ever found, going by what Gez said.

 

Yes, things are complicated. Read carefully. :p

 

Just now, Gez said:

Because ZDoom doesn't care about getting included in Debian's distribution or whatever. There's a lot of other non-free content that's bundled with (like the game fonts) that would also be a blocker anyway. The deal is that all the stuff GZDoom absolutely needs to run is free-software-compliant and included in the core resource archive (gzdoom.pk3), while all the non-free assets are in technically optional files (game_support.pk3, lights.pk3, brightmaps.pk3) that you can remove if, for example, you want to distribute GZDoom with your own custom-made standalone game.

 

Ah, I see. So those optional "semi-official add-on" files only come with GZDoom in the binary distributions in the website? Wouldn't that still be copyright infringement, though? Wouldn't that make the ZDoom website host liable? What if Bethesda suddenly felt like sending a DMCA takedown notice letter? Big corporations tend to be snappy like that.

Tl;dr how are these files even able to be distributed in the first place?

 

Honestly, it's a miracle ZDoom worked out, for a multitude of reasons, including legal ones. I think the one advantage it has over other ports is its legacy, being known for decades to be a reliable and fairly advanced and feature-full source port, which may have helped boosted its popularity as people saw little reason to switch to other, less "standard" ­– or "non-state-of-the-art" – so-called advanced source ports, like Vavoom or the Eternity Engine.

[P41R47]

6 minutes ago, Gustavo6046 said:

 

You mean of the samples used to create the sound that is subject matter, right?

 

And, no, I don't think it was ever found, going by what Gez said.

 

Yes, things are complicated. Read carefully. :p

yeah, i get it.
I was just guesing.

From what Gez said, maybe thats how they go out with it.

Locating that sound on the non-free assets file.

 

Kinda dickish move, anyway, as they probably didn't found the source of the sound and are still redistributing it without permission :/

[Gez]

7 minutes ago, Gustavo6046 said:

Ah, I see. So those optional "semi-official add-on" files only come with GZDoom in the binary distributions in the website? Wouldn't that still be copyright infringement, though? Wouldn't that make the ZDoom website host liable? What if Bethesda suddenly felt like sending a DMCA takedown notice letter? Big corporations tend to be snappy like that.

Tl;dr how are these files even able to be distributed in the first place?

There's a Latin phrase for this: de minimis non curat lex.

 

astoundingly, nobody has come forward to litigate about the use of an unrecognizable 1-second sample sound taken (but not necessarily originating) from some random demoscene module nearly 30 years ago. and whoever the copyright owner for that sample is, they're probably not Bethesda or another ZeniMax subsidiary.

 

As for the fonts and stuff -- yeah, sure, but programs like DoomWord would also be in jeopardy then, as well as probably like 97% of the /idgames archive content.

[wallabra]

12 minutes ago, Gez said:

There's a Latin phrase for this: de minimis non curat lex.

 

Litigation is one way to make quick buck. Sometimes the defendant isn't even able to defend themself, particularly if they can't even pay to fight the case, requiring them to represent themself without a lawyer (pro se defensive). Thus it is easy to obtain a lot of legal reparations (monetary restitution) through unfairly won court cases, = $$$.

 

12 minutes ago, Gez said:

astoundingly, nobody has come forward to litigate about the use of an unrecognizable 1-second sample sound taken (but not necessarily originating) from some random demoscene module nearly 30 years ago. and whoever the copyright owner for that sample is, they're probably not Bethesda or another ZeniMax subsidiary.

 

Ah, yeah. In that particular instance it wouldn't be ZeniMax. Almost missed that for a moment.

 

12 minutes ago, Gez said:

As for the fonts and stuff -- yeah, sure, but programs like DoomWord would also be in jeopardy then, as well as probably like 97% of the /idgames archive content.

 

So? Do you think corporate cares? Maybe? I mean, no, really, maybe they do, if it could be dangerous to the community and all this content in a way that harms their profit Doom's legacy.

 

20 minutes ago, P41R47 said:

Kinda dickish move, anyway, as they probably didn't found the source of the sound and are still redistributing it without permission :/

 

 

Anyway, since this isn't a ZDoom thread, I will bring this thread back to the topic of Graf's PRBoom+ fork with style:

 

there ain't no alsa-salsa here in town yet, pal

[fabian]

I have come up with this as a changelog / revision tracker, that I'd like to append to the spec doc. Is everybody fine with this?

Rev 1.3 (@fabiangreffrath, Mar 5 2021)
 * If interbackdrop does not specify a valid flat, draw it as a patch instead.

Rev 1.2 (@JadingTsunami, Feb 12 2021)
 * Fix typo in ZDoom-style Actor name.

Rev 1.1 (@XaserAcheron, Jan 24 2021)
 * Updates to the UMAPINFO docs to disambiguate the 'bossaction' field a bit.

Rev 1 (@coelckers, Jul 10 2017)
 * Updated UMAPINFO spec to curly brace syntax.

Rev 0 (@coelckers, Apr 22 2017)
 * Initial implementation.

An entry would be added each time the document changes (and the document is supposed to get updated each time the implementation changes), so other ports can precisely track which revision of the spec they support.

[seed]

That sounds pretty good.

 

Eternity has a similar tracker too, but for more things, I think.

[ketmar]

32 minutes ago, fabian said:

Is everybody fine with this?

in 1.3, "interbackdrop" is 2-arg key, not 1-arg as it was before. i think this should be mentioned in changelog. otherwise it looks ok, thank you!