DOSBox Daily - KDIKDIZD out of the oven and ready to go!

[Gibbon]

20 minutes ago, OpenRift said:

Hey @Gibbon so I kind of had a thought, would you be interested in working on a DOS-based front-end for Doom? Like the a DOS equivalent of ZDL? I came up with this concept a while back and given your retro coding fixation, I had a hunch you might want to work on something like this:

 

You mean an actual DOS program?

 

That would probably not be something I would do.  I've never used any of DOS' native drawing API's nor have I ever written 16bit C (and definitely not DOS assembler).

 

I am also not on Windows enough to do it, as you would realistically need Open Watcom to make 16bit DOS binaries.

[OpenRift]

15 minutes ago, Gibbon said:

You mean an actual DOS program?

 

That would probably not be something I would do.  I've never used any of DOS' native drawing API's nor have I ever written 16bit C (and definitely not DOS assembler).

  

I am also not on Windows enough to do it, as you would realistically need Open Watcom to make 16bit DOS binaries.

Understandable. Well, if you know anyone who would be interested in such a project, please do point them our way, because this could change DOS Dooming forever if it ever came to fruition.

[Gibbon]

8 hours ago, OpenRift said:

Understandable. Well, if you know anyone who would be interested in such a project, please do point them our way, because this could change DOS Dooming forever if it ever came to fruition.

It definitely would!  One thing I will do though is give it a go.  I'll take the GPL release of SETUP.EXE as a guide and try to get that working with open watcom.  It's definitely intriguing.

 

EDIT:

So..  ooof.  Seems that SETUP.EXE was made with a newer version of TURBO C then what was released by Borland as freeware (probably version 3 in ~1992 ish.  It also contains some pre-compiled object files and other stuff that you cannot change in screens).  basically you'll have to find someone to code from scratch a new one in 16bit C and DOS Assembler.

 

No wonder nobody has done it yet.

Edited December 30, 2021 by Gibbon

[adamastor]

11 hours ago, Gibbon said:

You mean an actual DOS program?

 

That would probably not be something I would do.  I've never used any of DOS' native drawing API's nor have I ever written 16bit C (and definitely not DOS assembler).

This got me thinking Gibbon: would it be feasible to develop a fork of DOS BOOM with the updates you introduced in ReBOOM?
 

Or make a fork of ReBOOM compatible with DOS? Those small features you added such as the stats above the status bar, and the Ty code would be great to see in that form.

[Redneckerz]

1 hour ago, Mr. Kong said:

This got me thinking Gibbon: would it be feasible to develop a fork of DOS BOOM with the updates you introduced in ReBOOM?
 

Now that could work, but you would be missing out on a lot of what EDGE introduced. EDGE 1.27 (November 11, 2001) still had DOS support although the executables are for Windows. Likely EDGE32.exe works when you set it using -forcevga. EDGE will then render in standard 320x200 at 8 bits depth. Perhaps @Lobo could explain it better or has a DOS version laying around? Edge 1.28 (May 24, 2004) moved to Windows and does not have the DOS parameter anymore mentioned in the readme.

Quote

Or make a fork of ReBOOM compatible with DOS? Those small features you added such as the stats above the status bar, and the Ty code would be great to see in that form.

Contrary to belief, DOSDoom and Boom are two rather distinct efforts. DOSDoom eventually became EDGE, with its DDF scripting and what not.

Edited December 30, 2021 by Redneckerz

[Gibbon]

3 hours ago, Mr. Kong said:

This got me thinking Gibbon: would it be feasible to develop a fork of DOS BOOM with the updates you introduced in ReBOOM?
 

Or make a fork of ReBOOM compatible with DOS? Those small features you added such as the stats above the status bar, and the Ty code would be great to see in that form.

Well it would definitely be possible yes.  I'm not sure if Boom 2.02 can be compiled with the DJGPP versions of today but I can certainly try in DOSBox (I'm pretty sure Boom was done with DJGPP or some GCC compatible compiler), though compiling stuff there either crashes it or it takes a really long time.

EDIT:

So I've setup DJGPP from 1998/1999 and I've got a dev environment up and will compile allegro 3.12 first then get onto Boom.

Edited December 30, 2021 by Gibbon

[adamastor]

3 hours ago, Gibbon said:

Well it would definitely be possible yes.  I'm not sure if Boom 2.02 can be compiled with the DJGPP versions of today but I can certainly try in DOSBox (I'm pretty sure Boom was done with DJGPP or some GCC compatible compiler), though compiling stuff there either crashes it or it takes a really long time.

EDIT:

So I've setup DJGPP from 1998/1999 and I've got a dev environment up and will compile allegro 3.12 first then get onto Boom.

Awesome!

[Gibbon]

Question.  I'm assuming you want the entirety of the features right?  So that means also the UMAPINFO support?

[adamastor]

4 hours ago, Redneckerz said:

Contrary to belief, DOSDoom and Boom are two rather distinct efforts. DOSDoom eventually became EDGE, with its DDF scripting and what not.

Thanks, Reneckerz.

You're a great help in discovering all this DOOM history.

[adamastor]

Just now, Gibbon said:

Question.  I'm assuming you want the entirety of the features right?  So that means also the UMAPINFO support?

I have no idea if that'd be something you'd be willing to shoe in but, if that'd be the case then, of course man!

[Dusty_Rhodes]

Anyone know how to get DOSBox to use a .sf2 soundfont for midi playback? I really want to use WeedsGM4, as it's my favorite soundfont.

[Master O]

5 minutes ago, Dusty_Rhodes said:

Anyone know how to get DOSBox to use a .sf2 soundfont for midi playback? I really want to use WeedsGM4, as it's my favorite soundfont.

 

https://github.com/dosbox-staging/dosbox-staging/wiki/MIDI#configuration

 

In Staging's dosbox.conf, go to the following sections and change accordingly:

[midi]
mididevice = fluidsynth

[fluidsynth]
soundfont = /path to/soundfont.sf2

 

The original Dosbox 0.74 does not have support for Fluidsynth iirc.

Edited December 30, 2021 by Master O

[adamastor]

1 minute ago, Master O said:

 

https://github.com/dosbox-staging/dosbox-staging/wiki/MIDI#configuration

 

In Staging's dosbox.conf, go to the following section and change accordingly:

[midi]
mididevice = fluidsynth

[fluidsynth]
soundfont = /path to/soundfont.sf2

 

The original Dosbox 0.74 does not have support for Fluidsynth iirc.

Hear, hear for DOSBox Staging wizardry.

[SilentD00mer]

1 hour ago, Master O said:

 

https://github.com/dosbox-staging/dosbox-staging/wiki/MIDI#configuration

 

In Staging's dosbox.conf, go to the following sections and change accordingly:

[midi]
mididevice = fluidsynth

[fluidsynth]
soundfont = /path to/soundfont.sf2

 

The original Dosbox 0.74 does not have support for Fluidsynth iirc.

 

Does DOSBox-X have support for Fluidsynth? So I could use this with it too?

[adamastor]

2 minutes ago, SilentD00mer said:

 

Does DOSBox-X have support for Fluidsynth? So I could use this with it too?

I think that it does indeed.

[SilentD00mer]

16 minutes ago, Mr. Kong said:

I think that it does indeed.

Oh, thanks! I'll try to use DOSBox-X. I tried to set DOSBox with Fluidsynth some time ago, but I lost the configs and I don't remember what I did that time, but I remember it was complicated (I tried the solutions I found in some forums).

[adamastor]

1 minute ago, SilentD00mer said:

Oh, thanks! I'll try to use DOSBox-X. I tried to set DOSBox with Fluidsynth some time ago, but I lost the configs and I don't remember what I did that time, but I remember it was complicated (I tried the solutions I found in some forums).

I think that DOSBox-X or, as Master O mentioned, DOSBox Staging are indeed safer bets for that. They're full of pretty great features.

[Redneckerz]

2 hours ago, Mr. Kong said:

Thanks, Reneckerz.

You're a great help in discovering all this DOOM history.

That has to be the nicest thing someone has told me this month. Thank you.

 

If you have any other questions, feel free to PM me :)

[Master O]

10 minutes ago, SilentD00mer said:

Oh, thanks! I'll try to use DOSBox-X. I tried to set DOSBox with Fluidsynth some time ago, but I lost the configs and I don't remember what I did that time, but I remember it was complicated (I tried the solutions I found in some forums).

 

https://dosbox-x.com/wiki/DOSBox‐X’s-Feature-Highlights mentions full Fluidsynth support.

[Gibbon]

Spoiler

Done, I'll get to work then backporting ReBOOM changes onto DOS BOOM.  I've setup my DOS emulator to mimic an interlaced CRT :) just as I remember it.

 

I've done a cheat message for Rand Phares too.

[adamastor]

5 minutes ago, Gibbon said:

  Reveal hidden contents

Done, I'll get to work then backporting ReBOOM changes onto DOS BOOM.  I've setup my DOS emulator to mimic an interlaced CRT :) just as I remember it.

 

I've done a cheat message for Rand Phares too.

We couldn't ask for more, Gibbon.

[SilentD00mer]

57 minutes ago, Master O said:

 

https://dosbox-x.com/wiki/DOSBox‐X’s-Feature-Highlights mentions full Fluidsynth support.

 

Cool! Now I can use my favorite soundfonts with DOSBox! Thanks! :)

[OpenRift]

tbh I just used VirtualMIDISynth for running soundfonts, because it would use that soundfont for everything and was a one-time setup.

[maxmanium]

There are some maps in AV that cause a crash when saving due to their size (i.e. Toxic Touch and Misri Halek) so I've applied the DEHACKED patch to DOOM32.EXE and copied the par times from AV.EXE in HxD. I'm pretty sure I did it right but someone should double-check.

 

AV32.zip

[adamastor]

4 minutes ago, maxmanium said:

There are some maps in AV that cause a crash when saving due to their size (i.e. Toxic Touch and Misri Halek) so I've applied the DEHACKED patch to DOOM32.EXE and copied the par times from AV.EXE in HxD. I'm pretty sure I did it right but someone should double-check.

 

AV32.zip

I did the same in my case as well, also on account of playing through Black Label later.

[punch you in the face man]

7 minutes ago, maxmanium said:

There are some maps in AV that cause a crash when saving due to their size (i.e. Toxic Touch and Misri Halek) so I've applied the DEHACKED patch to DOOM32.EXE and copied the par times from AV.EXE in HxD. I'm pretty sure I did it right but someone should double-check.

 

AV32.zip

On my end this exe crashes when saving on any map. Saving on map01 caused the game to hang like what usually happens when a map is too large to save, but saving on map10 and map20 caused Dosbox Staging to crash right to desktop.

[maxmanium]

9 minutes ago, punch you in the face man said:

On my end this exe crashes when saving on any map. Saving on map01 caused the game to hang like what usually happens when a map is too large to save, but saving on map10 and map20 caused Dosbox Staging to crash right to desktop.

 

That's bizarre, it worked just fine for me. Maybe it's something with your config? Did you get any useful console output when it happened?

 

EDIT: What's your memsize in your dosbox config? I have mine set to 63. If you haven't changed it I believe the default is 16 which presumably is not enough for the hacked executable since it extends several limits. Just a guess tho.

Edited December 30, 2021 by maxmanium

[punch you in the face man]

18 hours ago, maxmanium said:

What's your memsize in your dosbox config?

Ah, that was it. I set it to 63 and it's working fine now. Hopefully that will at least help someone else if they have the same problem.

 

EDIT: Doom32 has a heapsize of 32 megs so there's no need to set it higher than 32. Shouldn't affect anything, but just letting people know.

EDIT2: Actually that is not the case. Plutonia 2 with a patched fdoom32.exe was causing that same crash on a game save even with a heapsize of 32, 63 worked though. I guess you need more memory to save the game than you do to play it. New to DOSBox doom, so I'm figuring this stuff out as I go.

Edited December 31, 2021 by punch you in the face man
i am not a clever man

[OpenRift]

3 hours ago, maxmanium said:

There are some maps in AV that cause a crash when saving due to their size (i.e. Toxic Touch and Misri Halek) so I've applied the DEHACKED patch to DOOM32.EXE and copied the par times from AV.EXE in HxD. I'm pretty sure I did it right but someone should double-check.

  

AV32.zip

When you say "cause a crash", how do you mean? Like a VPO or...?

[maxmanium]

21 minutes ago, OpenRift said:

When you say "cause a crash", how do you mean? Like a VPO or...?

 

https://doomwiki.org/wiki/Save_game_buffer_overflow