Changes between Version 129 and Version 130 of AndroidPort


Ignore:
Timestamp:
Jan 18, 2012, 9:17:14 PM (12 years ago)
Author:
Anders Feder
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • AndroidPort

    v129 v130  
    9898
    9999I think the best approach is to extend graphics/!ShaderProgram.cpp to support GLSL shaders (it was designed with that in mind, but I don't know if it'll actually work without some interface changes); then move all the renderer's existing fixed-function texture-environment setup code into ShaderProgramFFP.cpp and implement GLSL-based equivalents, so that most of the rest of the renderer code doesn't have to care whether it's using FFP or GLSL (it just uses the CShaderProgram interface). Also, change all immediate-mode drawing (glVertex3f etc) to vertex arrays. I think that should deal with the most serious problems, and the code would all be shared between GLES and desktop GL modes (no need for forking or #ifdefs etc) and can be tested with desktop GL. Then there's probably just lots of little issues remaining, which can be addressed as they occur.
    100 
    101 === Optimizations ===
    102 The target device supports the ARM NEON SIMD instruction set. In turn, it does not support the x86 SSE SIMD instruction set.  Hence, it would be relevant to 1) identify portions of the code that use SSE and port them to NEON, and 2) identify portions of the code that lends itself well to SIMD processing, but doesn't currently target either SIMD engine, and port them to both, in order to achieve a speedup on both ARM and x86 architectures.
    103100
    104101=== Other dependencies ===
    … …  
    128125 * ''FCollada'' - We use a customised/bugfixed version of FCollada, so a port of the standard version of FCollada probably wouldn't work. Our own version has no significant dependencies other than libxml2.
    129126
     127=== Optimizations ===
     128The target device supports the ARM NEON SIMD instruction set. In turn, it does not support the x86 SSE SIMD instruction set. Hence, it would be relevant to 1) identify portions of the code that use x86 SSE and port them to ARM NEON, and 2) identify portions of the code that lends itself well to SIMD processing, but doesn't currently target either instruction set, and port them to both, and thereby achieve a speedup on both ARM and x86 architectures.
     129
     130The target device has a dual-core processor. Unfortunately, 0 A.D. doesn't really take advantage of multicore systems yet. This could improve with multithreaded AIs and pathfinding. 
     131
     132
     133
    130134== Implementation ==
    131135The [http://en.wikipedia.org/wiki/Dalvik_(software) Android VM] allows applications to call methods implemented in native code through [http://docs.oracle.com/javase/7/docs/technotes/guides/jni/index.html JNI]. This means we have to produce a native shared library which implements the core game functions as a set of methods (functions) which can be called from a [http://en.wikipedia.org/wiki/Shim_(computing) shim] running in the standard Android VM. The native library and the shim can then be packaged and distributed together as a standard Android application.