|
| From: | Jordan Schidlowsky |
| Subject: | Re: Live GNUstep Android game ( Golf Blitz ) |
| Date: | Mon, 6 May 2019 16:37:49 -0600 |
Thanks Ivan! So, many thoughts on this... First off, I'd start with cross-compilation. In the industry I work in, the deployment platform is generally not the development platform. ( Actually it seems like a general 'open computing platform' is getting harder to find as a lot of platforms are becoming more and more locked down ). I suspect this won't change, and Android, iOS, Fuchsia, Switch, etc, will continue to be platforms that aren't suitable for development, but require deployment to. The GNUstep make/build, although capable of being cross compiled, definitely feels like a process that is designed for deployment on the development platform. I sometimes felt like the build environment, and test suites could be 'modernized'. I'm not sure how, and I'm not a build tools guy by any means, but it just feels like my industry is moving completely towards different environments for development and deployment, (with deployment platforms being VERY locked down). libobjc2 was pretty simple to integrate, with the exception of the tests (which I still haven't found an easy way to easily run them on platform). The main hardships and trouble points with getting GNUStep running on Android is somewhat of a loaded question. The main issues arise from what parts of Foundation are generally language related (objc) and what parts are platform related (NSBundle, NSUserDefaults for example). To me, this is actually one of the biggest problems of the ObjC language, and probably has contributed to it's lack of widespread adoption. I know there are other projects like ObjFW, that basically duplicate a ton of existing data structures, when it really shouldn't be necessary. If some kind of small standard library for ObjC existed that was NS* compatible it would be quite useful without having to 100% commit to all the other platform stuff. IMHO I think Foundation should have be split into two frameworks: language classes, and platform classes. And if there isn't a clear division in some scenarios the platform specific stuff should be taken out and implemented as categories in another framework (just my 2 cents). In our games we do a TON of UI work... Like a massive amount... To the point where the UI code is probably 95% of the codebase and the actual game logic is maybe 5-6%. ObjC is a pretty nice language for UI work, as there's just so much you can do with dynamic dispatch that you can't do with a statically dispatched language. Refactoring, adaptability, forwarding, runtime introspections, memory profiling/debugging, there's just a whole bunch of issues that are much easier to deal with and adapt to if you are willing to sacrifice a few cycles here and there. IMO UI code is one of these areas. Menu's, windows, scenes, buttons, layers, etc, all benefit from this immensely. Our game logic, which needs to be super fast, is written in c++ and c. But anyways, ya, shoe horning the platform specific stuff in GNUStep onto android is probably the hardest part... A prime example is NSBundle. Applications on android are basically zip files, who's assets are generally inflated on the fly, so there's just no clean way to adapt the NSBundle API on Android. For example how do you express 'pathForResource' within a filesystem AND within a zip file? It just doesn't work without ugly, ugly hacks, and it really shouldn't work because fundamentally they are different platforms and do things differently. Our solution to most of these issues is to just not use the API, which is generally manageable for games because games really just require a thin wrapper around IO, display/sound. Of which we use a VERY thin UIKit wrapper for input, and OpenGLv2 rendering which is already cross platform for the most part, which means we really are only using a small subset of GNUStep. Android IDE support is also not great. And actually this is one of the few things I like about CMake, because it can generate various backends for your projects (one of which is Xcode). But basically you have to end up using Android Studio or XCode at some point if you want to ship on iOS or Android, so having a build process that can generate those project files as a backend is quite nice. We use most of GNUStep and all dependencies to CMake so we could have the whole stack in Android studio so we can do a 'one-click' build/deploy/run/debug. This allows one to quickly and easily edit & debug (within the IDE which is quite nice) stuff in libdispatch, or libffi, compile and run with address-sanitizer, or whatever really... With things not really being stable on that platform this was kind of a must. The biggest annoyance is Android Studio not having language support for ObjC. I'm not sure what it's using for c/c++ syntax, libclang, or clangd, or what, but ObjC is definitely not supported. This leads to a mild annoyance, but we usually just develop in XCode and then update/compile/run in Android Studio. At least we have debugging support within Android Studio, which is very nice. Anyways, I could probably rant on for hours on the subject, but those are some of the main pain points for us getting stuff running on Android! Also all our development has also been done on Macs. No linux, or BSD development machines in the office.
|
| [Prev in Thread] | Current Thread | [Next in Thread] |