Chocolate Doom

[drfrag]

 Thanks, that's what i'll do try to convince someone to run the server. I want to run a RUDE server with backpacks on unholy massacre after i release another test build. Of course you're invited but i see you're very busy. I think fake splitscreen (you only need to allow joystick input in the background) could be combined with real netplay as one player could join the localhost and others the server through the network, that if i'm not wrong.

 Are you aware that joysticks don't work with SDL 2.0.10? Or so it seems, i compile with 2.0.8 now.

 

 One more thing i'd like to know your opinion on adding 8 player support to Doom. Since Hexen has that it should be doable. But does it make sense? I wonder what i'd need besides new player colors and some easy way to avoid telefrags such as a delay else the killer would pick your backpack i think. Now that i think of it i could use DM starts for coop. No need for new starts. I could "suck" the code from Hexen or perhaps Doom Legacy with a brute force analysis. May be i'll create an issue in my repo later.

[fraggle]

Hi Chocolate fans - I previously mentioned the vanilla-net branch in this thread but I forgot to make a Windows build available for people to try it out. Anyway, there's a build here for anyone who's curious and wants to try this out.

 

How to use:

 

• Connect to a DOSbox IPX server: -dbconnect ip:port
• Connect to a DOSbox virtual modem: -dbdial ip:port
• Listen for an incoming DOSbox virtual modem "call": -dbanswer -port portnum

[DagothKronk]

I'm at my absolute wit's end. I'm running chocolate doom on ubuntu 18.04, and no matter what I do, I can't seem to get choco to use built-in timidity (gus emulation included) whatsoever. The engine falls back on fluidsynth support despite setting up eawpat's timidity .cfg, pointing the chocolate-doom .cfg at the timidity .cfg or freepats .cfg in /etc/timidity, trying the gus patches available on idgames, you name it. It's possible I'm missing something super obvious but chocolate doom simply refuses to use built in timidity support for whatever reason. It's kind of a longshot seeing as how vague the issue is but I thought I'd shoot a message at thread just in case.

[plums]

@DagothKronk do you have SDL_SOUNDFONTS set? (if you don't know how to check: open a terminal and type echo $SDL_SOUNDFONTS .) It needs to not be set to not use fluidsynth.

[fraggle]

59 minutes ago, DagothKronk said:

I'm at my absolute wit's end. I'm running chocolate doom on ubuntu 18.04, and no matter what I do, I can't seem to get choco to use built-in timidity (gus emulation included) whatsoever. The engine falls back on fluidsynth support

Interesting, thanks for the feedback.

 

I assume you're starting Chocolate Doom from the terminal. Can you try this and see if it solves the problem?

export SDL_MIXER_DISABLE_FLUIDSYNTH=1
chocolate-doom

If it does then I can make a code change that will fix it for everyone (ie. Fluidsynth should be disabled when the user has configured Timidity or is using GUS emulation).

[DagothKronk]

5 minutes ago, fraggle said:

 

export SDL_MIXER_DISABLE_FLUIDSYNTH=1
chocolate-doom

 

This worked, bless up and much thanks

[DagothKronk]

2 hours ago, plums said:

@DagothKronk do you have SDL_SOUNDFONTS set? (if you don't know how to check: open a terminal and type echo $SDL_SOUNDFONTS .) It needs to not be set to not use fluidsynth.

I didn't see this reply. I'll look into this as well, thank you.

 

EDIT:

To answer your question @plums SDL_SOUNDFONTS returns nothing when I echo it. However chocolate doom in terminal still looks for fluidr3mono_gm .sf3 for some reason unless fluidsynth is explicitly disabled. weird stuff.

Edited March 31, 2020 by DagothKronk

[plums]

@DagothKronk thanks, that's good to know for people having issues in the future. Good to see that you got it sorted out.

[crmb]

hello.

I tried Chocolate Doom/Crispy Doom for the first time and noticed the mouseaccel. I found there is an option in the setup.
I can't remember of any mouseaccel on DOS, and just tried in dosbox.
Why it is enabled (2.0) by default ?

 

(At first i thought it was taking my Windows mouseaccel)

[maxmanium]

I found an engine bug, but I'm not sure if it's the problem with the original or just Chocolate. Part of my DEHACKED patch sets the god mode health to 200, but after deactivating it, the player dies after losing 100% health as if that were what remained. It doesn't seem to happen in doom2.exe.

[Inspektor_Backdoor]

So guys i got a question. Im new here so sry if im on the wrong post or something. I installed Chocolate Doom on my PS Vita with henkaku installed. Now everytime i want to start it it gives me an error "Saved Core File Succeeded" (C2-12828-1). Can anyone provide assistance for this problem? Everything else like other homebrews and Backuped games works just fine! Cant really understand whats going on there.

 

[fraggle]

2 hours ago, Inspektor_Backdoor said:

So guys i got a question. Im new here so sry if im on the wrong post or something. I installed Chocolate Doom on my PS Vita with henkaku installed. Now everytime i want to start it it gives me an error "Saved Core File Succeeded" (C2-12828-1). Can anyone provide assistance for this problem? Everything else like other homebrews and Backuped games works just fine! Cant really understand whats going on there.

 

Despite the name, "Chocolate Doom" on the PS Vita is not actually anything to do with me/us. I suggest you find the contact details for the author of that port.

[SiFi270]

Why doesn't Chocolate Strife have a "toggle autorun" button? If you have "always run" enabled in the setup, you won't be able to look up or down properly, and I'm pretty sure separating the inputs for run and center view would affect demo compatibility. So I've had my finger on the shift key like a chump, and now it's kind of achey. :(

 

Also, health should stop at 199 in Doom when -gameversion is set to 1.2. As far as I know, RUDE is the only port in this family that does this at the moment.

[Edward850]

4 minutes ago, SiFi270 said:

Why doesn't Chocolate Strife have a "toggle autorun" button?

Because Strife never had this kind of function. Autorun in Doom, Heretic, Hexen and Strife only exists as a glitch caused by how joystick buttons can be defined.

Also your post might imply you are looking for demo support? In case you are, Strife actually is the only game that doesn't have that for single player, due to how the dialogues work.

[SiFi270]

I know about the glitch, and I'm pretty sure from experience that it also works in Vanilla Strife. While none of the vanilla engines have buttons for selecting the next or previous weapon, chocolate family ports have "pretend I just pressed the corresponding key for the next or previous weapon" button, so I don't see why a "pretend I'm holding run down until I press this again" button would be any more complicated.

[chungy]

That's... actually probably not a bad idea. The "run" command only being activated when a direction key is pressed. Next/prev weapon is mostly in the engine for limited input controls (gamepads, especially), though we don't disable it for keyboard/mouse play. I imagine some people use it as a quality-of-life thing with a mouse wheel anyway.

 

It would stray a little from vanilla without breaking demo compatibility, but at least it would allow looking up and down. The reason it centers is because Strife always centers the view on the run command. The joystick index-overflow that allows "autorun" in vanilla makes the game believe it's pressed all the time.

 

It'll be worthwhile posting this as a feature request on the Chocolate Doom issue tracker -- at least we can get some discussion about it going.

[drfrag]

Playing RUDE coop online the other day (besides the serious issues in RUDE itself) we noticed that you can't quit chatting pressing the ESC key (ESC doesn't stop chat input) instead pressing ESC brings up the menu. I think this is a bug, is it? It's very inconvenient. It happens with latin keyboards but also selecting the US keyboard layout in win10. According to this code snippet in hu_stuff.c chat input should stop.

        else if (c == KEY_ESCAPE)
        {
                StopChatInput();
            }

https://github.com/chocolate-doom/chocolate-doom/issues/1284

[fraggle]

That is a bug, yes. Can you file a report on Github?

[drfrag]

I already did yesterday and linked to it in the previous post. I've even pushed a fix but i'm not sure about any possible side effects.

https://github.com/chocolate-doom/chocolate-doom/issues/1284

https://github.com/drfrag666/RUDE/commit/db87645b1047fee4307e92a6184300c88b2dbad3

[thisneedsmorsalt]

Hi, I'm absolutely new here, but I need some help with chocolate doom for the PS Vita (which btw I deeply, deeply love). So basically when I load D4V.wad (Doom 4 Vanilla) in Custom file 1 and D4V.deh in DEH File 1, the game only sometimes loads the mod (when it does, it's beautiful).

SO, my question is: how do I make it load the wad normally without having any issues?

For further understanding:

- What I mean is, when I try to play with the mod on I only get to play Doom2 absolutely vainilla, yet it sometimes works and I'm able to play D4V, so ChocDoom is actually working, but not quite

- I usually load it using Doom2 as my main wad (I've also had luck loading the wad with UltimateDoom.wad, but only once)

- I only have D4V.wad and D4V.deh on the ux0:/data/chocolate/pwads/doom directory

- [Load DEHACKED lumps] is always off, but I don't know if it should be on

- I've also been able to play the wad without loading the D4V.deh file

 

Further questions I have:

- Should I load the wad as merge file instead of Custom File 1?

- I want to play custom maps AND the D4V mod, how can I achieve that? D4V already comes with such wads as Scythe but I don't know how to load both of them and make them work (heck, I can't even make scythe work by itself)

[chungy]

You need to contact the developer of the PS Vita port. This thread is only really relevant for the official version of Chocolate Doom, which is on PC platforms (Windows, Linux, Mac)

[drfrag]

Someone has reported a GZDoom crash with ganymede.wad due to bad nodes, while rebuilding nodes would fix it i wonder why it doesn't crash with Crispy. It crashes with Choco and it's a hard crash. https://doomworld.com/idgames/levels/doom/g-i/ganymede

GZDoom builder says:

Quote

Linedef 74 references invalid sidedef 65534. Sidedef has been removed.
Linedef 72 references invalid sidedef 65534. Sidedef has been removed.

And the LZDoom console:

e1m1 - Hangar

Sidedef 92 has a bad sector
Unknown middle texture 'ªºß=I5â=' on second side of linedef 72
Unknown top texture 'ž�¿=֠Á=' on second side of linedef 72
Unknown bottom texture '²CÑ=I•Ó=' on second side of linedef 72
Sidedef 95 has a bad sector
Unknown middle texture 'ªºß=I5â=' on second side of linedef 74
Unknown top texture 'ž�¿=֠Á=' on second side of linedef 74
Unknown bottom texture '²CÑ=I•Ó=' on second side of linedef 74

It doesn't crash in RUDE either but i don't get any warning in the console.

[drfrag]

The problem causing the crash is that the sector is null.

      if ((unsigned)LittleShort(msd->sector)>=Level->sectors.Size())
      {
         Printf (PRINT_HIGH, "Sidedef %d has a bad sector\n", i);
         sd->sector = sec = nullptr;
      }

PRBoom+ and others (but not Crispy) use sector 0 and that mostly fixes the crash but still crashes at times and crashes earlier.

[drfrag]

Still crashes from time to time. The texture names change and are random junk.

e1m1 - Hangar

Linedef 72 has a bad sidedef
Linedef 74 has a bad sidedef
Sidedef 92 has a bad sector
Unknown middle texture '���ÿ�#+ÿ' on second side of linedef 72
Unknown top texture '���ÿOc{ÿ' on second side of linedef 72
Unknown bottom texture '‡Ÿ·ÿ�7/ÿ' on second side of linedef 72
Sidedef 95 has a bad sector
Unknown middle texture '���ÿ�#+ÿ' on second side of linedef 74
Unknown top texture '���ÿOc{ÿ' on second side of linedef 74
Unknown bottom texture '‡Ÿ·ÿ�7/ÿ' on second side of linedef 74

With this commit: https://github.com/drfrag666/gzdoom/commit/642b9fe053b47a0388823f011d4d23265a91ccc4

I'm posting this here becouse Choco also crashes.

@fabian I still don't know why Crispy doesn't crash, it doesn't contain that code from PRBoom.

[maxmanium]

Repost of the following bug:

 

On 4/14/2020 at 9:02 PM, maxmanium said:

I found an engine bug, but I'm not sure if it's the problem with the original or just Chocolate. Part of my DEHACKED patch sets the god mode health to 200, but after deactivating it, the player dies after losing 100% health as if that were what remained. It doesn't seem to happen in doom2.exe.

 

After checking it's definitely a bug with Choco -- doesn't happen in DOS.

[drfrag]

It could be a random crash in DOS. It's fixed in LZDoom i think but still i don't know how it's done in Crispy.

https://github.com/drfrag666/gzdoom/commit/ae9cf88da09aab04a9dbfa5ac55670579f51fba4

[vanilla_d00m]

Is there a way to get doomp.exe (doom plus) to work with this?? I like the way chocolate runs when playing the levels and moving around. Original DOS behavior?

 

Even with ZDOOM on 35fps it doesn't run like chocolate doom (im using 2.3.0 and this port rules) 

[chungy]

See Crispy Doom

[vanilla_d00m]

Yes... I know it was made to be 100% vanilla, I just wan't to test things out with it.  I seen AXDOOMER's chocolate doom plus on github but when i got it, I had no idea how to use it.

 

I have crispy doom 5.0 and it works great, but doesn't chocolate doom have the nuke opl??

 

i tried chocolate-doom.exe -file doomp.exe iwad.doom.wad -file e1m8b.wad but the doom plus won't work with it. 

[maxmanium]

2 hours ago, vanilla_d00m said:

Yes... I know it was made to be 100% vanilla, I just wan't to test things out with it.  I seen AXDOOMER's chocolate doom plus on github but when i got it, I had no idea how to use it.

 

I have crispy doom 5.0 and it works great, but doesn't chocolate doom have the nuke opl??

 

i tried chocolate-doom.exe -file doomp.exe iwad.doom.wad -file e1m8b.wad but the doom plus won't work with it. 

 

Homie... you can't -file a DOS .exe. That's an entirely separate program.