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

Crispy Doom 5.6.3 (Update: Oct 04, 2019)

Recommended Posts

fraggle said:

So I'm hitting that ball back into your court :)


But it lands out of bounds, sorry.

XCOPY, if you feel that network play with Chocolate Doom feels generally sloppy, maybe you should try the alternative network timing code. I think it has become the default in 2.1, have you tried with this version? Does this improve your experience?

Share this post


Link to post

Other way round, I'm afraid. Chocolate Doom has had "improved" network timing/sync code since I introduced the rewritten networking code back in v0.1.something. But there have been a whole load of problems with it and people understandably complaining. Because of that, I've switched back to the "old" sync code for the time being.

The old sync code was previously available with the -oldsync parameter; now it's reversed and the new sync code is available with -newsync instead. I still plan to come back to the -newsync code and try to fix it in some later version, but for the time being I figure it's better to have something that at least works reliably, even if old sync has issues itself.

But what XCOPY is asking for is really unrelated to this. He wants client side movement prediction, which eliminates the delay between inputs being sampled (G_BuildTiccmd) and the ticcmd being run with G_Ticker. Most modern games do this and all the "multiplayer" source ports (Odamex, Zdaemon, etc.) also do it. SMMU had an implementation of this as well so if you're intrigued at all then maybe take a look at the code. But I can't really add it to Chocolate Doom because it does change the gameplay experience somewhat.

Share this post


Link to post

Happy New Year everybody!

Update 02 Jan 2015: Crispy Doom 2.2 has been released!

Crispy Doom is a fork of Chocolate Doom that provides a higher display resolution, removes the static limits of the Doom engine and offers further optional visual, tactical and physical enhancements while remaining entirely config file, savegame, netplay and demo compatibile with the original.

Please visit the Crispy Doom homepage for more information:
http://fabiangreffrath.github.io/crispy-doom

The Crispy Doom source code is available at GitHub:
https://github.com/fabiangreffrath/crispy-doom

Binaries for Windows (x86) are available here:
http://www.greffrath.com/~fabian/crispy-doom_2.2.zip

Have a lot of fun!

- Fabian

Share this post


Link to post

Just tried this out and I am very happy to see this port. Good job.
Found a bug though. In the 2.2 windows build of Heretic & Hexen if you scroll the mouse wheel in the main menu the game locks. Doom and Strife do not.

Share this post


Link to post
raithe said:

Found a bug though. In the 2.2 windows build of Heretic & Hexen if you scroll the mouse wheel in the main menu the game locks. Doom and Strife do not.


Thank you very much for your bug report!

Actually, the bug you experience is also reproducible with Chocolate Heretic if you apply some action (e.g. change to prev and next weapon) to the mouse wheel "buttons". The main difference is that these mappings are set by default in Crispy Doom/Heretic.

The main reason for the lock is that in Heretic and Hexen, the MN_Responder() function refuses to "eat" mouse events and these are thus passed over to the G_Responder() function, This, in turn, tries to change weapons in a game that hasn't even started. Boom.

The following patch should fix this, will post a bug report against Chocolate Doom in a minute or so.

--- a/src/heretic/mn_menu.c
+++ b/src/heretic/mn_menu.c
@@ -1083,6 +1083,10 @@ boolean MN_Responder(event_t * event)
         }
     }
 
+    if (event->type == ev_mouse)
+    {
+        return true;
+    }
     if (event->type != ev_keydown)
     {
         return false;

Share this post


Link to post

Nice.
Spent some time running through E1 last night and I have to say this is a very nice port. All the features you need, with none forced on you, and it still feels like old doom should. Very cool.

Share this post


Link to post

I understand that many people have gotten Chocolate Doom to run on Raspberry Pi. As Crispy is a fork of Chocolate Doom, would any of the code introduced in Crispy prevent it from running on Raspberry Pi (say on a B/B+ board)? I ask because I'm thinking of getting one, and playing Doom on it would be fantastic.

Share this post


Link to post
mdmenzel said:

As Crispy is a fork of Chocolate Doom, would any of the code introduced in Crispy prevent it from running on Raspberry Pi (say on a B/B+ board)?

I don't think so. Portability is as much a priority for Crispy Doom as it is for Chocolate Doom. And "under the hood", both ports are still pretty much the same.

Share this post


Link to post

Think you might add doom retro's gamepad support? I just tried this for the first time but when I trieed to configure the gamepad (a logitech f310 which works perfectly with doom retro) the setup would not recognize the trigger buttons. And I could see no way to adjust the joystick sensitivity.

Share this post


Link to post

Requests regarding improvement of gamepad support come in quite regularly, so I guess there is really a demand for it. However, I don't think these improvements should be specific to Crispy Doom, but should rather get applied upstream.

There is already a bug report opened against Chocolate Doom regarding improved Joystick handling. Maybe you could add to this discussion:
https://github.com/chocolate-doom/chocolate-doom/issues/424

Share this post


Link to post

@Fabian: copying a small snippet of discussion from another thread because this one's more relevant.

Xaser said:

There have already been some third-party efforts to do chocolate-doom-plus like _bruce_'s build, but no such equivalent exists for Heretic (or Hexen, I suppose) just yet. Hence the ask, I suppose.

fabian said:

Actually, Crispy Heretic is just that. I stopped developing the Heretic, Hexen and Strife ports once I got high-resolution and limit-removing features ready. They are included in the package just as a convenience and as a bait to get people to pick up where I left them. ;)

Is Crispy Heretic really limit-removing? Or does it just raise the cap? I'm able to trigger (presumably) a VPO with this test wad: http://static.angryscience.net/doom/vpotest.wad

If it's still got an upper cap, what is it? Just so I don't accidentally nuke it in something I'm working on...

Share this post


Link to post
Xaser said:

Is Crispy Heretic really limit-removing? Or does it just raise the cap? I'm able to trigger (presumably) a VPO with this test wad: http://static.angryscience.net/doom/vpotest.wad

If it's still got an upper cap, what is it? Just so I don't accidentally nuke it in something I'm working on...


Crispy Heretic is not limit-removing, it merely has its limits increased to the ones of doom-plus/heretic-plus: http://www.chocolate-doom.org/wiki/index.php/Crispy_Doom#Raised_Limits

It hasn't changed from the state of Crispy 1.0 since then.

Share this post


Link to post

Huh, okay. I was confused because of the use of the phrase "limit-removing" in your earlier post before; that and the wiki page mentions outright removal of some limits (for just Doom, I suppose?) but later states that limits "for all four games" have been raised to that of Doom+. Which is it?

The search for a (non-ZDoom) limit-removing Heretic port continues, I suppose.

Share this post


Link to post

When I was talking about purists, I meant the kind of purist that would dislike the engine to have code that's not written in the same way as it is in the original Doom executable. As far as I know, Chocolate-Doom doesn't have any feature that's not available in Vanilla Doom, except features that are completely hidden and undocumented (like "-scanline" for example).

Share this post


Link to post

Congrats on 2.2 release.

The wiki page has wrong version (i.e. "Changes of Crispy Doom 2.1 from Crispy Doom 2.0" appears twice)

I think resurrection after death is a game-breaking feature, becoming too tempting for anyone who knows about the cheat. Of course all the cheats can "break" the gameplay, but I feel this one really goes too far. I added it to EDGE (way back when) and found myself using to way too much, so I removed it again.

Share this post


Link to post
Xaser said:

Huh, okay. I was confused because of the use of the phrase "limit-removing" in your earlier post before; that and the wiki page mentions outright removal of some limits (for just Doom, I suppose?) but later states that limits "for all four games" have been raised to that of Doom+. Which is it?

Sorry, I know it is confusing. The changelog on the Chocolate Doom wiki page is cumulative, so you'd have to read it from bottom to top to know what's the current state. :-/

Crispy Doom was always meant to be a Doom port only. It is just that in the Chocolate Doom code base, all four games share certain rendering routines. When I introduced the high-resolution rendering into Doom, that broke the other games and I had the choice to either remove them from the port or adapt them to the changes. I was eventually talked into doing the latter and so ended up releasing all four games as Crispy Doom 1.0. I have never touched the other three games since then and decided to remove them from the 1.1 release. However, I was then asked to still include them as an "unsupported" convenience and this is what they still are today.

The search for a (non-ZDoom) limit-removing Heretic port continues, I suppose.


I could remove the limits for Heretic as well, that's not a big deal. I suppose we are talking mainly about the VISPLANES limit here?

axdoom1 said:

When I was talking about purists, I meant the kind of purist that would dislike the engine to have code that's not written in the same way as it is in the original Doom executable. As far as I know, Chocolate-Doom doesn't have any feature that's not available in Vanilla Doom, except features that are completely hidden and undocumented (like "-scanline" for example).


Yes, Chocolate Doom has its own clear goals and Crispy Doom deviates from these by implementing the most-often requested (and rejected) features that do not interfere with its compatibility. However, most (all?) user-visible features are optional and I am sure that if you have them all disabled (and play Crispy Doom in "Graphic Detail: Low" mode) you cannot tell Crispy Doom and Chocolate Doom apart. That is, unless you pay very high attention to the rendering glitches that are present in Choco/Vanilla but fixed in Crispy. ;)

jmickle66666666 said:

looks like crispy doom is a good basic but (less) limited port to base new ones off of.


Yes, probably. But, actually, I forked Crispy Doom off of Chocolate Doom to avoid the necessity of any more forks. I think the most-often user-requested features are all there and anything else, if cleanly implemented, could get merged.

Anyway, you could use Crispy Doom as a "feature tool-box" if you like. I have literally commented every single line of code that I changed and I think it would be rather straight-forward to create another fork of Chocolate Doom with just, say, the limit removing parts of Crispy Doom copied over.

That being said, I'd enjoy collaboration. If there is anything that you miss in Crispy Doom and which would lead you into creating another fork, please contact me before and maybe we could find a way to implement it directly in Crispy.

andrewj said:

Congrats on 2.2 release.


Thank you!

The wiki page has wrong version (i.e. "Changes of Crispy Doom 2.1 from Crispy Doom 2.0" appears twice)


Oh my! Thanks, fixed. It's been there for two months now and noone noticed. /o\

I think resurrection after death is a game-breaking feature, becoming too tempting for anyone who knows about the cheat. Of course all the cheats can "break" the gameplay, but I feel this one really goes too far. I added it to EDGE (way back when) and found myself using to way too much, so I removed it again.


You mean IDDQD after death? I never use it, it makes me feel like a bitch. ;)

However, I found the original behavior highly irritating and counter-intuitive -- lying on the floor bleeding with 100% health. "No one can hurt me now!", yep. If you are cheating god mode after death you are surely expecting something different.

My general stance on cheats is "you cheat, your fault". ;)

Share this post


Link to post
fabian said:

Yes, probably. But, actually, I forked Crispy Doom off of Chocolate Doom to avoid the necessity of any more forks. I think the most-often user-requested features are all there and anything else, if cleanly implemented, could get merged.

Anyway, you could use Crispy Doom as a "feature tool-box" if you like. I have literally commented every single line of code that I changed and I think it would be rather straight-forward to create another fork of Chocolate Doom with just, say, the limit removing parts of Crispy Doom copied over.

That being said, I'd enjoy collaboration. If there is anything that you miss in Crispy Doom and which would lead you into creating another fork, please contact me before and maybe we could find a way to implement it directly in Crispy.

Cool to hear! My thinking was for the possibilities of using crispy doom as a game engine for a doom style game, with source modifications.

Share this post


Link to post

Update 04 Mar 2015: Crispy Doom 2.3 has been released!

Crispy Doom is a fork of Chocolate Doom that provides a higher display resolution, removes the static limits of the Doom engine and offers further optional visual, tactical and physical enhancements while remaining entirely config file, savegame, netplay and demo compatibile with the original.

Highlights of this release include:

* New Overlay and Rotate modes for the Automap
* Support for the secret E1M10 map of XBOX Ultimate Doom
* Merge of TEXTURE1/2 and PNAMES lumps
* Weapon Recoil Pitch
* Return of the Static Crosshair
* OGG/FLAC Music from lumps in PWADs
* Preloaded WAD/DEH files
* -mergedump parameter (DEUSF replacement)
* Rebuild of BLOCKMAP lumps
* Support for ZDBSP and DeePBSP nodes, support for Hexen map format
* Removed Z_Malloc errors
* Various rendering improvements
* etc...

Please visit the Crispy Doom homepage for more information:
http://fabiangreffrath.github.io/crispy-doom

The Crispy Doom source code is available at GitHub:
https://github.com/fabiangreffrath/crispy-doom

Binaries for Windows (x86) are available here:
http://www.greffrath.com/~fabian/crispy-doom_2.3.zip

Have a lot of fun!

- Fabian

Share this post


Link to post
fabian said:

support for Hexen map format

!!!
???

Share this post


Link to post
Gez said:

!!!
???

It's a gimmick that I added mostly because it was possible. From the release notes: "Please note that although it is now possible to load and explore maps in Hexen format, all interactions with their environment are most probably broken." ;)

Share this post


Link to post
Linguica said:

Hmm, full air control in noclip you say? You are a genius!

Ne, I have to return this compliment. ;)

Share this post


Link to post
fabian said:

I could remove the limits for Heretic as well, that's not a big deal. I suppose we are talking mainly about the VISPLANES limit here?

VISPLANES and VISSEGS are the big ones. The former's the one I'm hitting at the moment but the latter will inevitably pop up.

But yeah, if the inspiration strikes you to do this, I'd be exceptionally grateful (as would the RoP folks maybe, heh). "Limit-removing Heretic" isn't really a thing that exists at the moment -- Not with any sort of discernible baseline, at any rate. ;)

Share this post


Link to post

Aces! That was quick -- I'll see about getting a build compiled (though it may take a while since I'm on Windows :P ). Superthanks for this, sir!

Share this post


Link to post

Well, shoot. I feel like a spoiled child -- thanks there for the build, sir! :D

Seems to work well -- my map's behaving nicely now, so I think we may have a winner. :D

Share this post


Link to post

You may want to have a look at stderr output to see when exactly it raised the limits.

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
×