Crispy Doom 6.0 (Update: Mar 31, 2023)

[VGA]

Excellent!

1) I have selected my native res, but there are black bars all over. Also, no widesreen support? (hor+ please) Using 1680x1050 here.

2) Can The Trooper's Playground somehow be automatically launched? (Its wad was supposed to be merged with NWT to doom2.wad)
"nwt -merge ttp.wad"
http://www.doomworld.com/idgames/?file=levels/doom2/s-u/ttp103.zip
I tried loading it but it throws an error about duplicate lumps

[fabian]

VGA said:

1) I have selected my native res, but there are black bars all over. Also, no widesreen support? (hor+ please) Using 1680x1050 here.

Nope, this is Doom. There is no widescreen support. However, you may expect the horizontal black bars to vanish as soon as we have switched rendering to SDL2.

Edit: What I meant to say was that the 1.6:1 aspect ratio is a crucial characteristic of Doom's renderer; it is assumed/expected and hard-coded everywhere. Supporting any other aspect ratio *properly* would mean to support a different field-of-view all over the code and is much more intrusive than e.g. doubling the resolution. So, it is rather unlikely that this will ever get introduced. But, the scaling quality will be much improved in future releases of both Choco and Crispy.

2) Can The Trooper's Playground somehow be automatically launched? (Its wad was supposed to be merged with NWT to doom2.wad)
"nwt -merge ttp.wad"
http://www.doomworld.com/idgames/?file=levels/doom2/s-u/ttp103.zip
I tried loading it but it throws an error about duplicate lumps

Does it work if you start it by "crispy-doom -file TTP.WAD -nwtmerge TTP.WAD -deh TTP.DEH"?

[VGA]

It works! Pretty awesome work overall, can't wait for SDL2 improvements!

I have a serious (for me) feature request. When I hold right-click to mouselook, then when I release it I want the view to return to normal (like in zdoom), it's fiddly to have to re-press the button to re-center the view each time.

Also, is it possible to have an option for the awesomely satisfying "secret revealed" sound that other ports have?

And lastly all those mouselook options are confusing, why are there both a freelook option and allow vertical aiming?

EDIT: The map markers aren't properly saved in the savegame?

[fabian]

VGA said:

It works! Pretty awesome work overall, can't wait for SDL2 improvements!

Yes, me too. But I am waiting for Choco to merge the WIP sdl2-branch before I do the switch in Crispy.

I have a serious (for me) feature request. When I hold right-click to mouselook, then when I release it I want the view to return to normal (like in zdoom), it's fiddly to have to re-press the button to re-center the view each time.

I think it depends on what you are used to. I, for example, wouldn't want it any other way.

Also, is it possible to have an option for the awesomely satisfying "secret revealed" sound that other ports have?

Crispy Doom currently plays the item respawn sound when a secret is revealed. I think the DSSECRET sound that many other ports play comes from ZDoom but its origin and licensing is unclear. Also, I don't want to introduce any additional non-Doom resources into Crispy Doom.

And lastly all those mouselook options are confusing, why are there both a freelook option and allow vertical aiming?

Free Look means you can look up and down but shooting is always horizontal, as in Doom. Vertical Aiming means that you shoot in the actual direction that you are looking into. For example, you cannot beat the IOS from the highest platform position with the former, but only with the latter.

EDIT: The map markers aren't properly saved in the savegame?

I'll have a look at it, thank you!

Edit: Erm, is it possible they aren't even saved in Vanilla as well? Sorry, but I am not going to sacrifice savegame compatibility for this.

[VGA]

Maybe this will help:
https://github.com/fragglet/mbf/blob/master/am_map.c
// Revision 1.13 1998/02/23 04:08:11 killough
// Remove limit on automap marks, save them in savegame

That vertical aiming option sounds useless, maybe it should be always on? One less option to make room for ..... drum roll ...... LOOKSPRING!

http://zdoom.org/wiki/CVARs:Configuration#lookspring

:-D

[fabian]

VGA said:

Maybe this will help:
https://github.com/fragglet/mbf/blob/master/am_map.c
// Revision 1.13 1998/02/23 04:08:11 killough
// Remove limit on automap marks, save them in savegame

Yep, Boom. Boom's savegames were incompatible with Vanilla's and as stated above, I am not going to sacrifice savegame compatibility with Vanilla for this.

That vertical aiming option sounds useless, maybe it should be always on? One less option to make room for ..... drum roll ...... LOOKSPRING!

http://zdoom.org/wiki/CVARs:Configuration#lookspring

:-D

No, it's not useless, it's crucial. It makes a huge difference if you are bound to Doom's autoaiming or are free to shoot in whatever direction you like.

[VGA]

Of course, but why would someone want to look up and be firing horizontally? Autoaim works anyway, right?

[fabian]

VGA said:

Of course, but why would someone want to look up and be firing horizontally? Autoaim works anyway, right?

To prevent "accidental" triggering of events that were not possible in Vanilla. I have already given the IOS example and people have pointed me to some secret alcoves in MAP16 that have suddenly become shootable, when I was asked to make this feature optional. Yes, it was once enabled by default, but its impact on gameplay was considered too severe. After all, mouse look should just enable you to look around, nothing more.

[VGA]

Why does Chocolate Doom work properly fullscreen (with vertical bars of course) but crispy Doom also has horizontal bars?

Also, on my system the music is super loud and the SFX are super low. I have music at 3 and SFX at 15 and still can hardly hear anything.

EDIT: Doom Retro fullscreen also is fullscreen.

[fabian]

VGA said:

Why does Chocolate Doom work properly fullscreen (with vertical bars of course) but crispy Doom also has horizontal bars?

Well, it shouldn't. Please make sure that both ports have "Aspect Ratio Correction" enabled and that both are set to the same screen resolution in the respective *-doom-setup tools.

Also, on my system the music is super loud and the SFX are super low. I have music at 3 and SFX at 15 and still can hardly hear anything.

I can confirm this, though haven't investigated why, yet. Music is set to "Native MIDI", right? Does the same happen also in Choco?

EDIT: Doom Retro fullscreen also is fullscreen.

DR doesn't count, its rendering has been changed vastly with respect to Choco/Crispy.

[VGA]

Oh, Choco was set at 640x480, I set Crispy Doom at the same, too, now it's fine. What advantage would a higher resolution have anyway? It's rendering internally at 640x480, right? And there's no upscaling, so...

Sound is unbalanced in Choco + its forks for me. Native midi.

[fabian]

VGA said:

Oh, Choco was set at 640x480, I set Crispy Doom at the same, too, now it's fine. What advantage would a higher resolution have anyway? It's rendering internally at 640x480, right? And there's no upscaling, so...

More precisely, it's rendered at 640x400 and then stretched to 640x480. If your screen supports this mode natively, you should probably stick to it. Any other resolution would just mean more software scaling and stretching involved.

Have I already mentioned that this will be done in hardware by your GPU once the switch to SDL2 has landed? ;)

Sound is unbalanced in Choco + its forks for me. Native midi.

Then I assume it's an SDL_mixer issue and there is not much we can do about it now. But interestingly the issue appears to be portable, as I am on Linux and suppose you are running Windows?

[Quasar]

*All* SDL ports do not have an independent native MIDI volume on Windows. That's old hat. In fact no application on any version of Windows after Vista or higher can have an independent MIDI volume. To get around it you have to either play the MIDI from another process, emulate MIDI entirely such as with FluidSynth, or hand-send every MIDI event to the system with manually tweaked volume, such as with PortMidi.

[VGA]

But the music volume is actually working. I had to turn it down to 2. I'm on Windows 7 x64.

EDIT: Lmao I see what you mean, it lowers the sfx, too :-D
Wow that sucks so bad.

[uhbooh]

Pretty cool port but i have to ask, why do the automap colors look darker?

[fabian]

uhbooh said:

Pretty cool port but i have to ask, why do the automap colors look darker?

This is because red-keyed doors are drawn in full red, so regular walls are drawn a bit darker so you can distinguish them.

[LexiMax]

I've been hacking on Crispy for a few days and I've got a question, why do you put additional player bits into player2_t instead of in player_t? Is there an incompatibility I might run into? What about mobj_t - do I need a mobj2_t?

[kb1]

AlexMax said:

I've been hacking on Crispy for a few days and I've got a question, why do you put additional player bits into player2_t instead of in player_t? Is there an incompatibility I might run into? What about mobj_t - do I need a mobj2_t?

To avoid disturbing the vanilla save format? (just a wild guess).

[fabian]

kb1 said:

To avoid disturbing the vanilla save format? (just a wild guess).

Yes, savegame compatibility is the reason. However, I was a bit over-cautious with this measure. Actually, Choco does not save the player_t structs as a whole, but saves them element-wise in saveg_write_player_t(). So, it *should* be safe to just add the fields in player2_t to player_t. Maybe I'll even do this one day...

[kb1]

fabian said:

Yes, savegame compatibility is the reason. However, I was a bit over-cautious with this measure. Actually, Choco does not save the player_t structs as a whole, but saves them element-wise in saveg_write_player_t(). So, it *should* be safe to just add the fields in player2_t to player_t. Maybe I'll even do this one day...

But then you create a compatibility issue in the other direction :)

[LexiMax]

fabian said:

So, it *should* be safe to just add the fields in player2_t to player_t. Maybe I'll even do this one day...

Okay, cool, just making sure I wasn't missing anything. As for what I'm working on...well...as of about 30 minutes ago I got this little number working.

https://github.com/fabiangreffrath/crispy-doom/compare/master...AlexMax:uncapped

Uncapped framerates with camera, mobj, and sector position interpolation! Demos work, running through a few levels works, haven't tested netplay or savegames, and there's probably some corner cases I haven't thought of. Hopefully the final patch will be easy enough to understand so anybody can add it to their chocolate-derivative if they want.

[fabian]

kb1 said:

But then you create a compatibility issue in the other direction :)

God forbid! Of course I would still ignore the additional fields during game loading and saving. It would just affect their internal representation as elements of the player_t struct instead of the player2_t struct.

AlexMax said:

Uncapped framerates with camera, mobj, and sector position interpolation! Demos work, running through a few levels works, haven't tested netplay or savegames, and there's probably some corner cases I haven't thought of. Hopefully the final patch will be easy enough to understand so anybody can add it to their chocolate-derivative if they want.

o_O Impressive! I'll surely give it some testing, maybe we can even work on merging this for the next Crispy release.

[LexiMax]

fabian said:

o_O Impressive! I'll surely give it some testing, maybe we can even work on merging this for the next Crispy release.

Cool!

I've done some more testing of it, saving and loading appear to work just fine for me, but when I tried to add an option for uncapped framerate to the menu I discovered that you were out of menu spaces on the first page and I didn't know how you wanted to rearrange the menu to accommodate the option.

A few more observations:

• Everything is interpolated, including monsters. ZDoom has an option to turn monster interpolation off for the following reason:
  

  Because ZDoom allows the framerate to go above 35 FPS, monster movement is interpolated by default so they move more smoothly and take advantage of the additional frames. However, the actual AI that moves them is still limited to the normal 35 tics per second rate. In some situations, this may cause jerky or inaccurate movement when ZDoom attempts to interpolate. This option (nomonsterinterpolation) can be enabled so that monsters will only visibly move at the 35 FPS rate.

  
  I can see how some people might want this option, but I'm not sure if you thought it was worth a separate switch for it or not.
  

• Instant lifts, like in king1, aren't exactly instant anymore. However, introducing an interpolation limit on the Z axis might have some undesired side effects, because such a limitation must be put in every interpolation that happens on the Z axis so things line up, and since Doom has no terminal velocity, this might cause the player camera to not interpolate during a big fall.

[VGA]

Can't you make it so that when instant floor raise/lower specials are triggered the interpolation stops for the next frame?

[LexiMax]

VGA said:

Can't you make it so that when instant floor raise/lower specials are triggered the interpolation stops for the next frame?

That would be much worse, as instead of there merely being Z-axis interpolation issues when your Z distance is greater than some limit, your entire gamesim has a gigantic hiccup when an instant lift is activated. Would not be nice for anybody in a netgame with you.

Also, I personally do not think that the effect as it stands looks bad at all - the only difference is that you would perceive the lift lowering or raising in the span of a single tic (28ms) instead of instantly, which is almost too fast for you to tell the difference.

[VGA]

I thought the gamesim runs at 35fps no matter what so there would be no problems with netgames and demos. But what do I know, I'm probably wrong :-D

Sometimes in ZDoom when on an instant raising lift I catch a frame inbetween the transition and it looks kinda bad, I guess that's what you mean? If ZDoom hasn't fixed it, then ... screw it :-D

Anyway I rarely see instantly raising floors with the player on them, they are totally shit. They really break the immersion and get on my nerves.

[LexiMax]

VGA said:

I thought the gamesim runs at 35fps no matter what so there would be no problems with netgames and demos. But what do I know, I'm probably wrong :-D

There would be no demo problem, the effect would simply be jarring, visually.

I made a few updates to the branch tonight - the biggest addition is a per-mobj flag that is turned on at the beginning of each tic and that you can turn off midway through if you don't want that mobj to interpolate that tic. I currently use it to disable interpolation when things go through teleporters, but there might be other uses for it.

I can't figure out how to respond to your github comments, so I'll just answer you here.

Stuff about the FPS counter

The FPS counter was intended as a quickie personal aid to help me ensure that I was actually uncapping the framerate correctly. I can certainly get it fixed up for you for real, though. Just know that I think moving where the FPS counter is rendered means that the FPS counter will end up being a frame out of date, but I don't think that will be too big of an issue.

Stuff about breaking non-doom games

My apologies - my Visual Studio solution is pretty hacked up since I had to upgrade it from whatever version was there (I use 2013), and because it wasn't kept in sync with the rest of the code changes. In my desperation to get Crispy compiled in the first place (and because I'm not a huge fan of the other games anyway) I removed the non-doom games from the solution and focused on doom. Folks, this is why you use CMake. :P

Stuff about whitespace

Can you please expand on what you mean by whitespace changes, especially considering that the commit you referenced was significantly reworked and I couldn't see the which lines your comments were referring to? I determined that Doom uses 4 space tabs with a hard tab of 8 spaces and seemed to randomly switch between tabs and spaces, so I decided to use 4 spaces as my indentation.

EDIT: Do you have any interest in ZDoom's player camera hack, where the player camera is updated immediately via a global variable instead of being interpolated to? Fair warning, it is kind of a hack, because I have to read the mouse before returning early in TryRunTics, which I would then use to update a global variable which gets appended to viewangle. If the thought of doing this doesn't sit well with you, I'm more than happy to leave it as it is.

[fabian]

Oh boy, so much to reply to. I'll try to keep myself short. ;)

AlexMax said:

I've done some more testing of it, saving and loading appear to work just fine for me, but when I tried to add an option for uncapped framerate to the menu I discovered that you were out of menu spaces on the first page and I didn't know how you wanted to rearrange the menu to accommodate the option.

Yes, we need a third "Crispness" menu page. I'll take care of that.

Everything is interpolated, including monsters. ZDoom has an option to turn monster interpolation off for the following reason:[...]
I can see how some people might want this option, but I'm not sure if you thought it was worth a separate switch for it or not.

I'd like to keep things as simple, short and logical as possible and would thus prefer to avoid another such option.

Instant lifts, like in king1, aren't exactly instant anymore. However, introducing an interpolation limit on the Z axis might have some undesired side effects, because such a limitation must be put in every interpolation that happens on the Z axis so things line up, and since Doom has no terminal velocity, this might cause the player camera to not interpolate during a big fall.

Again, please keep the rules simple and the exceptions few. ;)

Stuff about the FPS counter

The FPS counter seems like a good idea. It should probably get turned into a cheat code, just like the IDMYPOS map coordinate display.

What I'd like to see is the FPS being calculated in i_video.c in a function that returns them as a fixed point value. This function would be called in the appropriate place in doom/hu_stuff.c and the return value would be used to print the FPS information to the screen. The main issue is that there is no inter-game-portable print-to-screen function, i.e. Heretic and Hexen have no M_WriteText().

This would eventually fix the next point on the list:

Stuff about breaking non-doom games

Stuff about whitespace

I have seen in the branch-comparison page on Github that your branch adds and removes some blank lines and stuff like that. I am very sensible about these things, as I'd like to keep the diff between Crispy and Choco as small as possible, literally. So, please take care to not remove blank lines or trailing white space from lines that are not part of your actual changes.

EDIT: Do you have any interest in ZDoom's player camera hack, where the player camera is updated immediately via a global variable instead of being interpolated to? Fair warning, it is kind of a hack, because I have to read the mouse before returning early in TryRunTics, which I would then use to update a global variable which gets appended to viewangle. If the thought of doing this doesn't sit well with you, I'm more than happy to leave it as it is.

Since I have absolutely no idea what you are talking about right now, the answer is probably "no". ;) Seriously, I haven't ever got in touch with ZDoom and if the approach you mention makes things harder to understand, harder to debug and probably puts demo/savegame/netgame compatibility at risk, its is pretty sure not worth it.

Thank you very much already!

Uncapped playing already feels awesome. I am looking forward to your pull request. ;)

[DXBigBoss]

Any interest in adding an eight player mode? If you add me on Skype I could give you some unfinished code I did with chocolate-doom 1.7.0 trying to implement it, the color ramping works perfectly fine, chat messages work fine too, but it only works in deathmatch since there are no additional player starts in stock Doom maps, and the game also crashes at the intermission screen due to me not knowing how to make an external WAD that stores HUD sprites and whatnot for players five through eight.

[fabian]

DXBigBoss said:

Any interest in adding an eight player mode? If you add me on Skype I could give you some unfinished code I did with chocolate-doom 1.7.0 trying to implement it, the color ramping works perfectly fine, chat messages work fine too, but it only works in deathmatch since there are no additional player starts in stock Doom maps,

Multiplayer-only features have never been of high priority for me. But one thing that I consider important is compatibility with Chocolate Doom. It should always be possible to play with a mixed multiplayer setup of Chocolate Doom and Crispy Doom. I guess this would be sacrificed here, right?

Implementation-wise, you had to increase the MAXPLAYERS macro, right? Sorry, but this has too much impact on too many unrelated code paths, that I'd outright deny such changes. So, sorry, but "no, thanks".

and the game also crashes at the intermission screen due to me not knowing how to make an external WAD that stores HUD sprites and whatnot for players five through eight.

Maybe you should try to re-arrange the intermission screen with the HUD font instead of relying on graphics lumps from external WADs?

Your approach sound interesting, nevertheless, so how about publishing your changes? People could review the code and give some valuable advice. And I guess there are other forks that would like to merge your changes.