Thanks for noticing that - does not happen to me on my videocard (neither in Windows nor FreeDOS), but I was able to reproduce with DOSBox.
Attaching the patch with some cleanup and a change that removed the effect in DOSBox for me.
Will also be re-uploading a cleaned up version to github after a bit more testing.

By the way, the same effect I could see in the original SETUP.EXE for MBF that I have, only it's limited to letters in blue saying something along the lines of "Allegro setup..." and can be pretty hard to see. I think this may have been due to a more cleverly constructed palette in the @gerwin's SETUP.DAT...

Thanks!

I recently found out there's another Sigil episode. I did manage to play the first one just fine in MBF+fixes in first post, but the second one seems to be unusable and the episode won't show up in the game, even though the title graphics etc. did change.

I could use it with Sakitoshi's mbf_sigil but it has one major problem which is lack of WSS support. So I wonder what would it take to get the new episode work in the "regular" version that does have WSS support ?

Hello everyone,

MBF is a great project, can I also start coop mode via serial connection/ipx spx?

How can I do that?

Thank you in advance
Haggi

Tiido wrote on 2024-02-25, 07:39:

I could use it with Sakitoshi's mbf_sigil but it has one major problem which is lack of WSS support. So I wonder what would it take to get the new episode work in the "regular" version that does have WSS support ?

You might as well try Tartar - it is using the set of sound and video routines from MBF. I personally never tried it with WSS but it should work. Will also be interesting to see how it runs on your machine, as it was previously reported to be slower than MBF 😀

Haggi wrote on 2024-03-05, 16:56:

MBF is a great project, can I also start coop mode via serial connection/ipx spx?

How can I do that?

There must be a better way of doing this, but I trust SERBOOM.EXE and IPXBOOM.EXE would work just fine.
You find them in BOOM 2.0.2 distribution.
SERBOOM.EXE allows EXE name to be passed as parameter, but IPXBOOM has BOOM and DOOM hardcoded.
One way around this is by changing the IPXBOOM.EXE to refer to MBF.EXE instead
(a more straightforward one would be renaming MBF.EXE to, say, DOOM2.EXE).

Here's such updated version - it has allowed me to start a 2 player game between two DOSBox-es.

PS
I was trying to search why dogs would not appear in multiplayer game, and stumbled upon this:

------------------------------------------------------------------------------- […]
Show full quote

-------------------------------------------------------------------------------

DISCLAIMERS
...
MBF is a single-player game. Multiplayer games may or may not work (some people
say they do work).
...

-------------------------------------------------------------------------------

Okaaaay... 😉

Tartar sounds interesting, I will try it soon. As far as performance goes, I will probably not notice any kind of difference since it'll be used on a C2D based machine (RUBY-9719VG2AR). I definitely look forward to trying the higher resolutions that this will offer ~

ludicrous_peridot wrote on 2024-03-09, 10:55:

You might as well try Tartar - it is using the set of sound and video routines from MBF. I personally never tried it with WSS but it should work. Will also be interesting to see how it runs on your machine, as it was previously reported to be slower than MBF 😀

I finally got around to trying Tartar and the good news is that WSS works fine, and 1280 x 1024 (my card lacks 960 and 800 in VESA modes list) is very nice to look at ! FPS counter stays between 40...50 in all resolutions.

However I have not had luck getting Sigil2 to work right. Apart from filenames (SIGIL.WAD + SIGIL2.WAD) and being in a subfolder ( .\IWAD ), I do what the github page says.
* If I load just Sigil 2 it runs but with some wrong textures and there's a nonworking Sigil1 entry in small font in episode list. Playable but not quite right...
* If I load Sigil 1+2 I only get Sigil 1, the second one is not in the episodes list. That is the way I have played the eps in another port where things do work fine.
* Sigil 1 alone works just fine but that one I never had issues with...

Are the shims filename sensitive by any chance ? In pure DOS the original filenames cannot be represented due to them breaking 8.3 limit.

@Tiido: If you don't mind certain things you can actually take SIGIL2.wad, edit it in SLADE and rename E6M? to E3M?. Simply shift sixth episode to place of third. It shall work. Just be aware most maps requieres more than 128 visplanes (aka are not vanilla compatible).

@Tiido, apologies you are not getting working game by simply following the readme. I will review it.

From what I can see shims get loaded for you - they actually contain the definition of the episodes for them to be visible in the menu.

Can you try this: https://www.moddb.com/mods/tartar/news/decemb … r-tartar-update?

EDIT:
I think I realize what the problem could be. Can you try TARTAR -shim SHIMS\SIGIL_II -file SIGIL SIGIL2 ?

And no, shims are not case sensitive.

....aaaand I found my problem. I had the compatibility WAD of first Sigil ep (named to SIGILC.WAD) in my IWAD dir too and for whatever reason it was getting loaded also even though it was not specified anywhere... Once I got rid of that file, things began to work as expected. I am seeing that some of the demos go out of sync but that is perhaps because of some enemy behavious options related issue ? Overall I consider the problem solved ~

I'm quite pleased with this port, thänk you very much ~

As far as editing WADs go, I have completely zero experience with all the tools and everything around, for now I will not go that route. Perhaps one day I will want to make my own stages, as I have done with Duke3D...

Go here for retroarch doom engine discussion: Retroarch scaling with doom engine games

when testing MBF 2.04 and also boom, i've noticed MBF has a regression in regards to wad loading - in boom the -file parameter was no longer required and it's possible to just enter "boom wadname", while in MBF "mbf -file wadname" would be needed.

i'm also a bit surprised that neither boom nor MBF ever implemented next/previous weapon keys, which i think at least doom legacy did. having that along with mouse wheel support one day (in conjunction with a supported driver of course) would be impressive, because very few programs are out there with support for the wheel in DOS.

i will say MBF is a lot faster than boom indeed, the latter showing stuttering issues with even mildly complex maps. i'm not sure what purpose the vsync option serves though as it only cuts down the framerate, page flipping is enough and showed no visual anomalies when testing on a riva128 VBE 3.0 card.

While this answer of mine, may not be the most helpful one, MBF not having the simplified file loading feature of Boom 2.02 is not a regression. MBF is based on Boom 2.01, by the time TeamTNT has released 2.02, which included the feature you are referring to, MBF was a completely independent project. That said 2.04 includes a number of bugfixes and compatibility improvements taken from PrBoom lineage of Boom successors, so it's quite solid. Best of both worlds, if I may say.

Well, Boom and MBF should have the weapon toggle key button asignment, and this could be bound to middle mouse button, which DOS mouse driver can have wheel click registered as... not exactly what you are referring to, I guess, but somewhat tangential.

i wasn't that aware of the development history so that's a fair point, boom 2.02 has an oct 9 1999 .exe date while the (apparently) first MBF is jan 2 1999. i wonder if there is any other feature from boom that never made it over?

i only saw a best weapon toggle so that wouldn't be hugely helpful. really just having keys for prev/next weapon would be fine and bring the game up to par with duke3d, so 1996. quake was still a bit weird with only implementing a next weapon key...

is there any port out there that will attempt to pre-load the entire WAD file into RAM? from what i can tell, even modern ports seem to just load assets on demand.

this won't be an issue on most machines, but i once tested heretic on a p60 setup with 32mb memory and found that if i run the game from a ramdisk instead, the overall experience would be smoother as otherwise it had some noticeable stutter when first coming across assets. so for slow systems that have a lot of memory this might help more than anything else.

auron: The entire idea behind zone system is to use RAM as another stage between hard-drive and rendering system. It's loading and freeing assets as needed with very small RAM space. And this is valid for both, Quake and DOOM. Why would you even do that?

You could modify the source code - Alexey's done a proper DOS "backport" from the leaked sources.

ChocolateDoom, if I remember correctly, has the option in the source code to "pre-cache" all "assets"(but it's win only).
The delays you're talking about are not only cache but maybe also related to, so called, "composite textures" which are rendered from multiple patches.
But no guarantees - check the sources if you want to be sure.

I play DoomII a lot on my P66 and the "cache delays" are quite rare.

Grunt wrote on 2025-06-04, 18:06:

auron: The entire idea behind zone system is to use RAM as another stage between hard-drive and rendering system. It's loading and freeing assets as needed with very small RAM space. And this is valid for both, Quake and DOOM. Why would you even do that?

because making use of available hardware is a good thing in general and shows scalability. DOS is the perfect platform for this, as you don't exactly expect anything notable running in the background. people tend to put more RAM than what was normal at the time in their vintage systems and i'm no exception, but it often won't really do much at all for games.

ut2004 is the best example of such an option that i'm aware of, as you can set it to preload assets in order to reduce ingame hitching, but it warns to only turn the option on when having at least 512 megabytes of RAM. also, i'm not entirely sure that quake works exactly like doom when it comes to memory management. under DOS, it'll set higher heapsizes automatically (or up to ~64 mb, at the very least) and i found the game to be much less prone to HDD related stutters, compared to doom engine games. the latter will just use the same small heapsize regardless, unless using one of the limit-removing .exe hacks instead i guess.

i'm not sure anymore whether i used an IDE drive on the rz1000 or a SCSI setup at the time for heretic, this would be pretty relevant. the rz1000 with all the patches performs quite poorly so that would explain things. in comparison the ramdrive felt like a cartridge console-like experience in terms of instant loading and no hitching, so it made it easier to overlook the p60 already feeling slightly on the slow side for heretic (which is crazy enough as those systems would have been sold as fairly high-end machines at the time, with only 8mb of RAM as well).

Was under impression MBF would load all textures and sprites for every level into memory, and sounds are preloaded at the engine start.

Now, graphics are at PU_CACHE before getting used, so could be swapped out, but not in a set up with "lots of memory", I believe.

using MBF 2.04 (2017 build) on a pentium 200 mmx with 64 mb, no smartdrive, loading up just the stock doom2 wad, there indeed doesn't appear to be any hard drive access during gameplay, even on a bigger map like downtown. however loading a 60mb megawad in addition, it definitely loads from the HDD while in a level, even doing short accesses just during map traversal. these don't seem to be causing performance dips though, even with the hi-res mode. not 100% sure if this is DMA or PIO, but don't believe award bioses set DMA to work in pure DOS.

looking at the contents in slade, the biggest parts are the sidedefs/segs etc. data which is per level, along with the MIDIs, so if it keeps just a single level in memory one could think it should fully fit, but there is probably more to it. should look at what memory usage looks like in win95 but for now it seems 128 mb is required to not have any ingame HDD access with big megawads (and certainly recommended to use a pentium ii or later anyway as the hi-res mode gets very demanding on complex maps).

edit: having looked at this in 95b system monitor, where free memory after boot is about 49 mb (using a 4 mb vcache), when running MBF with the 60 mb megawad, it's just over 12.2 mb free ingame. it's mostly a flat line but with some minor steps in the beginning, suggesting ingame data loading (maybe graphics as suggested).

with just the doom2 IWAD, warping to map13, it's about 30 mb free. pagefile size is shown as 0 mb for either instance, and it seems there might be a bit of ingame HDD use even on the IWAD after all. so from what i'm seeing here i would say even MBF is not strictly using all available memory to precache everything into RAM, although the size of whatever data is loaded ingame must be very small. arguably the ingame loading is more noticeable in vanilla because of the blue floppy icon, which i'm not seeing in MBF.