WinMBF goes 64 bit (WinMBF64 aka 3.0)

[Redneckerz]

Note: This is the first in a long line of entries i will be making over the following months highlighting new, obscure or forgotten parts of our collective Doom history.

 

@fabian used to want to have WinMBF be 64-bit compatible in 2017:

And started a thread about WinMBF's future in 2012:

Enter WinMBF64.

 

Developed by Adam aka astb, WinMBF64 is a 64 bit only MiniGW build of WinMBF by Team Eternity and @Quasar. Bumped to version 3.0. No new features, just a 64 bit WinMBF. As of October 2019 astb includes the SDL libraries used in building the source port as part of the release.

 

In the authors words:

 

Quote

 

 

what works

Sound effects don't work, music does. It's playable, I took the sources from the old trunk here: http://mancubus.net/svn/hosted/winmbf/ and fixed all the errors and modified the code to be 64bit compatible and fixed some SDL_mixer segfaults.

versioning

I decided to keep the version name 'MBF' and simply bumped it to version 3.0.

building

MingW was used for building it (64bit only) with custom compiled SDL1.2 libraries. I will not be making an SDL2 version, that would be an undertaking that I'm not motivated to do. But feel free to do a pull request if you're up to the task :)
 

 

 

Works as it should on Windows 7. Ive made an edit on the associated DoomWiki page already to reflect this update which is currently ''pending changes'' considering ive just started out there.

 

Links:

Github: https://github.com/atsb/winmbf

Binary + source: https://github.com/atsb/winmbf/releases

 

Edited December 10, 2019 by Redneckerz : BBcode went a little haywire, fixed

[fabian]

Well, that's a single 4-commit code drop, but thanks anyway. I have started my own branch to achieve 64-bit compatibility meanwhile: 

https://github.com/fabiangreffrath/WinMBF/tree/64bit?files=1

[Redneckerz]

3 hours ago, fabian said:

Well, that's a single 4-commit code drop, but thanks anyway. I have started my own branch to achieve 64-bit compatibility meanwhile: 

https://github.com/fabiangreffrath/WinMBF/tree/64bit?files=1

It is what it is - Plain ol' WinMBF in 64 bit. So its atleast as pure as one would want it. Perhaps contact Adam and notify him of your work?

 

Hope that for you, and others who want to enjoy WinMBF freed from the 32 bit shackles, this is sufficient.

[fabian]

I just checked and my branch works fine with music and sound effects with stock SDL libraries.

[Redneckerz]

1 hour ago, fabian said:

I just checked and my branch works fine with music and sound effects with stock SDL libraries.

Heh, cool beans. Well, if that gets to an as-is build but with Music, then that's an interesting prospect.

 

For total confusion, call it WinMBF64 aswell with version 3.0. :P

[ReaperAA]

CrispyMBF when?

[seed]

6 hours ago, ReaperAA said:

CrispyMBF when?

 

Ya really, I've never managed to use the original WinMBF and it's pretty old now, so I'd definitely be up for something like that.

[fabian]

Next step would be to port the code over to use SDL2, but don't hold your breath. 

[seed]

1 hour ago, fabian said:

Next step would be to port the code over to use SDL2, but don't hold your breath. 

 

*heavy breathing*

[fabian]

Small status update:

The 64bit branch is making some nice progress. The only issue left seems to be that savegames saved with the 32-bit EXE could not be restored with the 64-bit EXE and vice versa - but this is probably a minor issue given that even PrBoom+ cannot do that.

The SDL2 branch is also making progress, i.e. sound and music work and the game window can be scaled at will. I still need to check stuff like mouse grabbing and fullscreen. The keyboard code needs to be more properly ported over from Chocolate Doom. Also, Alt+Enter fullscreen toggle and PNG screenshot saving are on the TODO list.

[fabian]

BTW, @Altazimuth @Quasar is there anyone paying attention to WinMBF's github repo to reply to my merge requests?

[seed]

This sounds exciting :D .

 

Can't wait for the version that implements those features from the list.

[Redneckerz]

8 hours ago, fabian said:

Small status update:

The 64bit branch is making some nice progress. The only issue left seems to be that savegames saved with the 32-bit EXE could not be restored with the 64-bit EXE and vice versa - but this is probably a minor issue given that even PrBoom+ cannot do that.

The SDL2 branch is also making progress, i.e. sound and music work and the game window can be scaled at will. I still need to check stuff like mouse grabbing and fullscreen. The keyboard code needs to be more properly ported over from Chocolate Doom. Also, Alt+Enter fullscreen toggle and PNG screenshot saving are on the TODO list.

Proper stuff. Whenever there is something build, ill make sure it gets covered on the Wiki. I'd reckon it will need some kind of distinguishment of the other port, though. Any specific name you want to attach to this?

[Graf Zahl]

19 hours ago, fabian said:

Small status update:

The 64bit branch is making some nice progress. The only issue left seems to be that savegames saved with the 32-bit EXE could not be restored with the 64-bit EXE and vice versa - but this is probably a minor issue given that even PrBoom+ cannot do that.

 

That's the inevitable result of saving data as binary blobs - the different size of pointers will block it. The question here, of course, is, how important is continued 32 bit support and interoperability with system upgrades to 64 bit to justify the added work to make this code pointer size independent? The last GZDoom survey I ran showed a mere 1.5% of all users being on a 32 bit OS, down from 3.2% a year ago.

 

[seed]

11 hours ago, Redneckerz said:

Any specific name you want to attach to this?

 

CrispyMBF :p .

 

40 minutes ago, Graf Zahl said:

how important is continued 32 bit support and interoperability with system upgrades to 64 bit to justify the added work to make this code pointer size independent? The last GZDoom survey I ran showed a mere 1.5% of all users being on a 32 bit OS, down from 3.2% a year ago.

 

Call it twisted logic if you want, but it might also depend on the user base. Something like GZDoom will inevitably be used on different systems compared to something like MBF, Chocolate, or whatever.

[fabian]

11 minutes ago, seed said:

CrispyMBF :p .

 

Though this is the obvious choice, it may raise some false expectation with regard to additional game-play features: there won't be any.

 

Is there an attribute similar to "Crispy" that is preferably used to advertise dog food? I mean, because Man's Best Friend...

[seed]

2 minutes ago, fabian said:

Though this is the obvious choice, it may raise some false expectation with regard to additional game-play features: there won't be any.

 

Oh, so there won't be any Crispy-like features after all? Interesting.

 

Perhaps that might change in the future, unless you're already dead set on the philosophy of your fork.

[Redneckerz]

1 hour ago, fabian said:

 

Though this is the obvious choice, it may raise some false expectation with regard to additional game-play features: there won't be any.

 

Is there an attribute similar to "Crispy" that is preferably used to advertise dog food? I mean, because Man's Best Friend...

This is definitely how i read that aswell. Within Doom terminology, i associate Crispy (and perhaps Strawberry) with very additional features.

 

A small list of silly suggestions:

• K9MBF/CanineMBF (Its the most loyal dog follows you to 64 bit compatibility but is vanilla WinMBF. Read as Canine, Marine's Best Friend)
• CrunchyMBF (Often dog food is advertised as such. Crunchy in this regard can refer to the SDL2 and 64 bit compatibilty that has been the extra ''body'' to regular WinMBF. Personally, i do like this variant.)
• MBFBiscuit or BiscuitMBF (Dogs like biscuits, right? The SDL2/64 bit compatibility raise can be seen as a biscuit.

[printz]

1 hour ago, fabian said:

Though this is the obvious choice, it may raise some false expectation with regard to additional game-play features: there won't be any.

Isn't "CrispyMBF" basically going to be just like PrBoom+ (but without any demo compatibility bugs fixed)? The differences will only be:

1. OPTIONS lump will be supported
2. Use the MBF blockmap reconstruction algorithm, not the Boom one like PrBoom+ does.
3. Alpha DOOM stuff to play with.

[seed]

Crispy also has higher res support vs vanilla, and some other niceties and enhancements, such as colored blood and intermediate gamma correction levels.

 

So, a "CrispyMBF" could've been very open to interpretation.

[Graf Zahl]

2 hours ago, seed said:

Call it twisted logic if you want, but it might also depend on the user base. Something like GZDoom will inevitably be used on different systems compared to something like MBF, Chocolate, or whatever.

 

You know, here's the thing. I very often see reasons like this being put forward when it comes to legacy support, as if there's this large anonymous group of users running very old hardware but having virtually no quantifiable proof for that assumption.

 

While I agree that there's surely older systems out there, and that users of such systems are forced to run software with lower specs, the overall trend is undeniable. The numbers are dropping - and dropping rapidly. 32 bit OSs have been commercially dead for 8-9 years - genuine 32 bit hardware even longer, so any system we are talking about here is getting ever closer to the age where its retirement is inevitable.

 

2 hours ago, fabian said:

Is there an attribute similar to "Crispy" that is preferably used to advertise dog food? I mean, because Man's Best Friend...

 

WoofDoom? >D

 

50 minutes ago, printz said:

• OPTIONS lump will be supported
• Use the MBF blockmap reconstruction algorithm, not the Boom one like PrBoom+ does.
• Alpha DOOM stuff to play with.

 

You are forgetting the biggest "feature": It's being actively maintained. Right now this community's biggest problem is that the major reference port is for all intents and purposes a zombie.

 

[Gez]

2 hours ago, fabian said:

Is there an attribute similar to "Crispy" that is preferably used to advertise dog food? I mean, because Man's Best Friend...

Crunchy?

[andrewj]

semi-jokingly: WinMBF+

[Redneckerz]

1 hour ago, Gez said:

Crunchy?

I like that we have the same idea here. :)

 

55 minutes ago, andrewj said:

semi-jokingly: WinMBF+

That would also do well as it would make it clear it is derived from WinMBF. But you would have to denote what the Plus stands for. If looked at PrBoom vs PrBoom-Plus, the differences are more significant than what is the case, in my opinion.

[fabian]

Thank you very much for your ideas! On the one hand, I like the "Crunchy" suggestion as a play on my main port project very much, but on the other hand, this fork will look absolutely exact like WinMBF - you won't see any difference at all (well, maybe except for one or two menu entries). After all, I'd really like to go with the WinMBF name, because that's what it actually is, but refuse to do so because this is clearly Quasar's baby. I am leaning towards something like PortableMBF, but that sounds too old-farted already...

[seed]

1 hour ago, Graf Zahl said:

You know, here's the thing. I very often see reasons like this being put forward when it comes to legacy support, as if there's this large anonymous group of users running very old hardware but having virtually no quantifiable proof for that assumption.

 

While I agree that there's surely older systems out there, and that users of such systems are forced to run software with lower specs, the overall trend is undeniable. The numbers are dropping - and dropping rapidly. 32 bit OSs have been commercially dead for 8-9 years - genuine 32 bit hardware even longer, so any system we are talking about here is getting ever closer to the age where its retirement is inevitable.

 

Oh, I don't deny what you're saying - there's still a handful of 32-bit software versions of various programs out there, but the trend is obvious, it's ever falling into irrelevance. 32-bit OSes are also more-or-less "dead" in 2019 due to their limitations (memory in particular) and whatnot.

 

My point there was to avoid treating your results as an absolute. The reasonable folks who are using old hardware and software will definitely not be using GZDoom (and the unreasonable ones will do and then complain about performance issues), so obviously those will not show up in your results because they're not part of the user base. If PrBoom, Crispy, and Chocolate had a survey system I'd be almost willing to bet the results would look quite a bit different.

 

@fabian CrunchyMBF is still the best option IMO :) .

[Redneckerz]

8 minutes ago, fabian said:

Thank you very much for your ideas! On the one hand, I like the "Crunchy" suggestion as a play on my main port project very much, but on the other hand, this fork will look absolutely exact like WinMBF - you won't see any difference at all (well, maybe except for one or two menu entries). After all, I'd really like to go with the WinMBF name, because that's what it actually is, but refuse to do so because this is clearly Quasar's baby. I am leaning towards something like PortableMBF, but that sounds too old-farted already...

As a variation Crunchy would do well. But if you want to keep with the WinMBF naming scheme, then @andrewj's suggestion is more apt.

 

Or WinMBF XL? After all, you raise the limits to 64 bit, thus making it xtra large.  I doubt anyone is going to associate that name with added bloat as that makes little sense in a source port naming scheme.

 

PortableMBF would imply it is directly installable on portable drives and leaves no traces on the host system. Unless your port does that, but it does sound a bit old :P

[Gez]

25 minutes ago, fabian said:

After all, I'd really like to go with the WinMBF name, because that's what it actually is

Doesn't it also run on Linux?

 

You could also call it MBF64 I guess, if you really hate CrunchyMBF.

[fabian]

30 minutes ago, Gez said:

Doesn't it also run on Linux?

 

Sure it does!

 

30 minutes ago, Gez said:

You could also call it MBF64 I guess, if you really hate CrunchyMBF.

 

That's already how this other guy called his fork. :/

[Gez]

MBF21, then. For 21st century.