crvs wrote on 2022-06-21, 22:54:

halfmoon wrote on 2022-06-21, 18:46:

Gmlb256 wrote on 2021-08-05, 16:31:

Has anyone noticed that MAP02 music on Final DOOM TNT: Evilution sound slightly different in comparison to the original DOS executable that was shipped with the game?

There is one note that doesn't seem to play on MBF.

I encountered something similar with Doom1 using MBF - the score/intermission screen (after you finish a level) music seems to not play some notes or something during the beginning of the track - first 2 seconds or so with the drums. Using MIDI - not sure about FM. Tried with both the most recent build posted by crvs as well as the version from 1998 and the issue seems present in both. Tested using DOS 7.1 on a Pentium 3 with a Yamaha Audician ISA sound card using external MIDI. Using the same setup with the original Doom exe works perfectly.

Can you try this .EXE?

Still has the issue with MAP02 music of TNT: Evilution. 🙁

halfmoon wrote on 2022-06-21, 23:59:

I just tried and it seems like the issue is still the same. Are you able to replicate the issue using MIDI/MPU-401 music? I'm not sure if it's a missing note or it's hitching but it happens a few times in those first couple of seconds. It's less obvious when listening to a Sound Canvas but all my other MIDI synths really make the issue obvious.

Then this issue is probably device-specific. In DosBox, all versions sound the same to me. I did a lot of changes since last release and this is the latest build that I could make, just hoped it worked. All my 'real' hardware is lost in the war, as well as the latest sources, hence there will be no more updates from me in near future, if I ever return to the project.

crvs wrote on 2022-06-22, 01:06:

halfmoon wrote on 2022-06-21, 23:59:

I just tried and it seems like the issue is still the same. Are you able to replicate the issue using MIDI/MPU-401 music? I'm not sure if it's a missing note or it's hitching but it happens a few times in those first couple of seconds. It's less obvious when listening to a Sound Canvas but all my other MIDI synths really make the issue obvious.

Then this issue is probably device-specific. In DosBox, all versions sound the same to me. I did a lot of changes since last release and this is the latest build that I could make, just hoped it worked. All my 'real' hardware is lost in the war, as well as the latest sources, hence there will be no more updates from me in near future, if I ever return to the project.

I tried in DosBox 0.74 using the default Windows Microsoft GS Wavetable Synth and it seems to have this issue in MBF as well. I also tried SoundBlaster in DosBox and it seems like it might have the issue as well but the general music fidelity is so low in comparison, I doubt anyone would notice the difference at the beginning of the track unless you're looking for it.

halfmoon wrote on 2022-06-22, 03:02:

I doubt anyone would notice the difference at the beginning of the track unless you're looking for it.

You could probably want to point it out, maybe record the right fragments ..

crvs wrote on 2022-06-22, 05:43:

halfmoon wrote on 2022-06-22, 03:02:

I doubt anyone would notice the difference at the beginning of the track unless you're looking for it.

You could probably want to point it out, maybe record the right fragments ..

I recorded using a Yamaha S-YXG50 softsynth and DosBox-X. It's even more pronounced on my real hardware but that will require some more effort to capture.
Hopefully you can notice a difference here. It's in the first ~2 seconds. In the vanilla exe, it's a consistent drum beat, but with MBF it sounds like it's struggling to play for the first couple of seconds.

crvs wrote on 2022-06-22, 01:06:

I did a lot of changes since last release and this is the latest build that I could make, just hoped it worked. All my 'real' hardware is lost in the war, as well as the latest sources, hence there will be no more updates from me in near future, if I ever return to the project.

That sure is a dramatic and valid excuse for losing things.
Sorry to hear about that, also considering all the bigger real-life troubles that surely came with it.

halfmoon wrote on 2022-06-22, 06:33:

I recorded using a Yamaha S-YXG50 softsynth and DosBox-X. It's even more pronounced on my real hardware but that will require some more effort to capture.
Hopefully you can notice a difference here. It's in the first ~2 seconds. In the vanilla exe, it's a consistent drum beat, but with MBF it sounds like it's struggling to play for the first couple of seconds.

I can hear it. It sounds like an issue with slow feeding of midi data from the game with midi driver. It always becomes obvious with fast drums. Dune 2 has some tracks that are a good test for such.
If someone can capture the raw midi data with DosBox and compare it, it will probably be the exact same data, just the timing in which each byte was send being different.
One other idea is to build Allegro Setup.exe with such a Dune 2 fast drum track, as the Music driver testing track, and see if the problem is there too. Which would prove it is caused by the Allegro midi driver.

gerwin wrote on 2022-06-22, 21:09:

That sure is a dramatic and valid excuse for losing things.
Sorry to hear about that, also considering all the bigger real-life troubles that surely came with it.
I can hear it. It sounds like an issue with slow feeding of midi data from the game with midi driver.

These are just things and I'm way more lucky than many others. That's all that I want to say.

On the root cause you are right, quick'n'dirty fix is pretty straightforward - to increase x2 (from 40 to 80 BPS) frequency of the interrupt in "midi.c". A smaller speed raise can be sufficient but I can't test it reliably in the emulator. Of course it could be better to try optimizing midi interrupt code, and (maybe) even to fix the Allegro timers (impossible task), I have played with them a bit but couldn't finish the job.

Here I attached another build, this one seems to sound better on level completion, if anyone wants to try it you're welcome (again, it's untested and not guaranteed to work).

crvs wrote on 2022-06-22, 23:17:

These are just things and I'm way more lucky than many others. That's all that I want to say. […]
Show full quote

gerwin wrote on 2022-06-22, 21:09:

That sure is a dramatic and valid excuse for losing things.
Sorry to hear about that, also considering all the bigger real-life troubles that surely came with it.
I can hear it. It sounds like an issue with slow feeding of midi data from the game with midi driver.

These are just things and I'm way more lucky than many others. That's all that I want to say.

On the root cause you are right, quick'n'dirty fix is pretty straightforward - to increase x2 (from 40 to 80 BPS) frequency of the interrupt in "midi.c". A smaller speed raise can be sufficient but I can't test it reliably in the emulator. Of course it could be better to try optimizing midi interrupt code, and (maybe) even to fix the Allegro timers (impossible task), I have played with them a bit but couldn't finish the job.

Here I attached another build, this one seems to sound better on level completion, if anyone wants to try it you're welcome (again, it's untested and not guaranteed to work).

I tried for a brief while using DosBox-X and the Yamaha softsynth and it definitely sounds better on the intermission screen. Thanks! Maybe I'll do some more testing using real hardware a bit later today and see if there's any issues.

halfmoon wrote on 2022-06-23, 00:38:

I tried for a brief while using DosBox-X and the Yamaha softsynth and it definitely sounds better on the intermission screen. Thanks! Maybe I'll do some more testing using real hardware a bit later today and see if there's any issues.

Great! It will be interesting to learn about the result.

gerwin wrote on 2022-06-21, 23:38:

Setup.exe is part of the full build of Allegro game library from the source. It gets build automatically when you build Allegro with all options enabled. It embeds setup.dat inside the setup.exe binary. You have to edit the contents of setup.dat with the Allegro grabber or dat tool, so that it holds the desired background image. Those two tools also get build with Allegro.
Of course for Doom MBF I made this modified Allegro 3.0, with better sound drivers and such. AFAIK Both Allegro 3.0 original and modified only properly compile with 1997 DJGPP sofware. Earlier in this topic I mentioned the exact packages and versions.

Thanks, I'm slowly remembering what I did back then, although I've not been able to compile a new SETUP.EXE so far. I also forgot that you made quite a few updates to MBF after I built my HacX binary back in 2015.

UPD: I was able to build the custom SETUP.EXE -- I just had not immediately realised that you changed the fonts in SETUP.DAT, and was trying to use an old modified version of that which was not compatible with the update.

gerwin wrote on 2015-06-25, 19:42:

Yes,
One of the last changes to MBF 2.04 was the use of VESA mode 320x200 when listed as supported in the VESA BIOS. Usually mode 150h. As this mode allows page flipping, and is more compatible+faster then Mode-X*. It also means that in that case MBF will prefer VESA 320x200 above mode 13h. One can verify which mode is used by MBF by enabling the option "Show frame rate + mode indicator".

I discovered an interesting thing: if S3 VBE/Core 2.0 is loaded prior to running MBF, it switches to a VESA mode 163h which does not have the incorrect aspect ratio screen problem with aspect=true.


I'm not certain if any of the two is faster than the other (running the game with high enough cycles to keep FPS at 35 at seemingly all times).

crvs wrote on 2022-06-23, 12:48:

halfmoon wrote on 2022-06-23, 00:38:

I tried for a brief while using DosBox-X and the Yamaha softsynth and it definitely sounds better on the intermission screen. Thanks! Maybe I'll do some more testing using real hardware a bit later today and see if there's any issues.

Great! It will be interesting to learn about the result.

Okay, so I played through Episode 1 of Doom using real hardware (DOS 7.1, P3, Yamaha Audician & external MIDI) and everything seemed to sound fine and I didn't encounter any new issues.
As for the sweet spot for the interrupt BPS value, I'm not sure the significance of the value of 40, but I assume multiples of that value are fairly safe and probably won't introduce any timing weirdness. If anything, I'm wondering if increasing it beyond 80 to 120 or even 160 could yield even more "accurate" results, though I'm not sure what kind of performance or other impact this could have.

Unrelated, but I did notice in the past that MBF doesn't send a GM reset command through MIDI so I have to use a batch file with "gsplay.exe gm" to initialize that correctly before running, as well as after MBF closes to make sure no MIDI notes are hanging on exit. The vanilla exe doesn't seem to suffer from these issues and I don't expect anyone to fix it in MBF but I'll be happy if they do.

MrFlibble wrote on 2022-06-25, 19:42:

I discovered an interesting thing: if S3 VBE/Core 2.0 is loaded prior to running MBF, it switches to a VESA mode 163h which does not have the incorrect aspect ratio screen problem with aspect=true.

Yes. That is intentional. Mainly because VESA 320x200 mode allows for page flipping, mode 13h cannot do that. AFAIK performance is the same.

I keep running into an odd bug I cannot quite pin down.

When I build MBF with GCC 4.7, it keeps corrupting certain key bindings when I load custom PWADs, specifically the REKKR total conversion. Namely, the minus key stops working altogether, because the game sets key_zoomout and key_map_zoomout to 0.

At first I thought that this was due to the stand-alone IWAD of the same TC that I put together, but the same problem occurs even if I use Freedoom IWAD and load the REKKR PWAD from the link in the previous paragraph.

I have not altered the source code from Upload no. 019 apart from replacing text strings, and also including Ouch face and medikit that you REALLY need fixes.

I compile the code in DOSBox (I know, I know) with the following parameters:

1-O1 -ffast-math -fomit-frame-pointer -mtune=i486 -fstrength-reduce -fexpensive-optimizations

Helper dogs and Doom beta emulation are disabled.

Here are my latest attempts:

• rekkrmbf-220707.zip - requires REKKR.WAD and an IWAD of choice (e.g. Freedoom 0.7)
• rekmbf_s-220707.zip - source

If I compile with GCC 2.7, the minus key works fine, but occasionally other keys stop working, including > for strafe right, and even Esc to exit menus.

In all cases, the game works fine on the first run when the CFG file is generated, but on subsequent runs the keys in question get altered or set to zero. With the GCC 4.7 build, the minus key reliably gets set to zero on the second run.

MrFlibble wrote on 2022-07-07, 13:20:

I keep running into an odd bug I cannot quite pin down.

I believe it's because ABI is somehow changed between two compilations so some characters/symbols get mismatched. I have got absolutely the same problem, but ultimately I just take it as a feature, and somehow I'm used to this behavior. Nothing to do with WAD, this mismatch will show even between the same source code but with different flags (debugging symbols and different optimizations).
Currently, I possess MBF with debugging symbols so I coud try to intercept it but absolutley no idea what shoud I watch for (breakpoint/catchpoint).

Ah, I see. I've settled for the GCC 2.7 build so far, been playing it for a bit and it seems to work fine.

Does this source port support controls like modern shooters ?

I'm interested in a source port for DOOM under DOS that supports controls like in modern shooters.

So, this is not Doom, but close enough - I produced a DJGPP build of Hexen with Allegro-based system funcs (and Allegro itself) I (once again) borrowed from @gerwin's code. Was using original Hexen source code release as a basis. 640x400 is supported, but as with MBF 2.04 I expect letterboxed 640x480 to work too on Intel cards, etc.

Here is a demo recording of the first level: https://www.youtube.com/watch?v=6TKlzq1Zla4

The aspect correction is purely video post processing effect; it's not performed by the engine.

ludicrous_peridot wrote on 2022-11-28, 22:37:

I produced a DJGPP build of Hexen with Allegro-based system funcs

Nice work! Seems like a more manageable project to work on Hexen separately, compared to fusing the two like ZDoom.
Whenever you have a version suitable for release, I will surely put it on my retro computer, for another playthrough. Looking forward to seeing it in 640x400 this time.

you'll probably want to double-size those pics. the inventory square looks awkward and tiny numbers could be a pain.

Heretic, Hexen and Strife doesn't get a lot of dos port love in general. I think only Vavoom was the other, and that's a drastic fusion of the quake renderer that looks very off for the doom engine (but still, technically impressive and still did a lot of things most doom source ports don't do)

@leileilol , you are correct there's no patch scaling in this this hack of port, so would be good to know how much pain the numbers on the inventory cause on a CRT in hi res.

I've made some clean-up after the video was recorded and pushed the source code to https://gitlab.com/ludicrous_peridot/bernewfie

Not sure when (or if) this will become a "release"-grade port, as I will unlikely have suitable time to devote to such goal this year, and next year probably as well, and for 2024 - I am not sure it will even come... so playthrough may be a risky endeavor 😀 (for example, game crashes very fast into the first level - actually with the first thinker being removed and its associate data freed - when built with instrumentation; and with release build I am seeing ghost ettins from time to time - or are these faster than light ettins? 😁 ).

That said I am more than happy to share the build in addition to sources if there's interest in trying it on different hardware (personally I don't even have an opportunity to check on the sig rig) and am around to fix less intricate bugs, if they are reported.