Chocolate Doom

[mora.chan45]

Hi there guys, I been using music packs in Chocolate and GUS emulation in Crispy for a while, but I switch back to the native MIDI because of the loops on tracks and for some reason the new internal MIDI player (midiproc) didn't wanted to work with the BASSMIDI Drive and even crashed one time, but with VirtualMIDISynth midiproc didn't give me trouble, VirtualMIDISynth had a problem however, it seems that reproduces MIDI by itself for some reason and doesn't let me change volume (always at max of the mixer of VirtualMIDISynth) or pause the playback when I pause the game, and others apps works very well with both MIDI drivers. After thinking of how MIDI worked in DOS versions I edited the default.cfg like the original and changing this:
 

Quote

snd_sbport                    0
snd_sbirq                     0
snd_sbdma                     0
snd_mport                     0

To this:

Quote

snd_sbport                    544
snd_sbirq                     7
snd_sbdma                     1
snd_mport                     816

And somehow midiproc worked again with BASSMIDI Drive, my question is why it fail in first place? Chocolate Doom didn't give me this problem before the 3.0.0 version.

[twipley]

On 10/21/2018 at 7:55 PM, fraggle said:

This weekend I implemented some improvements to the digital music pack support.

 

Great!

 

I have one question though: can absolute paths now be specified in the config files?

[fraggle]

 

[zokum]

IPX support is a very cool addition. A doom port with some sort of API could finally allow for some decent client side bots to play against with the original executable on relevant hardware :) Something I have always wanted since i tried similar things with Quake in the mid 90s.

Client bots "cheat" a lot less, they don't do voodoo stuff like picking up weapons from afar, shoot too fast etc like the Reaper bot in Quake did.

I think I have a 2xP150 machine with 128 meg somewhere. That would make for a great retro machine. Very unusual config, but it should be able to run a lot of games, although some games would probably choke on the amount of memory.

[mun]

17 hours ago, fraggle said:

 

So that IPX idea finally did materialize...

I've actually hoped that this become a reality. Keep up the great work!

[Danfun64]

IPX support? Yay! (See's it's ipxnet instead of true IPX) Boo! Native IPX (can be done on NE2000 compatible Dosbox builds) or bust!

[Edward850]

59 minutes ago, Danfun64 said:

IPX support? Yay! (See's it's ipxnet instead of true IPX) Boo! Native IPX (can be done on NE2000 compatible Dosbox builds) or bust!

While not impossible, it's considerably complicated to do without native IPX driver support, which 99.999r% of systems do not have nowadays. You would in effect have to implement DOSBOX's NE2000 emulation into Chocolate Doom as some sort of weird hardware abstraction. Or work with RAW packets directly. Neither of which are great options. It'd be instead actually easier to write a DOSBOX IPX tunnel client for the client system (say for Win98).

[fraggle]

Yeah, I want to put together a bridge server that will talk the DOSBox IPX protocol and route the packets onto a physical network. Native IPX support is likely to be messy and require native APIs to pull off so I'd like to keep that complexity out of choco.

 

Besides, having a DOSBox IPX -> native server is probably far more interesting and useful for any number of reasons. I'm a bit surprised nobody's done it already. If they have I'd love it if someone could let me know.

[kb1]

22 hours ago, fraggle said:

Yeah, I want to put together a bridge server that will talk the DOSBox IPX protocol and route the packets onto a physical network. Native IPX support is likely to be messy and require native APIs to pull off so I'd like to keep that complexity out of choco.

 

Besides, having a DOSBox IPX -> native server is probably far more interesting and useful for any number of reasons. I'm a bit surprised nobody's done it already. If they have I'd love it if someone could let me know.

Forgive my ignorance - and instead let ask a simple question:

Does this allow Doom.exe, running in DOSBox, to talk network to Chocolate? If not, let me instead ask a clueless question: What *does* this allow, in laymen's terms?

[fraggle]

That's correct. DOSbox has built-in networking that lets you tunnel an IPX connection inside IP packets. So you can connect DOSboxes together in a network and play old IPX games - as far as they know, they're playing over an IPX LAN.

 

I'm adding support to Chocolate Doom for the same IPX protocol that DOSBox uses. So choco can connect to DOSBox, and DOSBox thinks it's another DOSBox, and ipxsetup.exe running inside DOSbox thinks it's talking to another ipxsetup, but it's actually choco again, talking the same protocol.

[Master O]

2 minutes ago, fraggle said:

That's correct. DOSbox has built-in networking that lets you tunnel an IPX connection inside IP packets. So you can connect DOSboxes together in a network and play old IPX games - as far as they know, they're playing over an IPX LAN.

 

I'm adding support to Chocolate Doom for the same IPX protocol that DOSBox uses. So choco can connect to DOSBox, and DOSBox thinks it's another DOSBox, and ipxsetup.exe running inside DOSbox thinks it's talking to another ipxsetup, but it's actually choco again, talking the same protocol.

 

Speaking of networking protocols, what about ipv6 support?

 

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

[kb1]

3 hours ago, fraggle said:

That's correct. DOSbox has built-in networking that lets you tunnel an IPX connection inside IP packets. So you can connect DOSboxes together in a network and play old IPX games - as far as they know, they're playing over an IPX LAN.

 

I'm adding support to Chocolate Doom for the same IPX protocol that DOSBox uses. So choco can connect to DOSBox, and DOSBox thinks it's another DOSBox, and ipxsetup.exe running inside DOSbox thinks it's talking to another ipxsetup, but it's actually choco again, talking the same protocol.

Oooh - that's very cool, man! So, the big question: Think it'll sync?  :)

 

Another question/idea: Do you know of, or have you built/used a DOS (or even Win98) driver, maybe named something like "IPX_2_IP.exe" that would let the real thing talk to Chocolate, or another DOS/Win8 box? Stated differently, do you have any experience getting 2 original Doom.exe boxes talking via IPX tunneled over IP?

 

I ask, because, obviously, that's a logical next step. With such a driver, and your new code, DOSBox could be removed from the equation. Your new code could be used to make such a driver.

 

Very cool stuff, indeed! I might want to snag some of that code one day :)

[Edward850]

19 minutes ago, kb1 said:

Oooh - that's very cool, man! So, the big question: Think it'll sync?  :)

Of course it will. Conceptually, if demos stay in sync, net games can as well. You logically can't have one without the other. 

 

For this same reason, you could port the IPX tunnel client to Prboom+ and Eternity as well and they'd work just as well (something I'd be tempted to try myself if I can get enough free time).

Obviously excluding any memory specific problems, but even that's a problem vanilla doom could strike with itself. 

Edited November 27, 2018 by Edward850

[fraggle]

39 minutes ago, kb1 said:

Oooh - that's very cool, man! So, the big question: Think it'll sync?  :)

Should sync fine for the reasons Edward850 describes. Network sync is mostly equivalent to demo sync.

 

As far as hooking up a real DOS machine, the bridge server I previously described would be the approach I'd prefer. A simple setup might be that you hook up your DOS machine to the network, run the bridge server and tell choco to connect.

 

More complicated stuff like bridging two distant IPX networks is a bit more complex but you could easily expand the basic concept.

[Looper]

Hi, I asked these questions in the crispydoom thread, and got a bit redirected here so I will ask them again:

Is there a chance to support the numpad keys? I would like to have my weapon switch keys on them instead of relying on external programs to change the keys.

 

Is there a way to fix the quick start? Or is it SDL2 related issue thus 'unfixable'?

If I check a demo of Chocolate doom (or its fork), the quick start looks like this:

Meaning the first two frames do not have the strafe command. Since it is more crucial to have high acceleration at the very beginning of the level, this 'bad' quick start loses 1-2 frames most of time. It is obviously not a serious time loss, but it's a bit annoying as sometimes the quick start works 100% correct, and sometimes it loses even the MF50 command from the first two frames, meaning the doom guy runs in a bit unfamiliar way at the beginning of the level, thus one loses even more time or results in a complete loss of an attempt. In total, the time loss ranges between 0.00-0.11 seconds (0-4 frames).

[kb1]

19 hours ago, fraggle said:

Should sync fine for the reasons Edward850 describes. Network sync is mostly equivalent to demo sync.

I'm with you. I was kinda respectfully poking fun at you and a friendly joke. I'm sure if you convert your packets correctly, it'll work great. Yes, net play is basically a demo that gets it data from the network and player input, instead of a demo file.

 

19 hours ago, fraggle said:

As far as hooking up a real DOS machine, the bridge server I previously described would be the approach I'd prefer. A simple setup might be that you hook up your DOS machine to the network, run the bridge server and tell choco to connect.

 

More complicated stuff like bridging two distant IPX networks is a bit more complex but you could easily expand the basic concept.

I can't say it enough: This is a really cool project, and hooking up Chocolate to Doom2.exe is the ultimate test of everything you've accomplished with Chocolate. Go get 'em!

[kb1]

1 hour ago, Looper said:

Hi, I asked these questions in the crispydoom thread, and got a bit redirected here so I will ask them again:

Is there a chance to support the numpad keys? I would like to have my weapon switch keys on them instead of relying on external programs to change the keys.

 

Is there a way to fix the quick start? Or is it SDL2 related issue thus 'unfixable'?

If I check a demo of Chocolate doom (or its fork), the quick start looks like this:

Meaning the first two frames do not have the strafe command. Since it is more crucial to have high acceleration at the very beginning of the level, this 'bad' quick start loses 1-2 frames most of time. It is obviously not a serious time loss, but it's a bit annoying as sometimes the quick start works 100% correct, and sometimes it loses even the MF50 command from the first two frames, meaning the doom guy runs in a bit unfamiliar way at the beginning of the level, thus one loses even more time or results in a complete loss of an attempt. In total, the time loss ranges between 0.00-0.11 seconds (0-4 frames).

If I'm not mistaken, those frames occur during the screen wipe. The original vanilla screen wipe does not scale well at higher resolutions, and becomes very slow. Many source ports have made slight adjustments to the screen wipe to make it work faster at those higher resolutions. But doesn't Chocolate stick to 320x200 resolution internally, then scale up to the user's spec?

 

Anyway, the screen wipe is an area to consider, as well as the code that runs right before the screen wipe begins. (I had to make adjustments in my modified screen wipe in KBDoom to maintain sync in some demos, so I thought I would mention it.)

[Danfun64]

For a long time, I wished somebody would make an open source Dosbox IPXNET driver for Native MS-DOS, Win9x, and OS/2, similar to how Kali works.

[fraggle]

On 11/27/2018 at 7:56 PM, Looper said:

Is there a way to fix the quick start? Or is it SDL2 related issue thus 'unfixable'?

If I check a demo of Chocolate doom (or its fork), the quick start looks like this:

cndoom has some code that implements quickstart by adding a pause on startup, so probably choco should just import that code. I'd be in favour.

 

Re: numpad keys, when I originally started the project I set up the key mappings to be identical to vanilla - I think vanilla doesn't let you set bindings for the numpad, or they map the same as the pgup/pgdn etc. keys. Since then we've relaxed the attitude towards bindings - like how you can bind mouse and joystick buttons for all kinds of things vanilla doesn't allow - and I think we ought to just add support for the numpad keys as well. I'm not sure if there's an open bug for it already.

 

16 hours ago, Danfun64 said:

For a long time, I wished somebody would make an open source Dosbox IPXNET driver for Native MS-DOS, Win9x, and OS/2, similar to how Kali works.

You mean eg. a network driver that implements the Novell IPX API and tunnels the packets over IP? It's an interesting idea - the problem is that getting a functional IP stack under DOS is kind of a pain since it really wasn't that common in those days. That's why I prefer my idea of a network bridge - let the DOS machines talk IPX over what they think is a LAN, but route the packets off over a tunnel as appropriate. It could be something as simple as configuring a Raspberry Pi and plugging it into a network along with your retro machines.

[fraggle]

More silliness:

 

 

[xttl]

Is it possible at all to make Chocolate Doom output MIDI to an ALSA MIDI port on Linux somehow? Currently I can use this port to send MIDI messages to VSTi softsynths running under savihost in Wine (Yamaha S-YXG50 and Roland SC-VA) from DOSBox:

$ aplaymidi -l
 Port    Client name                      Port name
 14:0    Midi Through                     Midi Through Port-0

but I can't figure out a way to do this in the version of Chocolate Doom I just got from the git repo and compiled. From what I see I guess SDL2_mixer simply doesn't support ALSA MIDI at all? If so, that's really unfortunate because that would also prevent using old hardware Roland MIDI modules with Chocolate Doom on Linux. Especially since it's possible to make this work in Chocolate Doom on Windows, even the newest versions.

Edited December 2, 2018 by xttl

[Looper]

Thanks for the clear response.

 

12 hours ago, fraggle said:

cndoom has some code that implements quickstart by adding a pause on startup, so probably choco should just import that code. I'd be in favour.

 

CNdoom does not actually fix the quick start, it only makes it easier to perform by giving the player more time to press the keys. However, that is a big difference because it has the exact same problem as Chocolate doom: You get the slightly broken quick start with two frames missing the strafe command.

 

I have tested this under Chocolate Doom, Crispy Doom and CNDoom. All of them having 100% identical quick start behaviour, except for the CNDoom having more time to insert the commands/key pressings.

[fraggle]

On 12/1/2018 at 6:45 PM, xttl said:

From what I see I guess SDL2_mixer simply doesn't support ALSA MIDI at all? If so, that's really unfortunate because that would also prevent using old hardware Roland MIDI modules with Chocolate Doom on Linux. Especially since it's possible to make this work in Chocolate Doom on Windows, even the newest versions.

It's an SDL2_mixer missing feature and sadly yes, I think it's just never been implemented for Linux. I believe you can work around it by using the snd_musiccmd config option to run aplaymidi (a gross hack, I know).

[xttl]

8 hours ago, fraggle said:

I believe you can work around it by using the snd_musiccmd config option to run aplaymidi (a gross hack, I know).

 

Yes, that works (except that it breaks the ingame music volume control but I can live with this). Thanks for the tip.

 

edit: Seems to also sometimes leave stuck notes when changing songs. I worked around this by adding a short mid file containing a GM reset message to the aplaymidi command line. That causes a bit too much of a delay when looping songs, but I'll also work around this later by hacking the code a bit (I'll have to make it use the reset file only when actually changing songs, not when looping).

Edited December 4, 2018 by xttl

[kb1]

On 12/2/2018 at 2:11 AM, Looper said:

Thanks for the clear response.

 

 

CNdoom does not actually fix the quick start, it only makes it easier to perform by giving the player more time to press the keys. However, that is a big difference because it has the exact same problem as Chocolate doom: You get the slightly broken quick start with two frames missing the strafe command.

 

I have tested this under Chocolate Doom, Crispy Doom and CNDoom. All of them having 100% identical quick start behaviour, except for the CNDoom having more time to insert the commands/key pressings.

Do you know which tic number vanilla starts accepting key presses? It would be nice to know why all ports get this wrong.

[zokum]

6 hours ago, kb1 said:

Do you know which tic number vanilla starts accepting key presses? It would be nice to know why all ports get this wrong.

From the first tic I think. If you look at the screenshot, SL40 is missing from the first two ticks, but the turn and move forward are registered correctly.

[Looper]

13 hours ago, kb1 said:

Do you know which tic number vanilla starts accepting key presses? It would be nice to know why all ports get this wrong.

Vanilla allows move forward and strafe from the very first frame. This can be confirmed by checking the inputs of old demos.

[kb1]

8 hours ago, Looper said:

Vanilla allows move forward and strafe from the very first frame. This can be confirmed by checking the inputs of old demos.

Yes, but the first game frame is not always frame 0. I guess maybe it is, if you supply -WARP at the command line. But the frame (tic) counter runs during pause, during the menu, during INTERPIC, etc.

 

I'm kinda skeptical, because if Chocolate is missing movement commands that vanilla doesn't miss, this should affect Chocolate's playback of vanilla demos, shouldn't it? What I mean is that this should have been noticed a long time ago, while testing the playback of demos. I guess maybe the tic counter is corrected right before demo playback begins.

 

So, how about recording in Chocolate, then doing playback in vanilla? Does that work? Maybe that's not a valid test either, cause vanilla also would zero the tic counter before demo playback.

 

If this is a true problem, I don't envy fraggle. This would have to do with order of operations in the main game loop (D_DoomLoop), which is a function that's very carefully structured to do things in exactly the correct sequence. Moving things around here is very tricky, indeed. I guess some debug output while reading tic commands might be a good place to start. Goodness. Best of luck!

[zokum]

It would be interesting to see if this regression is something that exists in the non-source Linux versions of the game. Does this problem exist in the the early source ports based on the 1.10 source? Maybe the DOS versions have this minor advantage over the Linux ports? If this is the case, this minor gameplay change would be an interesting find to document in the wiki.

[zokum]

16 minutes ago, kb1 said:

Yes, but the first game frame is not always frame 0. I guess maybe it is, if you supply -WARP at the command line. But the frame (tic) counter runs during pause, during the menu, during INTERPIC, etc.

 

I'm kinda skeptical, because if Chocolate is missing movement commands that vanilla doesn't miss, this should affect Chocolate's playback of vanilla demos, shouldn't it? What I mean is that this should have been noticed a long time ago, while testing the playback of demos. I guess maybe the tic counter is corrected right before demo playback begins.

This won't affect demo playback I think. The bug is that Chocolate Doom doesn't properly register all key presses very early in the game. Choco handles the movement instructions just fine internally, it plays back demos correctly. It just doesn't register that these keys have been pressed. The problem might lie elsewhere in the stack of how keypresses are handled, outside of Chocolate Doom and inside a library.