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

Crispy Doom 6.0 (Update: Mar 31, 2023)

Recommended Posts

On ‎14‎.‎03‎.‎2017 at 0:43 PM, fabian said:

Edit: Update! Got a reply from Jay Wilbur who redirected me to "the gang at id Software". ;)

It's been one week since I contacted id software without a response. Tried again just now...

Share this post


Link to post

Mention in your letter that you'll take an absence of response as a tacit agreement.

Share this post


Link to post

...I'm sorry? I would have thought an absence of response would signify that permission has not been given...

Share this post


Link to post
On 3/20/2017 at 9:50 PM, Wagi said:

I think it's important to warn you ahead of time that Heretic and Hexen look like trash if they are rendered in truecolor, so a flag should be introduced in case users want to switch to 8-bit mode.

 

This is because the the cyan colors are designed to fade to deep blue instead of dark cyan in the original COLORMAP. The same goes for the color range that goes from yellow to red (like lava). Simply interpolating from these colors to black will make certain levels look "washed out", like the beginning of E3M2.

There should be no technical reason why 32-bit color support should have a more-negative effect than 8-bit color, as the former is a superset of the latter. And, regardless, there's definitely no reason that some tweaking couldn't improve things in general, and specifically for troublesome palettes. For example, maybe for Heretic, the darker levels of the palette could be derived with an algorithm, using only the original, bright palette, thereby ignoring the darker transitions. Or you could even interpolate between the algorithm and the darker palette, for a blend of both effects. This could even be user-adjusted to taste.

 

My point is that, being a superset of 256 colors, 32-bit color can do everything 8-bit can do, and much more. If 32-bit does not, at a bare minimum, look as good as 8-bit, something is simply being done wrong. (I don't know this to be true, nor do I believe that that is the case).

 

In other words, perhaps some special-case code could provide extra attention to, for example, the cyan and yellow transitions, to combat the effect you're describing. This could even be automated with code that tweaks colors, based on the results of a color-matching function that detects poor transitions.

 

Personally, I always found the Heretic, Hexen, and Strife palettes to be much more balanced, in general than the Doom palette. (Not the brightness translations, just the array and range of colors chosen). My guess is that they were built with generality in mind, whereas the Doom palette was built to support the first early textures and sprites, and then largely ignored as more and more images were created. This is unfortunate - it could have been done a lot better, and provided better light-to-dark transitions.

Share this post


Link to post

I have a feature request: since every feature added so far is specifically to not break compatibility with the original while adding cool new features, I had an idea for one that isn't in vanilla ports but I'm sure many people would find useful. What if whenever someone included midi's for D_E4M1-D_E4M9, it would automatically use them instead of the default tracks from other maps?

Share this post


Link to post

The problem with that is that AFAIK no other ports have such a feature. I don't think even ZDoom has that feature.

edit: I'm specifically excluding stuff like mapinfo here.

Edited by Danfun64

Share this post


Link to post
4 hours ago, Danfun64 said:

The problem with that is that AFAIK no other ports have such a feature. I don't think even ZDoom has that feature.

edit: I'm specifically excluding stuff like mapinfo here.

It will...

Share this post


Link to post

Adding that feature would break compatibility with the vast majority of Doom ports as they would all ignore the e4 midis, leaving a situation where one port plays different music than another port. Had this feature existed in the days of DOSDoom and Boom maybe it would be worth implementing, but otherwise it breaks port compatibility for the obituary reason that it can't play music in the correct order.

Share this post


Link to post
1 hour ago, Danfun64 said:

Adding that feature would break compatibility with the vast majority of Doom ports as they would all ignore the e4 midis, leaving a situation where one port plays different music than another port. Had this feature existed in the days of DOSDoom and Boom maybe it would be worth implementing, but otherwise it breaks port compatibility for the obituary reason that it can't play music in the correct order.

Nah, IMO it'd be like "if your port is ancient crap than tough luck, you're stuck with that sucky e1m8 midi, but... if you're using the badass crispy doom 4.0, you have a brand new mega badass midi OMG that port is so cool!", that seems like a legit attitude to me, although expressed a bit offensively.

 

Just like you can have an optional OGG track in a vanilla map and use MAPINFO to play the OGG version in ports that can do it, but leave vanilla with a MIDI without breaking anything.

 

edit: I'm not trolling, hahaha :]

Edited by bzzrak

Share this post


Link to post
12 minutes ago, bzzrak said:

Nah, IMO it'd be like "if your port is ancient crap than tough luck, you're stuck with that sucky e1m8 midi, but... if you're using the badass crispy doom 4.0, you have a brand new mega badass midi OMG that port is so cool!", that seems like a legit attitude to me

No, it's not. It's deliberately throwing away compatibility for no reason. There is still a (albeit) small community that uses things like the original dos executables. Not to mention the fact that modern ports like PrBoom-Plus, Eternity, Zandronum, Doomsday lack this feature. How much work would it be to add this feature in some very different ports, especially with PrBoom-Plus, which stresses compatibility and would deliberately have the feature turned off on anything but the latest complevel. Not to mention that would make things more confusing because technically Crispy Doom works with the equivalent of PrBoom-Plus's complevels 2, 3, and 4. At least with the case of ogg tracks shared with midis the tracks are usually the same even if they sound different.

 

Then again, you could be trolling me. I mean, you have the Post Hell banner as your avatar.

Share this post


Link to post
47 minutes ago, Danfun64 said:

It's deliberately throwing away compatibility for no reason.

Last time I checked, Crispy Doom has jumping and the ability to enable finite heights, both of which break compatibility when used. You make it sound like adding this feature would hereafter mandate its functionality, when there is clear precedent to make such things optional. From the Crispy Doom readme:

Quote

All of these features are disabled by default and need to get enabled either in the in-game "Crispness" menu or in the crispy-doom-setup tool.

I also don't accept the argument that Crispy Doom lacks freedom to enhance itself without precedent. Chocolate Doom, sure (even the type of precedent is critical in that case), but Crispy Doom can do what it wants. If it ends up being the only port that makes use of it, that's fine.

 

These aside, would changing the music currently playing actually affect savegames or demos? I was under the impression that you could, for instance, record a Plutonia demo, then playback while also including the Plutonia MIDI Pack PWAD and everything would be a-okay. Or is it the other way around that messes things up?

Share this post


Link to post

Guys, this feature will be implemented in a completely backward-compatible way: When you load an Episode 4 map, the engine will look if there's a D_E4Mx lump available and if it is, it will play this one and it will play the replacement music else. This way nothing changes unless the map/episode author decides to add his own music to his own map/episode. The patch will be nearly trivial and if you feel better, I will port it over to PrBoom+ and submit it to Andrey as well.

Share this post


Link to post

As long as this new feature (like the aformentioned jumping and finite actors) is disabled when doing demo recording or multiplayer, i'm happy.

Share this post


Link to post

In how far does this feature affect demos recording or multiplayer games?! It's about playing music that needs to be specifically prepared and is ignored else...

Share this post


Link to post

Unlike jumping and finite actors, adding an episode 4 specific music feature doesn't break demos. That being said, they will cause inconsistencies when playing with different ports. The problem already exists with MBF sky transfers appearing in Prboom-Plus's -complevel 9, even though they don't appear in Boom. I just don't want a repeat of that.

Share this post


Link to post

I understand, but these are completely different issues (and I am not maintaining complevels, just demo-safe vs. demo-breaking). This has nothing to do with singleplayer-only games.

 

If a map author picks up this feature and wants you to listen to a specific track in his episode 4 map, you will hear it even if you record a demo of it or play it with others.

Share this post


Link to post
3 hours ago, Danfun64 said:

Not to mention the fact that modern ports like PrBoom-Plus, Eternity, Zandronum, Doomsday lack this feature.

But except for PrBoom+, they all feature other ways to assign arbitrary music lumps to maps, so you could still make the behavior consistent through the magic of MAPINFO.

 

 

Edit: for PrBoom+, you can still change the music to an arbitrary one with MUSINFO and putting a music changer in the starting sector.

Share this post


Link to post

Wow. Are we really at a point that nobody can implement a feature unless it was already made before?

 

Come on. It's totally unobvious and stupid that Doom doesn't have actual tracks for episode 4. Giving WAD makers the freedom to explicitly define them is a good idea.

Share this post


Link to post
4 hours ago, Danfun64 said:

Adding that feature would break compatibility with the vast majority of Doom ports as they would all ignore the e4 midis, leaving a situation where one port plays different music than another port. Had this feature existed in the days of DOSDoom and Boom maybe it would be worth implementing, but otherwise it breaks port compatibility for the obituary reason that it can't play music in the correct order.

Using your logic strictly across all features of all ports would leave you with a dozen vanilla ports. You can't add a feature to your port unless everyone does?

 

Let me back up and say that, Yes, I wish the port authors would agree to collaborate, and maintain an online document that specifies how new features work, and which resources each new feature uses (line types, sector flags, etc. That should have happened a long time ago. There's no reason why we're all stuck at MBF compatibility, unable to put more features into the list of compatibilities.

 

But, instead, devs moved forward and added features without checking with other ports, so we have port-specific maps, and I don't think that's going to change any time soon. I wish it would, but it doesn't seem likely.

 

However, there is UDMF which is standardized, and there's DECORATE which has been adopted by Eternity, for one, and could be considered a standard.

 

My point is that, there's no reason Crispy can't add D_E4M1-D_E4M9 support, and call the wads that include them "Crispy-compatible". Most likely, if enough maps add these lumps, other ports will probably follow add support for them as well.

Share this post


Link to post

DECORATE hasn't been adopted by Eternity; just its syntax for simple definition of states.

Share this post


Link to post

...this is the point where I realize that I said too much and might have gotten too pasionate. Sorry...

 

/me walks away from this specific issue

Share this post


Link to post
24 minutes ago, Gez said:

DECORATE hasn't been adopted by Eternity; just its syntax for simple definition of states.

Ok. I call that "adopted". That's a move towards compatibility. Each engine that does adopt it will probably have their own dialect, but as long as the basic syntax is there, people will be able to use their experience to alter frame definitions with ease.

 

In a way, this actually expands the definition of DECORATE a bit. It's kinda like American English vs. British English. Both are English, but there's differences.

 

It would be cool if other ports could agree on a basic frame definition language, like a Basic DECORATE syntax. Why DECORATE? It's used a lot (in ZDoom), so it's mature and well known, and it's very compact and simple. Then ports could have a chance at loading a WAD with DECORATE definitions, built for a different port.

Share this post


Link to post

 

12 minutes ago, Danfun64 said:

...this is the point where I realize that I said too much and might have gotten too pasionate. Sorry...

 

/me walks away from this specific issue

Nah, no big deal. Compatibility is important, and it's important to add features carefully, to avoid compatibility issues. It always sucks when you want to play a game, but a compatibility issue pops up. Hopefully, it pops up at the start, and not when you're 45 minutes into a game, and a door won't open, or a path is blocked, or even the game crashes. It's a good thing to point out possible compatibility issues caused by the implementation of a new feature, or any other time as well. No big deal.

Share this post


Link to post

Hey, if you're hearing out suggestions for new features, I've always thought it'd be really cool to be able to see statistics for stuff like your accuracy and health conservation while you're playing. It's helpful to be able to measure your progress in specific terms.

Share this post


Link to post
1 hour ago, kb1 said:

Ok. I call that "adopted". That's a move towards compatibility. Each engine that does adopt it will probably have their own dialect, but as long as the basic syntax is there, people will be able to use their experience to alter frame definitions with ease.

 

In a way, this actually expands the definition of DECORATE a bit. It's kinda like American English vs. British English. Both are English, but there's differences.

That's one way to look at it; but to me it's like saying that both JavaScript and PHP are C++ (after all, they all use the same syntax based on curly braces and semicolons).

Share this post


Link to post
1 hour ago, Gez said:

That's one way to look at it; but to me it's like saying that both JavaScript and PHP are C++ (after all, they all use the same syntax based on curly braces and semicolons).

Is it really that bad? I haven't seen examples yet, but I thought the goal was to provide similarity. Maybe you mean C vs. C++? :)

Is it just that it's not yet mature, or has it actually gone down a different path?

Share this post


Link to post

Deeeerp boring off topic.

 

I like the E4 music idea, weird that noone has done it already?

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
×