Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Linguica

PrBoom+ name bikeshedding

Recommended Posts

4 hours ago, Spectre01 said:

-longtics for -cl9 in @cybermind's port are certainly nice to have.

 

From a compatibility standpoint it does not make sense to allow prb+ to create demos that would crash Boom.exe in the case where the original port would otherwise have no problems with loading the wad. If Boom couldn't load the wad in the first place (due to the map itself violating some other limits of the port) then it's fair game maybe, but it seems straight wrong for the demo itself to be the source of the crash, defeats the purpose of what complevel 9 is supposed to be.

Share this post


Link to post

Agreed, but this can easily be handled by invalidating the demo the same way it is done for UMAPINFO.

Tying longtics to the complevel doesn't sound right, it should be a separate option.

 

Share this post


Link to post
23 minutes ago, Ribbiks said:

 

From a compatibility standpoint it does not make sense to allow prb+ to create demos that would crash Boom.exe in the case where the original port would otherwise have no problems with loading the wad. If Boom couldn't load the wad in the first place (due to the map itself violating some other limits of the port) then it's fair game maybe, but it seems straight wrong for the demo itself to be the source of the crash, defeats the purpose of what complevel 9 is supposed to be.

 

I believe this is gonna go offtopic but how does vanilla doom and chocolate doom handle -longtic demos. If they cannot run -longtic demos, then doesn't that mean that PrBoom+ has already done something that defeats the purpose of a complevel (according to your opinion) 

Share this post


Link to post
19 minutes ago, ReaperAA said:

I believe this is gonna go offtopic but how does vanilla doom and chocolate doom handle -longtic demos. If they cannot run -longtic demos, then doesn't that mean that PrBoom+ has already done something that defeats the purpose of a complevel (according to your opinion) 

 

Vanilla crashes (unless you apply a patch to the exe). Chocolate, as far as I understand, has some auto-detection and will play back both short/longtics, perhaps begrudgingly. prb+ seems to employ similar methods for allowing you to record and playback longtics demos on cl2/3 if you really want to. Overall this seems to be a gray area. It "feels" wrong to me to allow longtics for cl2/3, but there is likely some community/historical context I'm missing here (like, at one point in time did a majority of demo recorders agree that vanilla ports should support longtics? Did a similar patch ever exist for Boom?).

Share this post


Link to post

It is definitely a gray area. But if demo recorders did agree that vanilla complevels (cl2/cl3) should support longtics, then I see no reason why they wouldn't allow longtics support for Boom/MBF demos (cl9/cl11).

Share this post


Link to post
1 hour ago, Ferk said:

I'd vote for UBoom

 

Will agree with this, on the principle of keeping it simple (though I'd have capitalised it as 'uBoom' personally, but this is barely relevant) -- almost commented suggesting 'xBoom', but I have no good justification for the 'x' other than just plain liking the letter. 'UBoom' in whatever form makes sense given the UMAPINFO development.

Share this post


Link to post
32 minutes ago, ReaperAA said:

It is definitely a gray area.

 

AFAIK the reason to allow longtics is because a hacked vanilla EXE exists that can produce them.

 

Share this post


Link to post
On 6/16/2019 at 8:20 AM, Linguica said:

Can we rename prboom+ yet? It's named for a coder who has been gone for decades, and has a suffix denoting it as a fork by another coder who has also been gone for years. It is also very Google unfriendly.

 

I propose the following names:
- BetterThanDoom
- TyDoom
- ProBoom
- DoomPlus
- PrBoomPlusOne
- Doom2008 (last update)
- StrawberryDoom (since chocolate and vanilla are taken)
- Doomy

Boom 2 seems like the best real name.

Edited by geo

Share this post


Link to post
12 minutes ago, TheMightyHeracross said:

PrBoom+ was last updated in 2016.

 

2017 when it switched to SDL2...

 

Apart from saying "test" in the name it's very much stable and everything works in it (it's also the only option on newer versions of Windows), I would prefer people stop saying 3 years...

 

32 minutes ago, geo said:

- DoomPlus

 

That one is taken too.

Share this post


Link to post

The last download package is from 2016, that's why people say 3 years.

 

In response to this thread I have a suggestion: Bikeshed Doom. :D

 

Share this post


Link to post

I suspect that's more a debate about whether we're talking last stable release or last experimental release, and whether the inclusion of "test" in the version name means it counts as the latter or if it's still considered the former.

Share this post


Link to post
4 minutes ago, Shadow Hog said:

I suspect that's more a debate about whether we're talking last stable release or last experimental release, and whether the inclusion of "test" in the version name means it counts as the latter or if it's still considered the former.

 

I think it should still be counted as stable honestly, apart from switching to SDL2 there's no other major changes in 2.5.1.5 that would make it a more experimental version.

Share this post


Link to post
2 hours ago, Ribbiks said:

 

From a compatibility standpoint it does not make sense to allow prb+ to create demos that would crash Boom.exe in the case where the original port would otherwise have no problems with loading the wad. If Boom couldn't load the wad in the first place (due to the map itself violating some other limits of the port) then it's fair game maybe, but it seems straight wrong for the demo itself to be the source of the crash, defeats the purpose of what complevel 9 is supposed to be.

 

Actually, Cybermind did it right by tagging such demos with a new version. So no worries on that front. Only problem I am facing is that the repos are incompatible so I'll have to merge his stuff manually, that may take a little because it also contains some refactorings in other areas that are quite extensive.

 

Share this post


Link to post
1 hour ago, Jayextee said:

 

Will agree with this, on the principle of keeping it simple (though I'd have capitalised it as 'uBoom' personally, but this is barely relevant) -- almost commented suggesting 'xBoom', but I have no good justification for the 'x' other than just plain liking the letter. 'UBoom' in whatever form makes sense given the UMAPINFO development.

 

Yes, the first letter being lowercase feels better, I didn't even think about that. Also, I said xBoom too: extended Boom. I think universal Boom is better though. 

Share this post


Link to post

@Graf Zahl I didn't know a port's primary purpose was to be the most popular.

 

On 6/16/2019 at 2:20 PM, Linguica said:

Can we rename prboom+ yet?

I get why but PRBoom+ has name recognition and endless posts about it. If we're not making some brand new port why lose that? It's just going to confuse people, especially those new to the community or those watching old Youtube videos that mention the port by name.

Share this post


Link to post
8 minutes ago, Altazimuth said:

@Graf Zahl I didn't know a port's primary purpose was to be the most popular.

 

 

No need to be *most* popular, that "most" will most likely be decided by the alignment of the stars, but wouldn't you prefer to work on something popular than obscure?

 

Share this post


Link to post

Agreed with Altaz, it really doesn't need a new name. People already recognize it as PR+, so a change is guaranteed to be confusing. It's still effectively the same port as before, just with UMAPINFO added, yeah?

Share this post


Link to post

PRBoom+, if it has one singular singular successor with a different name, won't care immensely about naming when it has momentum already. Offer improvements people want to PRBoom+ that don't compromise the project's integrity and people will come. It has its niche and it's successful within it. As long as other ports respect a port's niche then they'll be fine; hell even if EE managed to support most PRBoom+ complevels it'll never knock it out of its niche.

PRBoom+ isn't Eternity. It doesn't need releases specifically for it to do well. GZDoom being able to play PRBoom+ WADs isn't some awful threat to the port that means potential users will be lost. It doesn't need to be.

Share this post


Link to post
7 hours ago, Ferk said:

I'd vote for UBoom

 

I like this.

  1. It makes it clear that it's a Boom derivative.
  2. It's not yet another "extension" of the existing prefix or suffix.
  3. The port's headliner feature is UMAPINFO.  U just makes sense in that context.

Share this post


Link to post

I'm still confused, some people are talking about naming Graf's fork, but some are talking about renaming PrBoom+ itself, which is what I took from the OP. Which one is going on in this thread? Because I don't see how we can just rename someone else's port without their say.

Share this post


Link to post

This thread was created entirely out of posts from the thread about Graf's UMAPINFO-implementing variant, so it should be about that; the thread title doesn't actually mention that fact, however, which is probably why people are confused.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×