Chocolate Doom

[Faustrecht]

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.

[zokum]

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.

Edited November 23, 2022 by zokum
Added line about it being fixable.

[fabian]

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

[Hitherto]

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?

Edited January 22, 2023 by Hitherto

[Never_Again]

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.

[s4f3s3x]

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. 

[Edward850]

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

[s4f3s3x]

@Edward850 Here

[chungy]

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

[SiFi270]

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?

[zokum]

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.

[Never_Again]

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?".

 

[Lonespacemarine]

Dang the logo looks sweet

[Chocolate_Doomer]

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

[orffen]

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?

[CaptainMuskrat]

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

[houston]

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

[zokum]

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.

[Master O]

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

 

Edited August 14, 2023 by Master O

[liPillON]

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 

Edited October 5, 2023 by liPillON

[fraggle]

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.

[CacoKnight]

Some screenshots for the website?

 

ReactOS:

 

[houston]

9 hours ago, CacoKnight said:

Some screenshots for the website?

Pretty neat to see ReactOS in action! Tasteful touch on using the shareware and making the screenshot unambiguously "legal" ;) versus those Wikipedia articles which have to compress and rescale any game screenshot in case they accidentally include some weird copyrighted 2D asset within

 

It's a damn good and fascinating project, but for the life of me I still can't understand why they'd choose to reimplement Windows NT, instead of Windows when it was still good

[zokum]

53 minutes ago, houston said:

Pretty neat to see ReactOS in action! Tasteful touch on using the shareware and making the screenshot unambiguously "legal" ;) versus those Wikipedia articles which have to compress and rescale any game screenshot in case they accidentally include some weird copyrighted 2D asset within

 

It's a damn good and fascinating project, but for the life of me I still can't understand why they'd choose to reimplement Windows NT, instead of Windows when it was still good

Windows NT line when the hardware caught up with the code was the first decent iteration of Windows. Windows 2000 was the first stable mainstream usable Windows OS. Anything before that was either niche business stuff or toy GUIs. No one who had to use Windows 95/98 for any length of time beyond basic tasks liked it. It crashed and behaved oddly all the time. The core design was inherently unstable. I've used: Windows 3.0, 3.11 (fwg), 95, 98, ME, NT 3.5, 2000, XP, 7, 8, 10. I managed to barely avoid Vista. I've also used a fair amount of DOS versions and editions. DOS had its charm, but it really is a horrible OS.

[Kroc]

I had Windows 98 crash on me once (back in the day) because I pressed the left SHIFT key. Many techies dual booted Win9x and 2K at the time for good reasons.

[CacoKnight]

5 hours ago, houston said:

Pretty neat to see ReactOS in action! Tasteful touch on using the shareware and making the screenshot unambiguously "legal" ;)

Yeah ReactOS is pretty cool, I still have no idea why it exists but even if it's just for the fact that they can well, that's good enough! Also funny that's exactly the reason I used DOOM1.WAD :)

[krush]

Hey,

 

i am struggling with chocolate doom with some wads...

I want to load these mods together with chocolate doom:

 

Sound_Bulb_Legacy.wad - version 2.0 (source: moddb / Sergeant_Mark_IV)

D2SPFX20.WAD /.DEH - version 2.0 (source: this forum / Revenant100)

vsmooth.wad / .deh - version scuba steve (source: this forum / BIG Vanilla Doom Wad Pack! REV. 16 / Doomkid)

SCYTHE.WAD (source: doomworld/idarchive / Erik Alm)

 

how can i load all together and make them work together?

 

i am running chocolate-doom from linux (debian)

[maxmanium]

1 minute ago, krush said:

Hey,

 

i am struggling with chocolate doom with some wads...

I want to load these mods together with chocolate doom:

 

Sound_Bulb_Legacy.wad - version 2.0 (source: moddb / Sergeant_Mark_IV)

D2SPFX20.WAD /.DEH - version 2.0 (source: this forum / Revenant100)

vsmooth.wad / .deh - version scuba steve (source: this forum / BIG Vanilla Doom Wad Pack! REV. 16 / Doomkid)

SCYTHE.WAD (source: doomworld/idarchive / Erik Alm)

 

how can i load all together and make them work together?

 

i am running chocolate-doom from linux (debian)

 

Did you use -merge instead of -file?

[krush]

8 minutes ago, maxmanium said:

 

Did you use -merge instead of -file?

 

Quote

chocolate-doom -iwad /home/silvius/Data/doom/iwad/DOOM2.WAD -merge /home/silvius/Data/doom/mods/enhancements/sprfix20/D2SPFX20.WAD /home/silvius/Data/doom/mods/megawads/scythe/SCYTHE.WAD /home/silvius/Data/doom/mods/enhancements/vsmooth/vsmooth.wad /home/silvius/Data/doom/mods/enhancements/Doom_Sound_Bulb/Doom_Sound_Bulb_Legacy.wad
                         Chocolate Doom 3.0.0
Z_Init: Init zone memory allocation daemon.
zone memory: 0x7fe03c3ff010, 2000000 allocated for zone
Using /home/silvius/.local/share/chocolate-doom/ for configuration and saves
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in /home/silvius/.local/share/chocolate-doom/default.cfg
W_Init: Init WADfiles.
 adding /home/silvius/Data/doom/iwad/DOOM2.WAD
 merging /home/silvius/Data/doom/mods/enhancements/sprfix20/D2SPFX20.WAD
 merging /home/silvius/Data/doom/mods/megawads/scythe/SCYTHE.WAD
 merging /home/silvius/Data/doom/mods/enhancements/vsmooth/vsmooth.wad
 merging /home/silvius/Data/doom/mods/enhancements/Doom_Sound_Bulb/Doom_Sound_Bulb_Legacy.wad

 

everything seems to work except of Smooth Weapons

[maxmanium]

2 minutes ago, krush said:

 

 

everything seems to work except of Smooth Weapons

 

VSmooth should come with a .deh file. Load it with -deh.