I don't mess with brew, I have built my own prefix for the snapshots I do and if I need other things I'm more comfortable with MacPorts.

Well, from what I've seen recently, MacPorts seem to be better and have more resources than brew, apparently. Maybe I can switch to them for my next Mac just to see if it would be better for me.

What I like from brew is exactly how quick and easy it is, and how customizable the formulas are.

Dominus wrote on 2021-07-17, 18:47:

I just checked Brew and it is missing this vital SDL12 commit: https://github.com/libsdl-org/SDL-1.2/commit/ … cdac2636c82ff5f
Totally forgot that this was fixed due to my reporting 😀

So that's the holy grail at last. And with this I guess I can play 3Dfx DOS games in windowed with Voodoo chip emulation. 😁

Bruninho wrote on 2021-07-17, 20:09:

Well, from what I've seen recently, MacPorts seem to be better and have more resources than brew, apparently. Maybe I can switch to them for my next Mac just to see if it would be better for me.

What I like from brew is exactly how quick and easy it is, and how customizable the formulas are.

There is really not much difference between both. Fast to install and the port files of MacPorts are as easy as the brew formulas, maybe even easier.
I like the clean way of MacPorts by not plluting usr/local but it's mostly a philosophical question and for most end uses that doesn't matter much.
If you are used to brew just stick with it 🤷‍♂️

kjliew wrote on 2021-07-17, 20:29:

Dominus wrote on 2021-07-17, 18:47:

I just checked Brew and it is missing this vital SDL12 commit: https://github.com/libsdl-org/SDL-1.2/commit/ … cdac2636c82ff5f
Totally forgot that this was fixed due to my reporting 😀

So that's the holy grail at last. And with this I guess I can play 3Dfx DOS games in windowed with Voodoo chip emulation. 😁

Perhaps. I really really just forgot about this completely, even when you asked me about the display problem a couple of weeks ago.
Bug reported, tried the fix, it got added and then forgot...

Dominus wrote on 2021-07-17, 21:19:

There is really not much difference between both. Fast to install and the port files of MacPorts are as easy as the brew formula […]
Show full quote

Bruninho wrote on 2021-07-17, 20:09:

Well, from what I've seen recently, MacPorts seem to be better and have more resources than brew, apparently. Maybe I can switch to them for my next Mac just to see if it would be better for me.

What I like from brew is exactly how quick and easy it is, and how customizable the formulas are.

There is really not much difference between both. Fast to install and the port files of MacPorts are as easy as the brew formulas, maybe even easier.
I like the clean way of MacPorts by not plluting usr/local but it's mostly a philosophical question and for most end uses that doesn't matter much.
If you are used to brew just stick with it 🤷‍♂️

Yeah, you're right. However, I think I can understand why it's on /usr/local (which other place it should be in your opinion?). Since Catalina, the system is read-only, I cannot even mess with /usr/bin even if I had disabled SIP. Apple being Apple, as usual.
How about /opt instead of /usr ?

MacPorts uses /opt/local to be as less disruptive as possible. Using /usr/local is as disruptive as possible these days. All kind of things will pick up libraries there and that is not always desirable, as well as other software trying to store their stuff there.
That's why I like MacPorts more, it's self contained and won't interfere unless I need it to (though stuff breaks if other software hardcodes their search paths to /opt/local - I'm looking disapprovingly at CMake)

Dominus wrote on 2021-07-17, 21:55:

MacPorts uses /opt/local to be as less disruptive as possible. Using /usr/local is as disruptive as possible these days. All kind of things will pick up libraries there and that is not always desirable, as well as other software trying to store their stuff there.
That's why I like MacPorts more, it's self contained and won't interfere unless I need it to (though stuff breaks if other software hardcodes their search paths to /opt/local - I'm looking disapprovingly at CMake)

I like that concept. That's why I looked around for MacPorts. I have never used it. I just used brew because - it's what I had for my web development on Mac when I was a frontend developer until last year.

I am used to brew, but sometimes I feel I am being limited by it when some projects documentation mentions MacPorts to get this or that to build their binaries. Might as well try it on M1 next year.

@Dominus, can you also help reporting the bug to HomeBrew for the next SDL bottle to include the fix?

Perhaps you can also do it for MacPort. The libsdl Portfile from MacPort is even more pristine than HomeBrew. Or maybe MacPort simply prefer "SDL1.2 must die!" 🤣.

It actually should die. When I issue a brew doctor, after having it installed, it says sdl 1.2 is deprecated 🤣

Now, Kekko's Voodoo chip emulation plays in windowed, 640x480 or 800x600 will be fine.
Battle Arena Toshinden 3Dfx Ver 2.5 PC Retail

How about the Tale of Two Lara's? 😁

Try the same position and view angle as the in the screenshot on your choice of PC emulators. Maximize the quality with anti-aliasing with 'F3' key. This is a simple performance measurement to max out the field of depth with dense objects scene, a typical stress for any emulators without CPU virtualization. If the PC emulator of one's choice could sustain 30 fps, then it is a high performance emulator, especially if it could be done on mobile CPUs.

The MacBook Air M1 could not only have one but two, both at 30 fps side by side simultaneously. Hey, another performance demonstration, 🤣 not again!

Amazing... I couldn't tell the difference.

Sadly, the 3rd one is MIA. 🤣 Otherwise, it would show off the so-called true & authentic 3Dfx Voodoo rendering with 16-bit dithering, 2x2 filtering and all the accuracy goodies and "freaking fast". 😉

kjliew wrote on 2021-07-18, 06:10:

Sadly, the 3rd one is MIA. 🤣 Otherwise, it would show off the so-called true & authentic 3Dfx Voodoo rendering with 16-bit dithering, 2x2 filtering and all the accuracy goodies and "freaking fast". 😉

https://github.com/sarah-walker-pcem/pcem

Works with M1 Macs now, btw.

kjliew wrote on 2021-07-17, 22:39:

@Dominus, can you also help reporting the bug to HomeBrew for the next SDL bottle to include the fix?

Perhaps you can also do it for MacPort. The libsdl Portfile from MacPort is even more pristine than HomeBrew. Or maybe MacPort simply prefer "SDL1.2 must die!" 🤣.

No! 😉
Getting a port/formula approved is not fun. Doing it for something like SDL1.2 that has no new version... hard pass...

Dominus wrote on 2021-07-18, 07:52:

No! 😉
Getting a port/formula approved is not fun. Doing it for something like SDL1.2 that has no new version... hard pass...

Not a problem, I knew what kind of position that could be. So how did you do the macOS DMG type of DOSBox distribution? Static linking the SDL or always include the spiced up SDL dylib?

I used to static link but this year I started adding the dylibs for each arch in the app bundle. One reason was that I played around with the SDL12compat lib and for that it needs dylibs. Also I'm doing snapshots for Exult and Exult Studio. ES is a GTK+ app and that is not possible to distribute with static libs.
AND it doesn't need patching the makefiles which just breaks when you add another lib (or in the case of Exult configure shenanigans)

Wait a minute, look like the SDL fix is not the holy grail after all. It just has the display scaled up without taking mouse motion into consideration *in windowed mode*. A good DOS game that will manifest this issue is Dune 2: Building of a Dynasty. Try to play it in windowed, use scaler=normal3x or windowresolution=something on real display with display scaling. If SDL1.2 switched to fullscreen, then macOS would be managing the display scaling and mouse motion at the same time so that relieved the apps from such tedious handling. My OpenGL fix does not have the problem because the display matches SDL1.2 mouse motion at real screen pixels. So pick your camp, DOS games with mouse in fullscreen or 3Dfx DOS games in fullscreen.

SDL1.2 with matching display and mouse motion at real screen pixels is more consistent with other platform such as Windows and Linux. I had reported Windows 10 display scaling mouse issue in the past and I think they are the same. I think SDL2 solved the problem with internal mouse warping, otherwise mouse motion would be completely screwed up with borderless fake fullscreen. This is going to be nasty, having DOSBox manage mouse warping is very ugly, but SDL1.2 seems to be a dead end. *sigh*

IMO, my OpenGL fix is better if the hardcoded scaling value can be obtained programmatically.

Can you elaborate how that problem manifests itself? I don't quite understand...

IMO, my OpenGL fix is better if the hardcoded scaling value can be obtained programmatically.

but it's already in SDL git so this needs to be fixed instead of doing it per program, IMO. Maybe voice in in the bug report https://github.com/libsdl-org/SDL-1.2/issues/839 ?

If you are interested my elaborate buildbot scripts are at https://github.com/DominusExult/buildbot. I use this on my MacMini M1 to build snapshots for DOSBox and Exult, interestingly I'm still able to build for ppc on the M1 😀
I know it looks messy with the scripts included but this evolved over the last couple of years and works best like this for my little setup.
I still need to build the latest SDL12compat source to make this available in a working setup 😀