WinMBF goes 64 bit (WinMBF64 aka 3.0)

[Redneckerz]

6 minutes ago, TheWolfman00001 said:

Will this port of WinMBF be receiving support for sound effects any time soon?

You aren't referring to @fabian's build, right?

 

Because as far as i am aware, WinMBF64 (The one not by Fabian) does not have it, and i would go with what the ''building'' part says on the github page:

 

''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 :)'' emphasis mine.

[TheWolfman00001]

45 minutes ago, fabian said:

What do you mean by sound effects? 

I mean the current port of WinMBF64 posted in this forum doesn't have sound effects in it, will sound effects be added in a future update? (if it is still being worked on). In other words, the port by redneckerz

Edited December 28, 2019 by TheWolfman00001

[seed]

1 minute ago, TheWolfman00001 said:

I mean the current port of WinMBF64 posted in this forum doesn't have sound effects in it, will sound effects be added in a future update? (if it is still being worked on). In other words, the port by redneckerz

 

That's already in place, music and sfx work fine in fabian's fork, which is due to receive more quality-of-life improvements too, such as improved mouse support (because it's janky as hell currently).

[TheWolfman00001]

1 minute ago, seed said:

 

That's already in place, music and sfx work fine in fabian's fork, which is due to receive more quality-of-life improvements too, such as improved mouse support (because it's janky as hell currently).

That sounds pretty good, especially since that's the one I recently downloaded because I heard that it had successfully implemented sound effects. Unfortunately though I am not exactly sure how to get it working since it doesn't come with an EXE or anything, just with a couple of files in the main directory of the folder and a bunch of other files that I am assuming are used in the general database of the source port in order to run it effectively.

[seed]

25 minutes ago, TheWolfman00001 said:

That sounds pretty good, especially since that's the one I recently downloaded because I heard that it had successfully implemented sound effects. Unfortunately though I am not exactly sure how to get it working since it doesn't come with an EXE or anything, just with a couple of files in the main directory of the folder and a bunch of other files that I am assuming are used in the general database of the source port in order to run it effectively.

 

There literally is a winmbf.exe included with them.

[TheWolfman00001]

3 minutes ago, seed said:

 

There literally is a winmbf.exe included with them.

Yes, there is one with redneckerz's port, but there isn't with fabian's, are you saying that I have to add the files from fabian's WinMBF to the WinMBF from redneckerz?

[seed]

On 12/20/2019 at 2:02 PM, fabian said:

First 64-bit test build with SDL2, Alt+Enter fullscreen toggle, PNG screenshots, etc., bundled with a lot of 64-bit DLLs:

 

Yes, it's still called "winmbf"...

winmbf64_FG20191220.zip

 

@TheWolfman00001 Check here... you've got everything you'll ever need inside.

Edited December 28, 2019 by seed

[TheWolfman00001]

4 minutes ago, seed said:

 

@TheWolfman00001 Check here... you've got everything you'll ever need inside.

Oh my god... I didn't even notice this, I am so sorry D: (I was downloading fabian's fork using the link that he posted below the main post, which was a github build. ooooof)

Edited December 28, 2019 by TheWolfman00001

[Redneckerz]

14 hours ago, TheWolfman00001 said:

Yes, there is one with redneckerz's port, but there isn't with fabian's, are you saying that I have to add the files from fabian's WinMBF to the WinMBF from redneckerz?

Yeah this isn't mine port :) I just gave someone else's port a thread and a entry on the wiki because i remembered from various threads that people wanted a 64-bit WinMBF. And this guy made one, so...

 

Fabian's port is more complete however, so if a proper name for his port will be made, i can reference it on the Wiki.

[maxmanium]

20 hours ago, seed said:

 

That's already in place, music and sfx work fine in fabian's fork, which is due to receive more quality-of-life improvements too, such as improved mouse support (because it's janky as hell currently).

 

I wonder what causes the janky movement? I notice it too.

[seed]

8 minutes ago, maxmanium said:

I wonder what causes the janky movement? I notice it too.

 

It's very easy to notice too - turning around is way too slow, and yet, aiming is too fast and difficult. VSync also seems to be worse than usual, probably due to a dated or poor implementation of it.

 

I think we could take a look at Eternity's code to understand what's happening with the mouse. Eternity also suffers from that issue to an extent (probably inherited from MBF), but they added an option called "Smooth Turning" quite a while ago, which corrects the behavior and makes it feel just like the rest of the ports - the way it should be.

Edited December 29, 2019 by seed

[maxmanium]

1 minute ago, seed said:

 

It's very easy to notice too - turning around is way too slow, and yet, aiming is too fast and difficult. VSync also seems to be worse than usual too, probably due to a dated implementation of it or something along these lines.

 

I think we could take a look at Eternity's code to understand what's happening with the mouse. Eternity also suffers from that issue (probably inherited from MBF), but they added an option called "Smooth Turning" quite a while ago, which corrects the behavior and makes it feel just like the rest of the ports - the way it should be.

 

Interesting, I never noticed any issues with the mouse controls in Eternity -- granted, I don't use it much. Still, what causes this discrepancy?

[ketmar]

15 hours ago, seed said:

VSync also seems to be worse than usual, probably due to a dated or poor implementation of it.

tbh, there is only one way to "implement vsync": tell videodriver that it should synchronize "swap buffers" API call with vertical blank time. ok, i lied, there is another way, so-called "adaptive vsync", which basically means "wait for vblank, but only if previous vblank wasn't missed".

 

now, various "quality enhancing options" comes into play. like, drivers sometimes are pretty sure that triple buffering is the best thing humans invented after flushing toilet, and enforcing it. which is barely noticeable with 60-120 FPS game, but The Complete Disaster with 35 FPS game.

 

i really wish driver developers stop doing what they think will be good, and start doing what we're asking them to do. exactly, by letter.

 

p.s.: sorry for the rant. i had a great pleasure to caught intel driver lying (again) recently, so i am stll upset.

Edited December 30, 2019 by ketmar

[Graf Zahl]

2 hours ago, ketmar said:

tbh, there is only one way to "implement vsync": tell videodriver that it should synchronize "swap buffers" API call with vertical blank time. ok, i lied, there is another way, so-called "adaptive vsync", which basically means "wait for vblank, but only if previous vblank wasn't missed".

 

 

There really should be a third option, i.e. "wait for vblank, bu only if previous vblank wasn't missed, otherwise delay display of the new frame until next vblank, but only if in the mean time no other has arrived.", i.e. adaptive vsync with no tearing. IMO that's the only good way that display buffering should be implemented. Adaptive VSync is crap once it kicks in.

 

 

[ketmar]

(sidenote: i could never undertood that hatred towards tearing, tho. let all gods bless the tearing, because without it i (almost) have motion sickness. no jokes.)

Edited December 30, 2019 by ketmar

[seed]

19 minutes ago, ketmar said:

(sidenote: i could never undertood that hatred towards tearing, tho. let all gods bless the tearing, because without it i (almost) have motion sickness. no jokes.)

 

Well, it's ugly (also uncapped fps means more stress on the hardware).

 

Thankfully I am not allergic to it either, growing up with a potato that could barely go past 60 in... anything, so I just never had to use it. In retrospect that's a good thing since it would've meant I had to use VSync in all ports and games - and god damn it, most SDL-based Doom ports suffer from input lag with it AND uncapped framerate. I could always cap it, sure (input lag is not there when capped), but still...

Edited December 30, 2019 by seed

[Graf Zahl]

18 minutes ago, ketmar said:

(sidenote: i could never undertood that hatred towards tearing, tho. let all gods bless the tearing, because without it i (almost) have motion sickness. no jokes.)

 

Perception differs between people. For you it may be irrelevant, for me it's like someone's literally tearing apart a piece of paper right in front of my eyes.

[ketmar]

sure. i should make myself clear: i'm not saying that vsync is not necessary, just that i wasn't able to made it work flawlessly even in my own software on my hardware. the fun fact is that i, for my whole life, always had tearing, with or without vsync, on OSes starting from WinXP, and up to my current GNU/Linux, with different GPUs. that is, that feature somehow never worked for me. dunno why. no matter how hard i tried, the tearing was always there. sometimes it was barely noticeable, but... i guess i just so used to it that i cannot live without it now. ;-)

Edited December 30, 2019 by ketmar

[seed]

2 hours ago, ketmar said:

sure. i should make myself clear: i'm not saying that vsync is not necessary, just that i wasn't able to made it work flawlessly even in my own software on my hardware. the fun fact is that i, for my whole life, always had tearing, with or without vsync, on OSes starting from WinXP, and up to my current GNU/Linux, with different GPUs. that is, that feature somehow never worked for me. dunno why. no matter how hard i tried, the tearing was always there. sometimes it was barely noticeable, but... i guess i just so used to it that i cannot live without it now. ;-)

 

Try a 200hz screen instead :D .

[fabian]

Mouse movement should be fine now, i.e. identical to Chocolate Doom because it uses the same code now. Unfortunately, I don't have a chance to provide a test build currently, but maybe someone else has?

[seed]

2 hours ago, fabian said:

Mouse movement should be fine now, i.e. identical to Chocolate Doom because it uses the same code now. Unfortunately, I don't have a chance to provide a test build currently, but maybe someone else has?

 

More like a random question but, have you settled on an icon in the meantime? First build used just the... well default .exe icon of the OS.

Edited December 31, 2019 by seed

[Redneckerz]

@fabian Have you settled on a name for your MBF fork yet?

[fabian]

9 hours ago, Redneckerz said:

@fabian Have you settled on a name for your MBF fork yet?

 

I'll probably go with Woof.

 

WTF you ask?! Well, if you turn the Doom logo upside down it reads "Wood" - which is a pretty stupid name for a source port. "Woof" is another stupid name for a source port, but at least it contains a reference to dogs - and dogs are the Marine's Best Friend. ;-)

[drfrag]

I don't think that's a good idea, why not just MBFx64?

[Redneckerz]

4 hours ago, fabian said:

 

I'll probably go with Woof.

 

WTF you ask?! Well, if you turn the Doom logo upside down it reads "Wood" - which is a pretty stupid name for a source port. "Woof" is another stupid name for a source port, but at least it contains a reference to dogs - and dogs are the Marine's Best Friend. ;-)

WinMBF/Woof, it does sound similar, but i reckon that for such a significant name change, some significant features have to be in aswell.
 

49 minutes ago, drfrag said:

I don't think that's a good idea, why not just MBFx64?

That sounds rather stale in my ears and it does not reference WinMBF. At this point i also do not know how much newstuff Fabian port adds over either ole WinMBF of WinMBF64.

[Gez]

MBF's Bacon Fork, abbreviated to MBF.

[drfrag]

Why stale? Isn't WinMBF64 so? or MBF itself?

It's MBF, it's for x64 and it's not a windows only port.

[Redneckerz]

5 minutes ago, drfrag said:

Why stale? Isn't WinMBF64 so? or MBF itself?

It's MBF, it's for x64 and it's not a windows only port.

Because AFAIK Fabian's port contains more features than WinMBF64. Calling it MBFx64 can work, but relative to the amount of features added, you may want something with more... spice? :P

 

Reading back i have seen you mentioned this before in the thread along with making it analogus to MBF 2.04 from VOGONS. Since i recently documented that work and its dozen or so sub-versions, this is rather why i believe a slightly different name is needed.

 

But ultimately that's up to Fabian ofcourse. It does not matter much for me regardless, his stub at the Doomwiki needs some work anyways which i will get by sooner or later.

[SiFi270]

Woof also works because it brings Woof3D to mind, a Wolfenstein mod where you befriend the very same dogs that MBF introduced to Doom.

[Gez]

Fabian's Big Mod, or FBM.