Malik wrote:I'm sorry I didn't go through all the posts here yet, but is jumping being implemented? I know it will break the gameplay since the original design was not designed with jumping in mind, but still i wonder...

I understand that this release really shines on post Pentium II systems, yet it works very nicely on an AMD 5x86 + VLB Vga system. My benches show a mere 0.9 fps drop versus vanilla DOOM shareware 1.7. Plain VGA mode, of course. My only problem is with sound (as it is provided by Allegro). 1. SB16 CT1740 is detected in the setup as an SB16/AWE32 but produces only FM music in game, the digital part is mute. I tried changing resources manually. No dice.2. Moreover, the daughterboard at 300h makes the game freeze at the loading screen when music data is accessed. (If I select the intelligent MPU-401 (MPU-IPC-T) at 330h, my sc8820 plays the music properly.) Is there a proper allegro sound driver for early SB16 cards and their MPU-401 port?

EDIT:

Problem 1. is solved. For some reason, low DMA cannot be used for digi. High DMA works. Problem 2 remains...

Would be nice to make the allegro setup program it ships with to read from a WAD for the background/samples as well for consistency with say......alternative iwads. it would make it more Free at the same time

Voodoo2s aren't 100mhz stockGeforce256 isn't released as a beta on New Years '99 under the Quadro brandDOS gaming isn't a bilinear 320x200 16:10DOS PCs aren't better than the MacintoshDOSBox is not for running Windows 9xSGL != Glide

Jolaes76 wrote:The daughterboard at 300h makes the game freeze at the loading screen when music data is accessed. (If I select the intelligent MPU-401 (MPU-IPC-T) at 330h, my sc8820 plays the music properly.) Is there a proper allegro sound driver for early SB16 cards and their MPU-401 port?

I just tested the game with a CS4232 based soundcard, with the daughterboard at 330h or 300h, and that seems to work well (setup+game). In UART mode that is. So is this early SB16 MPU-401 specific? Does the setup program run reliable, does it pass the sound tests?

leileilol wrote:Would be nice to make the allegro setup program it ships with to read from a WAD for the background/samples as well for consistency with say......alternative iwads. it would make it more Free at the same time

Yeah I considered that, I will think about it again. There are some difficulties with this.

I am now having troubles with my pentium III that I use for working on MBF. It locks up and doesn't want to boot unless one reinserts the RAM in the socket. Probably it needs to be recapped.

First of all, none of GM devices are auto detected. Auto detect only picks up OPL3 synth. I can manually change the port, but selecting [MPU 401] at [-1] or [300] freezes both the SOUND SETUP TEST and the game loading as well.

CT1740 and CT1750 with DSP v4.05 both exhibit the MIDI freeze issue. I can set MIDI port to -1 or 300h, both freeze the start-up of shareware DOOM at " I_InitSound: "When I select 330h where the intelligent MPU 401 interface is, the game loads and auto-demo plays with sound.

Maybe I could remove the IPC-T and give 330h to the SB16 to check if the issue is restricted to addresses OTHER than 330h. But I am not giving up my true MPU so this is purely academic

Thanks for the explanation,In the source I notice that the allegro driver first checks port that has optionally been set manually. If not it reads the P value from the SET BLASTER environment variable. Otherwise it just tries 330h.

I will put in my oldest SB16 an try something, but I don't own a CT17xx model..

*auto detection detects WSS, which does not work. Manually setting SB Pro works great for digital effects. I had an issue with MIDI--auto-detection picked OPL3, which worked. I manually selected MPU401, which worked. Then I manually selected OPL again, and this time it did not work. I manually went back to MPU401 and it did not work. I could never get MIDI music to play again after that initial auto-detection.

edit: I just remembered, manually setting SB Pro on the 2nd system is not flawless. It only plays audio in the left channel. I tried setting to the other SB/Adlib options, but they all either don't work, or work only on the left channel. Probably a compatibility issue with the Audician?

Yes it would. As it stands there's not much to differentiate this port from the original - not enough to make me prefer playing it over the original at least - or over Zdoom. Right now I either play Zdoom on my athlon xp rig under win98, or the original version under DOS.

There's ports that do high-res, and 3d acceleration, but they're for windows.

What I'd like from a new Doom DOS port is:- glide support- mouselook

and I'm sure I'm not the only one who would find these features interesting.

maintenance release. Glide support is easier said than done (translating Doom into 3d is not trivial), not worth the trouble for 1 person, and is out of the scope for a maintenance project.

Voodoo2s aren't 100mhz stockGeforce256 isn't released as a beta on New Years '99 under the Quadro brandDOS gaming isn't a bilinear 320x200 16:10DOS PCs aren't better than the MacintoshDOSBox is not for running Windows 9xSGL != Glide

leileilol wrote:maintenance release. Glide support is easier said than done (translating Doom into 3d is not trivial), not worth the trouble for 1 person, and is out of the scope for a maintenance project.

I only have a basic understanding of coding, so I have no idea if it could be done and how. It would have been cool to run doom under glide on a retro rig tough

I'm having performance issues (slow, choppy framerate) with this version compared to some other DOS ports. The particular map that I'm having an issue with is MAP03 of THT: Threnody but I'd suspect there are probably others that would be an issue, I haven't extensively tested WADs with it.

In contrast, Boom 2.02 performs fine but lacks the MBF-specific features, and the last release of SMMU performs fine but makes some seemingly non-disable-able changes to standard Doom behavior that I do not like.

Also, how possible would it be to backport the -complevel 0 (Doom v1.2 emulation) option from PrBoom+? A few very old WADs (such as this one for example) rely on some v1.2 behaviors, but using the actual Doom v1.2 on my old machine isn't viable due to mouse bugs that were fixed in later versions.

ETTiNGRiNDER wrote:Also, how possible would it be to backport the -complevel 0 (Doom v1.2 emulation) option from PrBoom+? A few very old WADs (such as this one for example) rely on some v1.2 behaviors, but using the actual Doom v1.2 on my old machine isn't viable due to mouse bugs that were fixed in later versions.

Doom v1.2 demo compatibility was added already. But I suppose it needs the v1.2 iwad to trigger this mode.

I am having some issues with setting up my new MIDI device (MPU-401 connected MIDI module to FSMP on Windows). Whenever I select my AWE64 for digital out (AWE32 option), and MPU-401 for MIDI OUT, the SETUP program just hangs my computer when entering "Test Settings". It does not seem to matter whether I select port "-1" (default) or "330" for MIDI OUT. When I select the AWE32 MIDI OUT device instead, the SETUP program mentions that it is not possible to use this soundcard's DSP and MIDI OUT at the same time.The MIDI output does work properly, when I choose "No Sound" for the digital output.

What is this all about? Is this a limitation of MBF? Other games do not seem to have issues to utilize both at the same time. Also: somehow (really don't know what I did exactly) I got MPU-401 MIDI OUT to work together with digital out, just once, and it sounded just fine! This is what kinda frustrates me: if it worked once, why will it not work anymore after a reboot? (and not having changed any settings in MBF)

This behaviour is indeed odd. I haven't touched the the SB16 and AWE drivers really (it is the Allegro 3.0 library that is used for sound). In the todo list is something with the SB16 already. I will see if there is time to to check it, but haven't had much time for hobbies for months now Just small amounts.

gerwin wrote:Next; I don't like the fact that MBF does not give sound with the Vortex-2 PCI SB-Pro emulation driver.

Answer to self: The culprit is the DPMI extender. swap it with DOS32 or something and it will work.

After some more extensive testing, it seems MBF is not to blame after all.

It happens with every game that utilizes both the MPU401 for music and Sound Blaster for sound effects. I have also found a (very dirty) solution: if I first launch the game ROTT (or it's sound setup program), it will successfully initialize the MPU401, after which all other games that I have set up to use the MPU401 with Sound Blaster work perfectly fine. Even if I run the DIAGNOSE program again (SB16 init) in between. So ROTT does something to "fix" the soundcard issue (until I reboot the system that is...).

This is what confused me into thinking the issue was only MBF related: during testing my new MIDI setup, ROTT must have been somewhere in the middle of my testing rounds - and I would be like "oh see, it works in ROTT, but not in MBF". Sorry about that!

Note: this issue is also not soundcard type related, as the exact same thing happens on my new SB16 (CT2290) and previous AWE64 Gold. Perhaps I can find a neater way to initialize the MPU401 properly...