| 123 | | About OpenGL ES: Don't remember whether I've mentioned this before, but if not: 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. |
| | 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. |
| 134 | | Google publishes a Native Development Kit (NDK), which is a set of tools for building native applications for the Android platform. Unfortunately, the official NDK does not and will not support the `std::wstring` (wide characters) datatype, which is required by the game, so we'll have to use the unofficial Crystax NDK, which is merely an extension of the official NDK adding support for wide characters and other features maligned by Google. |
| | 136 | Google publishes a Native Development Kit (NDK), which is a set of tools for building native applications for the Android platform. Unfortunately, the official NDK does not and will not support the `std::wstring` (wide characters) datatype, which is required by the game, so we'll have to use the unofficial Crystax NDK, which is merely an extension of the official NDK adding support for wide characters and other features maligned by Google. |
