Chocolate Doom

12 hours ago, PKr said:

@Faustrecht why don't you simply use Crispy Doom, set low resolution, turn off widescreen, etc, and leave framerate interpolation on? That would basically be a Chocolate Doom with uncapped fps, just what you want... Or is there something that Chocolate Doom does that Crispy doesn't?

I didnt know about this. Thanks alot.

I will give it a shot.

On 11/17/2022 at 4:07 AM, PKr said:

@Faustrecht why don't you simply use Crispy Doom, set low resolution, turn off widescreen, etc, and leave framerate interpolation on? That would basically be a Chocolate Doom with uncapped fps, just what you want... Or is there something that Chocolate Doom does that Crispy doesn't?

Last time I checked Crispy didn't render everything completely like vanilla / chocolate. It's mostly minor stuff though. Nothing that couldn't be fixed.

Crispy has fixed flat distortion at the screen boundaries, for example, because it became more apparent with the increased resolution. 

Playing 10sector part 2  , which is (generally) boom mapset, with -complevel 2 (for some reason) in prboom+ on MAP03 I stumble upon engine showing as translucent tricky mid-texture without special boom actions. It is COMPBLUE "cage" for blue key. However, check it in vanilla & chocolate 2.3.0 (latest working version for me) reveal differency: choco just crashed while doom2.exe display that COMPBLUE as heavy tutti-frutti painting.

Funny thing, guess who is map author?

Nice find. That's Medusa.

Choco crashes because its default heap size (16 MB) is twice that of vanilla. You can avoid crashes if you run it with "-mb 8". What the blue key enclosure will look like will depend on the heap's contents; the look above can be reproduced by accessing the menu. Close enough to what vanilla shows, which is also highly variable.

Timeline: Silent crashes on levels with Medusa were reported in 2014.

I've read there's an option to get scanlines, however, I tried it on Chocolate 3.0.0 (MacOs) and it does not work. 

I don't think that's a thing. Where did you read this?

@Edward850 Here

Looks like the feature disappeared in the move to SDL2-backed hardware accelerated scaling.

People have been mentioning in the Megawad Club thread for the Number One Kill trilogy that TNG's 13th map seems to crash suitably accurate ports. When I did some testing of my own, I found out that this was even true for Chocolate Doom, but not pure vanilla (or Doom95, for what that's worth). Is there anything that can be done about this?

5 hours ago, SiFi270 said:

People have been mentioning in the Megawad Club thread for the Number One Kill trilogy that TNG's 13th map seems to crash suitably accurate ports. When I did some testing of my own, I found out that this was even true for Chocolate Doom, but not pure vanilla (or Doom95, for what that's worth). Is there anything that can be done about this?

In some cases content can cause the map to do funny memory accesses. This might be harmless in those two first ones, but trigger a 'crash' in chocolate doom. I haven't looked into the problem, but it would be quite a nice find if chocolate didn't emulate something sensible in the correct manner.

1KILLTNG MAP13 has two zero-length linedefs, 1891 and 2234, among other errors (open sectors, vertices not splitting linedefs they are on, etc.). But that's not what crashes Choco, though it may have thrown off the unknown nodebuilder used on that map, creating two segs with invalid references elsewhere:
 

P_LoadSegs: linedef 2223 for seg 3761 references a non-existent sidedef -1

P_LoadSegs: linedef 2220 for seg 3765 references a non-existent sidedef -1

Fixing those two segs in SLADE allows Choco to load the map. Vanilla doesn't seem to mind either way.

19 hours ago, SiFi270 said:

Is there anything that can be done about this?

Good question, that. The standard procedure is to open an issue on the Github project's tracker. When it will be acted upon and even if it will be acted upon at all is anybody's guess.

The Medusa issue referenced above, for example, predates the Github repo itself. It illustrates perfectly the old trope "After everything has been said and done, a lot more has been said than done". Quasar's experimental Medusa-emulation branch has been allowed to rot into obsolescence and the same fate apparently awaits the Doom v1.6 emulation and the Doom v0.99 demo support PRs. The latter also includes v1.1 support and various fixes affecting the existing -gameversion 1.2. It has been awaiting a review for three years now. This call for a new release has been gathering dust for two years. The list goes on and on.

How many more years have to pass before we muster enough courage to ask ourselves some hard questions, like "Has Chocolate Doom been abandoned by its creator?", "Does this project in its current state have any future?" and "What are we going to do about it?".

Dang the logo looks sweet

Love Chocolate Doom, it's litterally what I named my account after.

Are there any plans for a new stable release? There are a lot of commits since 3.0.1.

There is a NEWS.md update about a 3.1.0 (which I guess was planned for 2019 but didn't eventuate). With 1500+ commits since 3.0.1 it's a bit hard to understand what's new/changed - is there an updated NEWS.md available?

I'm not sure why it even needs so many commits and updates, it pretty much finished what it set out to do. If it has minimal, clean code and is highly portable it doesn't need any additions. Any more updates and you might as well call it "Chocolate with Sprinkles Doom".

Not going to create an issue for it, but it'd be pretty neat if Crispy Doom's soundfont selection were ported over.

12 hours ago, CaptainMuskrat said:

I'm not sure why it even needs so many commits and updates, it pretty much finished what it set out to do. If it has minimal, clean code and is highly portable it doesn't need any additions. Any more updates and you might as well call it "Chocolate with Sprinkles Doom".

Libraries change, operating systems change, new bugs that we didn't know of are found, emulation isn't 100% correct, there's always minor things that can be improved. I'd say making it more portable is probably the place where there is the biggest opportunity for patches. There's also emulation of obscure versions of the game, their bugs and quirks.

Question: Chocolate Doom can run https://www.chocolate-doom.org/wiki/index.php/Perdition's_Gate, but what command-line switch(es) is / are needed for Hell 2 Pay?

https://doomwiki.org/wiki/Hell_To_Pay

Edit 8/8/2023: For the full version of Hell 2 Pay, you have to use the following command line arguments:

-iwad DOOM2.WAD -merge HELL2PAY.WAD HTPDMO19.WAD

looks like chocolate-doom.org needs some maintenance

https://www.chocolate-doom.org/ fails to load the wiki, due to unresolved php dependencies

http://latest.chocolate-doom.org/ displays the python source, instead of the page usually served by it 

Thanks for reporting. The server that the site runs on is currently in the process of being upgraded and it seems we're having a bit of a bumpy ride.