ewmailing

Star Control 2 (which takes many Starflight influences and also hired Greg Johnson) also used a lot of procedural generation. It has around 500 stars and 4000 worlds with minerals and lifeforms. I recall the SC2 lead programmer Fred Ford saying they used a fixed seed, and they went through many seeds until they found one that looked good. I presume Starflight was of the same mindset.

It goes beyond drawing inspiration. Greg Johnson, designer of Starflight, worked directly on Star Control 2.

LuaCocoa author here.

While the objc_msgSend, objc_msgSend_stret, et. al, is an annoying detail, that isn't really the hard part. (And in fact, all the good bridges use libffi to do more direct invocations and avoids a lot of this problem.)

The hard part of bridging is those places where Objective-C introspection is not powerful enough to discover the types of parameters or signatures of functions. Typically, this is all the C stuff.

So for example, Obj-C's runtime introspection cannot tell you the make up of a struct. So it cannot tell you the size of NSRect, NSPoint, NSSize, or the individual data types inside the struct (and the names of each item if you need to access them).

And the Obj-C runtime introspection cannot tell you about what C functions exist and what the parameter types and return types are. So for example, there is no Obj-C runtime way to look up that CGPointMake takes two CGFloat parameters and returns a CGPoint struct.

Also, inline functions (marcos) in C/Obj-C are also problematic for these bridges since they need to call the functions at runtime.

Apple shipped a framework called BridgeSupport in Mac OS X 10.5 which contains XML data for all the things that cannot be determined at runtime. It also contains .dylibs with symbols for inline functions. BridgeSupport is still in macOS today, but it isn't getting much love and Apple keeps (accidentally?) breaking things in BridgeSupport every release.