| | 28 | === Input events === |
| | 29 | As far as I understand from the wiki, handlers for input events are specified in XML and !JavaScript. So I am wondering if it would be a possibility to simply add a range of new events (e.g. !TouchDown, !TouchUp, etc.) for the engine to handle? Then the port could simply be supplied with a new set of XML and !JavaScript files for the UI, but retain most everything else. |
| | 30 | |
| | 31 | The game's input events originate from SDL, so the real question is does SDL support these Android-specific events? At least in the development branch there is an [http://wiki.libsdl.org/moin.cgi/SDL_TouchFingerEvent SDL_TouchFingerEvent] that should work for this. You only need to add new events to the GUI XML schema if you're going to add new GUI object types, which might be reasonable on an Android port. I'm thinking it would be easiest to avoid that until absolutely necessary. Either way the GUI manager will need to be extended to capture these events and pass them onto scripts like the session input.js, which is where the most interesting event handling occurs (unit selection, building placement, etc.) Unfortunately the GUI engine code is a mess. |
| | 32 | |
| | 33 | Check out !HandleEvent in ''source\gui\CGUI.cpp''. See also EGUIMessageType in GUIbase.h. In fact you should be familiar with most of ''source\gui''. For the XML parsing you'd want the CGUI::Xeromyces_* methods at the bottom of CGUI.cpp. For camera movement, see the CGameView class in ''source\graphics\!GameView.cpp''. |
| | 34 | |
| 116 | | 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 | 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. |
