Oolite Bulletins

phkb wrote: ↑Sun May 18, 2025 12:15 pm

We'll have to press pause here while I reassess what might be possible.

I'm just going to step out for a moment.

I may be some time.

Fair enough. You gave an arm and a leg - yet we are asking for more.

Would it be ok to document what you have done so someone could take over?

I've just had another stab with oolite-1.90a2-Mac-TestRelease (downloaded 8th June).

Yes, the frame rate drops substantially when Thargoid Wars OXP unleashes its invasive hordes and merry heck breaks loose. (I'm hoping to try out the TR version and see if I can measure it - but would there be something which adds both the frame rate and the number of entities bouncing around to the latest.log?). - I've added cag's fps_monitor to my cocktail mix.

But the sound has yet to conk out early as it always does (it usually lasts for around two jumps ... or dies immediately in a Thargoid Wars-type fracas.


So there seems to be something right about it! Might there be a trade off between sound and frame rate?

Plan A was for Bogatyr to return and take over. That plan hasn’t worked out. So, plan B was for me to set up a working Mac build environment (not a hacked together VM) so that I can do proper testing myself, without having to wait 24 hours for another Mac user to try things out. With that environment set up, I’m also going to be looking at that OpenGL to Metal translation layer, to see if we can a full update working.

I’m waiting to hear back from a local friend of mine who might have a old MacBook (circa 2018) lying around I can borrow so I can avoid the approx $400-$500 price tag a second hand one still costs.

I've now been using this version solidly for a month.

1) No more infuriating problems with the sound

2) No crashes

3) The only minus is the frame rate diving - which happens when there are 600+ entities in the system and I'm in combat. But I'm also running a whole host of horrendously complex OXPs laden with timers and stuff in a mix of some 250-300 oxps.


My vote is that it is better than the old.

Cholmondely wrote: ↑Tue Jul 15, 2025 6:00 pm

My vote is that it is better than the old.

I'm hopefully close to getting a real Mac to do some proper testing. Like, in the next week. We'll have to see how it goes, though - I find everything harder to do on a Mac. (And please, before any Mac-person responds, that comment is about *me*, not the platform. I'm just too used to programming on Windows that making the jump to working in a "Mac" way makes every step take much, much longer).

I came across an Objective-C framework called ObjFW which has very wide platform support and regular updates.

"It enables you to write an application in Objective-C that will run on any platform supported by ObjFW without having to worry about differences between operating systems or various frameworks you would otherwise need if you want to be portable.

It supports all modern Objective-C features when using Clang, but is also compatible with GCC ≥ 4.6 to allow maximum portability...

ObjFW also comes with its own lightweight and extremely fast Objective-C runtime, which in real world use cases was found to be significantly faster than both GNU's and Apple's runtime".

Could replacing GNUStep with ObjFW be a path to restoring full cross platform support including old and new Apple?

The main developer of ObjFW has been helpful in answering my questions about what a port from one to the other would involve: https://git.nil.im/ObjFW/ObjFW/issues/52

Ok, here’s where I’m currently at.

I have (a) a real Mac laptop, and (b) a working build of Oolite 1.90.

To get to that point, I had to downgrade the os version from the latest to Catalina, and ended up using Xcode 10.1 to get Oolite working. I had problems with 11.3 - it would build, but crash just after the splash screen.

I had a look at trying the MGL app, but because I’m now on a really old Xcode version, it won’t even open the project. I’d need to be on probably Xcode 15, or 16 even, to get it working. But then I wouldn’t be able to build Oolite. So I’ve put that on hold for the moment. Unless another Mac user out there, who knows how to build projects in Xcode, can furnish me with the compiled version, I otherwise have no way to build it myself. Well, I guess I could put another Hackintosh vm together — I’ll think about that one.

My next steps are to try to recreate the issues previously noted around input lag and game slowdown under load, and see if I can debug where the bottlenecks are. I’ll report back with anything I discover.