I've been working on a fork of Aleph One, and would like to make it brain-dead easy for anyone to check out the source code and build the project. This is straightforward except for collecting the libraries needed by the engine.
For the main Aleph One repo, building from source is easy; you just grab all of the frameworks out of the release on the website and press some buttons. I, unfortunately, do not have that luxury. There are a few hundred megabytes worth of libraries and headers that a user would need to assemble. It would be nice to just check them into github, but it would really be pushing their file size limits (not to mention bad practice).
Does anyone have recommendations on the best ways to distribute project dependencies? How do other A1 forks handle this?
Distributing dependencies
Are you using different libraries? If not, I don't see why the same approach wouldn't work; grab the frameworks from mainline Aleph One and build.
As far as how other forks handle this: there aren't any. The community is so small that until now developers have mostly agreed to contribute to the main engine.
As far as how other forks handle this: there aren't any. The community is so small that until now developers have mostly agreed to contribute to the main engine.
-
TrajansRow
- Born on Board
- Posts: 70
- Joined: Sep 29th '16, 15:53
Yes; the libraries I need are built for arm64 and link with UIKit, so the release libs won't work.
Modifications to the project are mainly to support an alternative user interface and for OGL ES 1.1 compatibility (some of the same changes blezek did back in 2011); neither of which sound useful in the main release. ES 3 support would be a different story, but I'm not quite there yet.
Modifications to the project are mainly to support an alternative user interface and for OGL ES 1.1 compatibility (some of the same changes blezek did back in 2011); neither of which sound useful in the main release. ES 3 support would be a different story, but I'm not quite there yet.
-
TrajansRow
- Born on Board
- Posts: 70
- Joined: Sep 29th '16, 15:53
To clarify somewhat, my work on this fork started off last summer as a research project. The goal was to experiment with FPS control schemes on mobile platforms. In my opinion, mobile FPS control has been a mostly unsolved problem, and I believed I had some good ideas to contribute to the genre. Aleph One seemed like a good test bed - it was an open source engine that is easy to port and modify, and already runs on popular mobile hardware.
It turned out that the game can be really fun to play, and I want other people to try it. I just need to make it easy for anyone to do so.
It turned out that the game can be really fun to play, and I want other people to try it. I just need to make it easy for anyone to do so.
ES 3 would be very useful 
I guess you're limited to finding some place to host dependencies, but at that point you might as well release full binaries!
I'd love to try your ideas for mobile OS controls.
I guess you're limited to finding some place to host dependencies, but at that point you might as well release full binaries!
I'd love to try your ideas for mobile OS controls.
-
TrajansRow
- Born on Board
- Posts: 70
- Joined: Sep 29th '16, 15:53
While it's probably going to be necessary in the future, an ES 3 conversion is not something I'm working on right now. Most of my experience is in ES 2, and it was enough of a learning curve to acquaint myself with the fixed-function pipeline used in 1.1.
I figured I'd need to host assets myself... Not a huge deal, but I was hoping for something easier that I hadn't thought of. I submitted some of my early work to blezek, in hopes that he could get it in the hands of people faster, but it sounded like he has been too busy to maintain his iOS projects lately. I am also tracking head in github now, which has a newer license that may preclude public distribution anyway.
Because I want to make this application available to people for free, I intend to rely on the free provisioning features available in Xcode 7 and later. That works by allowing anyone to build and sign apps that they can run on their devices. I'm not aware of a way to do this with a binary that I've already signed for a general audience.
Another point, which I should not understate, is that the control schemes I've tested make use of uncommon hardware. Specifically, features like 3D Touch on iPhone 6s or newer and the improved haptic feedback on iPhone 7 is essential for reducing fatigue. There is a gyro component that works with all devices, but I'd say those controls are only as good as the current state-of-the-art, such as those found in N.O.V.A 3, et al.
I figured I'd need to host assets myself... Not a huge deal, but I was hoping for something easier that I hadn't thought of. I submitted some of my early work to blezek, in hopes that he could get it in the hands of people faster, but it sounded like he has been too busy to maintain his iOS projects lately. I am also tracking head in github now, which has a newer license that may preclude public distribution anyway.
Because I want to make this application available to people for free, I intend to rely on the free provisioning features available in Xcode 7 and later. That works by allowing anyone to build and sign apps that they can run on their devices. I'm not aware of a way to do this with a binary that I've already signed for a general audience.
Another point, which I should not understate, is that the control schemes I've tested make use of uncommon hardware. Specifically, features like 3D Touch on iPhone 6s or newer and the improved haptic feedback on iPhone 7 is essential for reducing fatigue. There is a gyro component that works with all devices, but I'd say those controls are only as good as the current state-of-the-art, such as those found in N.O.V.A 3, et al.
GitLab gives you 10 GB for a repository and has LFS enabled. So you could just check the dependencies into LFS...
-
TrajansRow
- Born on Board
- Posts: 70
- Joined: Sep 29th '16, 15:53
Thanks; that's just the sort of solution I was looking for!
Gitlab let me push the libraries and headers without any of the "not cool bro" messages that github was giving me. I was then able to add the assets from gitlab as a submodule to the main github repo. So now, a recursive clone should grab everything the project needs in a single operation.
Gitlab let me push the libraries and headers without any of the "not cool bro" messages that github was giving me. I was then able to add the assets from gitlab as a submodule to the main github repo. So now, a recursive clone should grab everything the project needs in a single operation.