Crispy Doom 6.0 (Update: Mar 31, 2023)

[kb1]

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, 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.

I'd be interested in checking out your code.

[fraggle]

DXBigBoss said:

it only works in deathmatch since there are no additional player starts in stock Doom maps

The easiest solution to this problem is to "overflow" into using deathmatch starts for the additional players.

[DXBigBoss]

I'm planning to resurrect my secret project I was developing with Chocolate-Doom's code once the problem with 2.1.0 is fixed that is, the game executable still residing in the background even after closing it in Windows 7 64-bit.

[Marscaleb]

So, I may be hosting a Doom tournament at a local con in a month. If so, I *want* to use Crispy Doom to run the game, so we can have the more authentic experience but still have high-res mode.

However, I am concerned about having to police people's settings. The physical options seem to be automatically disabled in multiplayer, which is great. But there still is the cross-hair option. It may not be much, but it still gives an unfair advantage over other players.
I really don't want to have to babysit all the players and watch over all their screens to make sure they don't try to pull a fast one and switch their crosshair on, and I also don't want to allow crosshairs because I really feel like they detract from the experience.

Is there some way to disable the crosshairs for all players? Or perhaps is there some quick-fix that could be implemented in the next week or two? (Even if its not the main version but just a special compile just for this?)

I'd also be interested in an option to disable players from hitting the exit switch and ending a level early, and an option to add a frag limit instead of just a time limit. But I suspect that's not something that can be "quickly implemented."

Oh yeah, and it would be really nice if I had an option to save the results in a text file, so I could consult that text file in case people accidentally exit the results screen too fast to check who the winner is. The text file could also save the player name with the results, and not just a player number or color, so it would be easier to tell who scored what.

I also keep thinking I would want to exit the game when the level ends, or rather after closing the results screen, and drop back into the setup program to easily set up a new match. Or maybe create an in-game screen for launching multiplayer maps, like you can do in Duke 3D.

I know you state that you want to keep compatibility with Chocolate Doom's multiplayer, and I think that is a great idea. But what you might consider is having a separate second version of multiplayer. You'd have the Chocolate Doom multiplayer, or you could run a Crispy multiplayer, with all of your crispy-specific settings. 8-player games, jumping and other physical options, letting the host force those physical options, easy options to control and change settings on-the-fly and jump to specific maps all without exiting the game and going back into the setup program.
That would be sweet.

But for now I'm just curious about the crosshair thing. If I can get that squared away I can use crispy doom instead of chocolate doom for the tournament. (Oh and if you get a fix for the map-freeze glitch; I posted an issue about it on GitHub.)

[fabian]

Marscaleb said:

So, I may be hosting a Doom tournament at a local con in a month. If so, I *want* to use Crispy Doom to run the game, so we can have the more authentic experience but still have high-res mode.

That's great, thank you very much!

But for now I'm just curious about the crosshair thing. If I can get that squared away I can use crispy doom instead of chocolate doom for the tournament. (Oh and if you get a fix for the map-freeze glitch; I posted an issue about it on GitHub.)

The map crash is already fixed in git, thank you very much for reporting it. Crispy Doom needs a lot more testing like this.

Regarding your other wishes: Sorry, but I don't have plans to implement them. Not on the master branch, but also not on a special "for-marscaleb" branch. My time for Crispy Doom is rather limited at the moment. For example, Crispy 3.0 should have been released for some weeks now already, but I am (a) too lazy, (b) hate writing release notes and (c) hate building software on Windows -- all this combined with too little free time. :/

Also, I generally don't do for-favor builds, not even for projects like CNDoom. The problem is, once you start it, people want more of it and you are effectively maintaining a fork you never wanted. So, I am sorry, but I have to reject your wishlist, it's out of scope for Crispy.

BUT, Crispy Doom, being a fork of Chocolate Doom, is very easy to fork itself. The crosshair restriction patch, for example, is trivial to implement and most of the other stuff you mention ahould be rather easy, too. ;)

[Linguica]

This would be a janky "fix", but you could edit the IWAD to make the "+" hud font character just be a transparent patch.

[LexiMax]

fraggle said:

The easiest solution to this problem is to "overflow" into using deathmatch starts for the additional players.

Doesn't seem very playable, though - spawning players halfway across the map and all.

What if you spawned additional players on coop spawn points, but also "unblock" players so they can walk through each other?

[Marscaleb]

Sorry, I didn't know I had any kind of PM blocking enabled. Would that be a default setting? ...But I just checked my settings and it says PMs are enabled, so I don't know why it wouldn't work.

AlexMax said:

What if you spawned additional players on coop spawn points, but also "unblock" players so they can walk through each other?

It would be a bit more work, but it would be more sensible to only unblock them for a moment; like as soon as they start moving they go solid.

But I think the best option would simply be to create a function that checks if the spawn location is occupied, and wait until it is open before spawning.
Or at the very least, have players 5-6 override the normal spawn position by a small amount; spawn them directly in front of the regular spawn points. I'm pretty sure that no map has the players start with a wall right in front of them and no room to move forward.

[Marscaleb]

fabian said:

Linguica has posted a very comprehensive guide to build Chocolate Doom from source here: http://www.doomworld.com/vb/source-ports/73613-compiling-chocolate-doom-with-visual-studio-a-simple-ish-guide/

I guess that everything in this guide applies to Crispy as well.

Okay, I followed that guide but I wound up with a list of unresolved external symbols.
They each say "unresolved external symbol" The particular (uhh, symbols I guess,) are "_deh_section_bexpars" "_deh_section_bexptr" "_deh_section_bexind" "_crstr" (five times) "_bex_pars" "_bex_cpars" "_cr referenced in function _R_DrawSprite" "_cr" (six times) "_V_Colorize referenced in function _R_InitColormaps" and then one final error that reads "8 unresolved externals"

Since a similar error was already described in the thread, I tried adding "deh_bexincl" "deh_bexpars" "deh_bexptr" in the same manner (and from the same directory) as the instructions gave for "deh_bexstr." This resolved the first three errors, but I don't know what file I need to add for the _crstr and _cr errors. (Or if I added the right files for the other three errors, to be honest.)

[LexiMax]

Marscaleb said:

It would be a bit more work, but it would be more sensible to only unblock them for a moment; like as soon as they start moving they go solid.

Why block again? It seems like unblockplayers might be a desirable setting even in 4 player games.

[fabian]

Marscaleb said:

Since a similar error was already described in the thread, I tried adding "deh_bexincl" "deh_bexpars" "deh_bexptr" in the same manner (and from the same directory) as the instructions gave for "deh_bexstr." This resolved the first three errors, but I don't know what file I need to add for the _crstr and _cr errors. (Or if I added the right files for the other three errors, to be honest.)

The deh_section_bex* and bex_* symbols belong to the BEX parser that I added, so you added the right files to the project.

The cr and crstr symbols belong to the color translation tables, please add the "v_trans.c" file from the "src" directory.

Phew, this shows that either noone ever tried to build Crispy Doom with VS or that noone bothers to contribute their project files. :/

[chungy]

Probably the former; since VS has never been an officially-supported way to build CD, it's not surprising that they go out of date on a semi-frequent basis.

AlexMax made some CMake files for Chocolate Doom; I didn't look to see if he generates a list of source files dynamically or not. I doubt fraggle would use it as the official build system either, but it could make things nicer since it can generate MSVC and CodeBlocks (among others) project files at the preparation stage (and obsolete the need for MSVC/CodeBlocks projects in the repo).

[Marscaleb]

Okay, I got the new version to compile, and I even got the crosshair to not appear in multiplayer.
(BTW the new "uncapped framerate" option is awesome!)

But there are some minor issues still. The executable that was built was named "chocolate-doom-dbg.exe," and while that file is easily renamed "crispy-doom.exe" it still tries to use "chocolate-doom.cfg" as its config file.

Also, it is now popping up with this console log that I don't recall seeing before.

EDIT: Disregard the window-pushing thing I mentioned; it was because the resolution was set wrong, which I didn't quite realize since the setup program isn't editing the correct config file at the moment.

[fabian]

Marscaleb said:

Okay, I got the new version to compile, and I even got the crosshair to not appear in multiplayer.

Yay!

(BTW the new "uncapped framerate" option is awesome!)

You'll have to thank AlexMax for that.

But there are some minor issues still. The executable that was built was named "chocolate-doom-dbg.exe," and while that file is easily renamed "crispy-doom.exe" it still tries to use "chocolate-doom.cfg" as its config file.

Ah, that's probably because the PACKAGE_NAME variable is still set to Chocolate.

Also, it is now popping up with this console log that I don't recall seeing before, and the fullscreen mode keeps pushing all the windows on my monitors over to the side.

These are most probably SDL issues that are not specific to the port.

[Linguica]

You should probably change the Configuration Manage to "release". Then under Configuration Properties > General, you can change the "Target Name" from $(ProjectName) to whatever.

[LexiMax]

chungy said:

AlexMax made some CMake files for Chocolate Doom; I didn't look to see if he generates a list of source files dynamically or not.

It does not (doing such a thing is considered an anti-pattern), but the files are laid out very similarly to the Makefile.am files, so if you're missing a file or two, you're just a few copy-pastes from it being correct.

[Jon]

Since neither doom retro nor chocolate-doom have cut a release since they merged my pitch-shifting code, your port is the first release to have it in :)

[fabian]

Jon said:

Since neither doom retro nor chocolate-doom have cut a release since they merged my pitch-shifting code, your port is the first release to have it in :)

\o/ Yay, though I usually don't mention features in the release notes that I merely took over from Choco.

[Jon]

fabian said:

\o/ Yay, though I usually don't mention features in the release notes that I merely took over from Choco.

Sure I figured that - besides the other stuff is much cooler (the framerate work etc)

presently crispy is my go-to port btw :)

[fabian]

Jon said:

presently crispy is my go-to port btw :)

I feel flattered, thanks! :)

[vadrig4r]

God bless Fabian, great work from you and of course the Chocolate Doom guys. Love the uncapped framerate feature especially.

[Linguica]

How the heck am I supposed to have my own fork of chocolate-doom AND crispy-doom when git refuses to allow you to fork a fork when you've already forked the original?

[chungy]

That's GitHub, heh.

Just maintain them in separate branches and have both remotes in your repo.

[fraggle]

Linguica said:

How the heck am I supposed to have my own fork of chocolate-doom AND crispy-doom when git refuses to allow you to fork a fork when you've already forked the original?

Not sure what you're trying to do. You have forks of both ports?

You might want to try using 'git cherry-pick'?

[chungy]

I think what he wants is to do a "fork" of crispy-doom (from GitHub's perspective), then just add chocolate-doom as a remote to his local repo. He should be able to send GH pull requests to either project from that point.

[Linguica]

fraggle said:

Not sure what you're trying to do. You have forks of both ports?

You might want to try using 'git cherry-pick'?

My point is that if I try to fork Crispy Doom so I can make changes to it entirely separately from Chocolate Doom, Github just goes "lol you already have a fork of Chocolate Doom silly!" and that's it.

[Lila Feuer]

I am using 1920x1080 with aspect ratio set to true and getting the game screen in a black box. What gives?

[Jon]

Linguica said:

My point is that if I try to fork Crispy Doom so I can make changes to it entirely separately from Chocolate Doom, Github just goes "lol you already have a fork of Chocolate Doom silly!" and that's it.

With git the command line, you can add crispy-doom as a "remote" to your chocolate doom fork (on your pc) and fetch it, check out branches and push those branches to your fork on GitHub. something like:

git remote add crispy https://github.com/fabiangreffrath/crispy-doom
git fetch crispy
git checkout -b my-crispy-master crispy/master

I don't know whether the GitHub tool offers this but hopefully it does somewhere. It's not that uncommon a use case.

When you come to raise a pull request on the website, after pushing a modified branch to your fork, you'll have to make sure it's going towards the crispy repository and not the original chocolate one. I *think* the UI might offer to let you type in the repo/fork/branch you are submitting to; or it might default to where you first forked from. In that case, hopefully if browsing the crispy fork pages a pull request option appears it will be against the right fork.

This all means you'll have just one git repo on your pic for the two projects, and only one checked out at a time.

[Jon]

Cyanosis said:

I am using 1920x1080 with aspect ratio set to true and getting the game screen in a black box. What gives?

1920x1080 is not a 4:3 size so the game draws the largest 4:3 it can and fills the rest with black.

[Gez]

Forking from a program and then from a fork of that program isn't possible with GitHub's web interface; but it is possible I believe with the command line tools.
https://adrianshort.org/create-multiple-forks-of-a-github-repo/

Though I heard the web UI will still not see it as a fork, so you'll miss the ability to do stuff like pull requests and so on through it.