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...