Mobile OS support

[aegis]

if we have good enough phones in 6 months for a very cut down version of spring, we will have phones running current spring fine in 12 months. stripping spring down there would take more then 12 months.
problem solved.

we've had phones capable of running stripped-down spring for a couple of years.

even if the phone is fully capable of running spring... there's a decent amount of work to be done to make it run on ARM/OpenGL ES

[raaar]

is it worth the effort?

[Argh]

It would be, if we had a game design suitable for mobile and there was money in the offing. Probably not otherwise, but who knows, maybe this is something that will appeal to somebody's boredom

[AF]

Not at all smoth, Id quite like to have the option to sacrifice things like terrain LOS blocking or 3d projectile physics in favour of lowtech simpleton calculations amongst other things that sacrifice accuracy in favour of faster simpler more scalable calculations.

It would not be a large branch of the engine either as we already have a handful of features that do precisely this kind of thing and have had patches for things with similar things in mind in the past such as teh wireframe map patch

[smoth]

but that seems more something that is going to come when they further decouple the engine isn't it?

[AF]

And the downsides of the necessary steps to running on these platforms being something we plan to already do is? There's also the added benefit that an iOS port would solidify what OS X support we have. It would also put us as the most advanced RTS on the platform by a long margin. AAA titles that have copped out on the cheap would be forced to compete and we'd get far better value for money

[echoone]

I am an Android developer.

spliff, it will not sync with x86.

This is a very important aspect. Furthermore, Android will likely run on ARM, MIPS, and x86 (official, unofficial port already exists) over the next year or so. Furthermore, ARM in of itself has many variations - for example, some don't have FP, whereas some that do have FP is actually still fairly slow. Additionally, on Android, all UI components of an application must still be coded in Java, requiring a JNI interface bindings and/or various service hooks, or other tricks.

Also, while the NDK continues to improve, it is still rather limited and APIs can continue to change/evolve over time.

Furthermore, GPU performance is still all over the place. Some high end devices have lackluster GPU performance. Not all use VR-based implementation. Unlike Apple's platform, support can be a serious headache because of the huge variation in capabilities and performance. Even worse, some devices are just flat out broken in regard to various features (e.g. Droid exposes light sensor but it never returns results).

OpenGL ES is a variation of traditional OpenGL. This likely means writing a completely new render pipeline, which based on comments I've read here, due to Spring's design, is a serious project in of itself, over and above what is already a considerable project. And that ignores the fact that some OGL profiles are flat out broken on some Android devices; resulting in everything from flat out breakage to lackluster performance.

Also, the Dalvik VM is very finicky about performance critical code. Its extremely important the GC never attempt to collect during game play as jitter and all out lag will become painfully obvious to players. Creating such a design is unquestionably doable, but requires a precise eye during design and development.

Lastly, Android's support for C++ sucks. They only support a subset which absolutely does not include templates, exceptions, or RTTI.