OK, I've got two main topics here, so let me try to split them up with headings
RTTII guess I wouldn't mind using RTTI in GAE, but we'll have to do an audit of all classes to discover which the compiler would generate RTTI info for and make sure it's none of our high-use objects. I haven't used RTTI in C++ much at all, but my understanding is that it only generates the information (and thus, overhead) for classes that contain at least one virtual function (
http://en.wikipedia.org/wiki/Run-time_type_information). I'm very cozy wtih the general concept of RTTI because I've done so much Java (and every non-static method in Java is virtual). Currently, we have a lot of enums for object type. As I understand it, using the typeof() operator is identical in performance.
My only concern with RTTI is bloating objects that don't need it. If you guys want to discuss this further, let's start a new thread for RTTI, it's certain worthy of it.
GUIBack to the GUI topic, whatever we come up with, I just want it to be very visually flexible. We don't need compiz-level effects, but I want it to be able to compete with the GUIs you see in todays games at least. It should be able to read configuration files (preferrably XML) for layout/format information. Lastly, the ability to animate components would be nice (i.e., when you're mouse floats over a button it does weird stuff). I've been thinking out an internal architecture for how we'll implement the connection in GAE between the GUI library, the user interface definition (what you write to "skin" GAE) and the internal GAE data. This is what I've come up with so far.
First off, in software engineering, one is always weighing various options to determine the best balance, usually in terms of "performance vs something else". Some stuff in GAE I've aimed to keep the working set small (less code), some less memory usage, some faster execution, etc. In the case of the GUI, I don't mind moving a bit away from "top performance" (like we want in path-finding, rendering, etc.) and more towards flexibility, maintainability & good design. So I'm thinking something along the lines of exposing displayable data, actions and events through an abstracted means that allows each to be referred to by their textual names. Here's a very brief and over-simplified example:
class SomeUIClass {
private:
int mySpecialValue;
public:
string getValue(const string &name) {
if(name == "mySpecialValue) {
return Conversion::toString(mySpecialValue);
}
// ... etc
}
void setIntValue(const string &name, const string &value) {
if(name == "mySpecialValue) {
mySpecialValue = Conversion::strToInt(value);
}
// ... etc
}
void doAction(const string &name) {
if(name == "mySpecialAction) {
mySpecialAction();
return;
}
// ... etc
}
private:
void mySpecialAction(); // e.g., "Start Game"
};
Obviously, the implementation would be something much more re-usable and we'll possibly need something for call-backs (I'm not entirely sure how that should work). Then, we can have an XML with something like this:
<my-excellent-ui-screen>
<label name="mySpecialLabel" text="You have ${mySpecialObject.mySpecialValue} specialness left."/>
<button name="makeMoreSpecial" action="mySpecialObject.mySpecialAction"/>
</my-excellent-ui-screen>
So maybe Lua would be the best solution for this (the Lua snippets can be contained in the values of XML attributes). This doesn't *have* to be the same XML or other configuration file that gets fed to the GUI library, but it would be nice if we could use it for both the GUI definition and layout as well as the connection to the internal GAE data, action and (possibly) events (or callbacks). From what I can tell at this point, we would mostly need callbacks if we need to tell the GUI to re-read values or some such, to prevent the need to call the accessors every rendering frame. Perhaps the GUI library can cache its values until we send a callback dirtying some fields and then the GUI will re-request the appropriate fields.
EDIT: Oh! One last thing!
Whatever we settle on & do, I would like for us to release it with two initial UI skins:
- A "Classic Glest" skin that looks exactly like Glest 3.2.2
- Some other Snazzy-looking skin to demonstrate GAE's skin-ability.
I know this has been mentioned before, but ideally, I would eventually like GAE to be usable as any RTS engine, so that starting it with certain parameters changes everything about it (skin, menu configuration, etc.).
