Changes between Version 115 and Version 116 of AndroidPort
- Timestamp:
- Jan 16, 2012, 5:37:53 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AndroidPort
v115 v116 94 94 * Double-tap position in game world - apply selected unit's primary action to the position. 95 95 96 === Libraries === 96 === === Graphics === 97 Android includes support for high performance 2D and 3D graphics with the Open Graphics Library (OpenGL), specifically, the OpenGL ES API. Since the game utilizes features of the full, standard OpenGL API, these portions of the code will have to be migrated to OpenGL ES. 98 99 I 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 === 102 === Other dependencies === 97 103 Android-compatible replacements must be found for all [http://trac.wildfiregames.com/wiki/BuildInstructions#Linux the dependencies of the PC edition]. This is what we have so far: 98 104 … … 120 126 * ''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. 121 127 122 === Graphics === 123 Android includes support for high performance 2D and 3D graphics with the Open Graphics Library (OpenGL), specifically, the OpenGL ES API. Since the game utilizes features of the full, standard OpenGL API, these portions of the code will have to be migrated to OpenGL ES. 124 125 I 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. 126 127 == Implementation == 128 === Implementation === 128 129 The [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. 129 130