Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

Current state and future of WinMBF?

Recommended Posts

Hi all,

I am a newbie to the Doom community and just recently found out about the WinMBF source port. Technically, it is the source port that I was always dreaming of: It is as close to the original as possible, has a high-res renderer (640x480, that is) and supports all Boom features, so I can play Freedoom with it. To me, it closes the gap between Chocolate Doom and PrBoom{-plus}. Thank you very much, Team Eternity, for your great work so far!

Unfortunately, it seems that its development has stalled since mid-2010, just before its designated final release. I have checked out the latest SVN trunk and it compiles flawlessly with Visual Studio and with some tricks even with MinGW and on Linux - all 32-bit, that is. However, the world is going 64-bit, especially in the Linux ecosystem, and that's where the port really needs some love. At least my attempts to make it run in 64-bit Linux have failed so far.

What I want is to bring this brilliant source port back to live, sort out its portability issues and bring it to its (final?) release. Furthermore, I'd like to add some minimal non-intrusive features like auto-detection of the Freedoom Iwad or the Doom3-BFG Iwads.

Is there anyone out there who has some experience or interest in this source port and would like to help out with some patches?

Best regards,

- Fabian

Share this post


Link to post

Am already overloaded with projects so cannot take on another, but can give you info.

DoomLegacy already did the fixes for making Doom source compile on 64 bit machines. You can download the DoomLegacy source and compare the wad data structures to see how it is done.

The problem is that short and int in the original source are used to mean 16 bit and 32 bit fields in the wad file. Compiling with a 64 bit machine makes short a 32 bit field and int a 64 bit field, makes the wad structure size and field alignment wrong, and when used to read a wad gets wrong data.

The data structures in Doom must be changed to be 16 bit and 32 bit fields for all compilers.
This is done using stdint, which tests the machine size and selects a type that gives the specified size. Some ports do the same determinations in their own header files.

1. #include <stdint.h>
2. In wad handling structures, change uses of "short" to int16_t
3. In wad handling structures, change uses of "int" to int32_t
4. There are some exceptions to the above general rules, and the best way to find them is to look at the DoomLegacy source.
5. Many fields become uint32_t in order to use a larger unsigned range.
But some must remain int32_t because a -1 was used to mark unused fields. Once the tests to detect the -1 are changed to be unsigned, then uint32_t can be used. This also fixes some field range overflows from overly-large wads.

Using val as an example:
--- int val;
--- if( val < 0 )

+++ // detect -1 value in wad
+++ #define VAL_UNUSED 0xFFFFFFFF
+++ uint32_t val;
+++ if( val == VAL_UNUSED )

Do the same for fields using short, but substitute uint16_t and 0xFFFF instead.

DoomLegacy source has comments that explain the choices better than I can remember. Other ports will have similar fixes, but Chocolate Doom, DoomLegacy, and prboom will be closer to the original than most others.

BTW: Doom compiled as a 64 bit program probably will run slower than if it is compiled as a 32 bit program. This is because so much of the data is 16 bit and 32 bit lengths, that compiled as 64 bit it must make extensive use of instruction prefixes to access wad data.
The only solution for this is to convert all the wad contents to 64 bit data fields (kept in a new internal data structure) upon reading the wad, and waste the memory. But then processor cache will only hold half as many wad structures, which forces more main memory fetches, which also slows the program execution.
If it affected video rendering it would be serious, but it doesn't.
It just does not give you any gain in performance.
I just prefer to keep compiling doom as a 32 bit program, which switches the hardware to 32 bit instruction set default memory accesses.

Share this post


Link to post

Dear Wesley,

thank you very much for your reply.

Honestly, I don't think that the wad data structures will be the worst cause of trouble. That is, it seems they are already fixed in this port.
Instead, it is the handling of config data in m_misc.{c,h} that causes trouble, especially the casting back and forth between integer and pointer in the default_t struct and related code.

- Fabian

Share this post


Link to post

I was working on bug fixes for MBF but as I'm learning coding as I go along I'm using mostly the fixes noted down in PrBoom's page and have the 3 key card bug working that Fraggle provided a fix for, along with other fixes.

Share this post


Link to post

I am afraid the amount of effort and style of changes that would be required to make it 64-bit clean are beyond the original scope of the project.

Such an effort was already undertaken for Eternity, and required modifications to level reading, save game reading/writing, network data transmission, and demo reading, as well as massive modification source-wide to use ISO C99 fixed-size types anywhere it matters, instead of DOS-style assumptions about short/int/long. It is also necessary to do significant cleansing of code segments which coerce pointers to integers, and make a sweep for sizeof() expressions which are hard-coded instead of taking a known-size type as their argument. Some code must also additionally be rewritten to avoid confusion/coercion between int/long/size_t/ptrdiff_t.

If someone is interested and can produce a patch for 64-bit compatibility which can maintain 100% demo compatibility, I'd be happy to apply it to the repo though.

As far as actual bug fixes, those would have to be done in a forked project or a branch, as the original project is meant to just be a literal port of WinMBF and not include compatibility-affecting fixes or new features beyond the minimum necessary to comfortably run the game in windowed OSes.

Share this post


Link to post
Quasar said:

as the original project is meant to just be a literal port of WinMBF and not include compatibility-affecting fixes or new features beyond the minimum necessary to comfortably run the game in windowed OSes.

And for that purpose, there already is DOSBox.

Share this post


Link to post
Quasar said:

If someone is interested and can produce a patch for 64-bit compatibility which can maintain 100% demo compatibility, I'd be happy to apply it to the repo though.


AFAIUI, most of the low-level code of MBF has already been replaced by implementations from the Eternity Engine, so why not merge also the other code affecting portability?

That said, I do not yet have a patch to make WinMBF 64-bit compatible. But I have one to make it compile on MinGW32 (and a Makefile), if you are insterested?

As far as actual bug fixes, those would have to be done in a forked project or a branch, as the original project is meant to just be a literal port of WinMBF and not include compatibility-affecting fixes or new features beyond the minimum necessary to comfortably run the game in windowed OSes.


I agree here.

While I believe that the most obvious bugs should get fixed, this should get done through compatibility options, which are, in turn, out of the scope of WinMBF.

Share this post


Link to post
fraggle said:

Oh of course I forgot about Shake My Marine Up (I think that's what it's called). I wanted to add more than just bug fixes though such as an internal browser and strife compatibility with the hexen features it's missing. EDIT: I'm a right diddy doughnut Smack My Marine Up has nothing to do with it. Anyway thanks for the link Fraggle.

Share this post


Link to post
Quasar said:

If someone is interested and can produce a patch for 64-bit compatibility which can maintain 100% demo compatibility, I'd be happy to apply it to the repo though.


Well, today I hacked up this patch, which allows me to compile and run WinMBF on an AMD64 under Debian unstable (amd64 distro, of course):
http://greffrath.com/~fabian/winmbf-64bit-WIP1.patch
You might also be interested in this Makefile to compile under Linux:
http://greffrath.com/~fabian/winmbf_Makefile

The main issue was the handling of the configuration data, i.e. that both (int) values and (char *) pointers were stored in an (int) variable. Many of the other fixes aren't 64bit-specific at all and are merely needed to compile on !win32-systems.

I tested playing, changing options (both ints and strings), resetting options, saving and loading games. I did not test advanced features like network play, demo compatibility, etc. but since my patch does not even remotely touch code related to this, I am confident that it remains completely unaffected.

Please tell me what you think about it!

- Fabian

Share this post


Link to post

I'd love to see a fully portable MBF. WinMBF is currently coded for Windows MSVC and needs tweaks to recognize all functions.

How does full screen WinMBF run for any of you? I keep having various stability problems with it.

Share this post


Link to post
printz said:

I'd love to see a fully portable MBF. WinMBF is currently coded for Windows MSVC and needs tweaks to recognize all functions.

It is not strictly limited to MSVC. With the Makefile I posted above it does also compile with MinGW. But then some structs are not aligned correctly and the game won't start. The following patch fixes this, it has to be applied on top of the one I posted before:
http://greffrath.com/~fabian/winmbf_mingw32.patch

I have not yet tested it with mingw-w64, though.

Share this post


Link to post

For all those still interested, I have created a Debian package for winmbf that compiles and runs on both i386 and amd64 (not yet tested on kfreebsd and hurd, though). I have applied a series of patches that can be found here:
http://anonscm.debian.org/gitweb/?p=pkg-games/winmbf.git;a=tree;f=debian/patches;hb=HEAD

Some of them, especially portability-64bit.patch, could probably need some review and clean up. So, please, share your comments.

- Fabian

Share this post


Link to post
printz said:

So, they're patches designed to be applied with Git?


Well, they are stored in GIT. During the creation of the Debian package they are automatically applied via quilt which, in turn, uses the patch command.

Share this post


Link to post

Hm, I must say, I am really astonished by the apparent lack of interest in this promising port. :(

Quasar, may I ask you what keeps you from releasing the long-announced r3 version of that port? It's a shame there are so many important changes in SVN that are not yet made available to a wide audience.

Share this post


Link to post
fabian said:

Hm, I must say, I am really astonished by the apparent lack of interest in this promising port. :(

Quasar, may I ask you what keeps you from releasing the long-announced r3 version of that port? It's a shame there are so many important changes in SVN that are not yet made available to a wide audience.

I've just been really busy. Is there a chance you can put your patch back up? I may see to getting it applied and doing a new release sometime soon.

Share this post


Link to post

Quasar, I realise you are very busy but each of these patches is very self-contained and quite small, so I wonder if you may have a chance to look at one or two at a time, over a period?

Share this post


Link to post
Jon said:

Quasar, I realise you are very busy but each of these patches is very self-contained and quite small, so I wonder if you may have a chance to look at one or two at a time, over a period?

Yeah, I'll look into doing this after the next EE release which is coming up real soon (once I get XBox 360 controller supported coded into it).

Share this post


Link to post

Even if you decide not to apply any of the patches

  • , I believe you should at least release the current state in SVN to the public. It contains so many features that clearly add value over the current 2.03 Build 2 release, e.g. video scaling and aspect ration fixing.

  • Though I believe you should at least apply crash-videomode.patch, which fixes a crash introduced by the WinMBF change set. The other crash-*, security-* and portability-* patches are minimal-intrusive and could turn out interesting as well.

  • Share this post


    Link to post
    fabian said:

    Even if you decide not to apply any of the patches

  • , I believe you should at least release the current state in SVN to the public. It contains so many features that clearly add value over the current 2.03 Build 2 release, e.g. video scaling and aspect ration fixing.

  • Though I believe you should at least apply crash-videomode.patch, which fixes a crash introduced by the WinMBF change set. The other crash-*, security-* and portability-* patches are minimal-intrusive and could turn out interesting as well.

  • Now that EE 3.40.37 is finally out I'll see about this here soon.

    Share this post


    Link to post

    I promise this is the last time I try to convince you to release a new version of WinMBF based on the code currently in SVN before this thread goes down to older-than-3-months-hell.

    Share this post


    Link to post

    I'm just so busy it's difficult to fit time for this into my schedule. I sort of wish someone else could take over or at least help with development on the project.

    Just the fact it still wants to build with Visual C++ 6.0 is a huge obstacle to me getting the momentum to start working on it again. That needs to be updated, at least to VC++ 2008.

    Share this post


    Link to post

    I have a fork of WinMBF that has many cross-platform bugfixes (it is NOT 64-bit clean yet though), ENDOOM support, and a CMake build system instead of a single project file for a 15-year old compiler.

    I believe I actually applied a patch or two of yours already. Further pull requests are welcome. If you would like to coordinate a release, we can do that, but I'd probably have to change the name to something that's not "WinMBF" since that's Quasar's baby.

    github.com/alexmax/winmbf

    Share this post


    Link to post
    AlexMax said:

    I have a fork of WinMBF that has many cross-platform bugfixes (it is NOT 64-bit clean yet though), ENDOOM support, and a CMake build system instead of a single project file for a 15-year old compiler.


    I believe I have stumbled upon your fork before, but paid no more attention, since it was lacking the missing bit that I was looking for: 64-bit cleanness.

    Regarding the build system, I have just switched my patch set to autotools, which I prefer over CMake for simplicity (and seeing how many of your recent commit merely touch the build system, I feel right in this regard):

    http://anonscm.debian.org/gitweb/?p=pkg-games/winmbf.git;a=blob;f=debian/patches/portability-autotools.patch;hb=HEAD

    I believe I actually applied a patch or two of yours already. Further pull requests are welcome. If you would like to coordinate a release, we can do that, but I'd probably have to change the name to something that's not "WinMBF" since that's Quasar's baby.

    github.com/alexmax/winmbf


    Yes, the name should definitely get changed. First, I was thinking about chocolate-mbf, but then chocolate-* is Fraggle's baby. My current idea is MBFree, since my version removes most of the text graphics that were derived from id's artwork and replaces them by renderings in the internal small font.

    However, I am not sure how much sense a common release or even code base makes. Apart from CMake (which I don't like) and ENDOOM support (which is of low priority for me) I don't see anything else that your fork adds (this is in no way intended as an offense!). Or am I mising something?

    Share this post


    Link to post
    fabian said:

    Regarding the build system, I have just switched my patch set to autotools, which I prefer over CMake for simplicity (and seeing how many of your recent commit merely touch the build system, I feel right in this regard):



    Keep in mind, though, that this way you are pretty much throwing Windows support out of the window (heh!)

    The main reason people use CMake is that it runs equally well on all the major OSs and can produce more output configurations (like, for example MSVC project files or even projects for many Linux IDEs.)

    As a mainly Windows developer, whenever I come across an autotools-configured project I can pretty much forget about compiling it myself and have to look for third-party suppliers who made a working binary. With CMake I can quickly generate an at least semi-working project file for any of the compilers I use and finish from there.

    (Just had to throw this in as a response to using arcane non-cross-platform compatible solutions. That may be viable for you, but certainly not for many public projects.)

    Share this post


    Link to post
    Graf Zahl said:

    Keep in mind, though, that this way you are pretty much throwing Windows support out of the window (heh!)

    It works flawlessly with MinGW. Visual Studio != Windows.

    Share this post


    Link to post
    fabian said:

    It works flawlessly with MinGW. Visual Studio != Windows.



    MinGW doesn't help at all if you want to integrate stuff into existing projects in some way.

    Also define 'flawlessly'! I never *EVER* managed to get a working binary out of an autotools config. The reason: It only works if you don't have to put any deeper thought into making it work. No problem on Linux, big problem on Windows. With CMake it's simple. When that is installed it will work. Period.

    Also, didn't you read my remark about Linux IDEs?
    autotools can only do one thing well: Making makefiles. What if you don't want a makefile for whatever reason?

    No, sorry. If you want to work cross-platform, use tools that are truly cross platform and can target each platform optimally! If you want to stick to Linux (or GCC in that matter), don't bother - but then it's not really cross-platform.

    Share this post


    Link to post

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    ×