You can see from the following code-snippet that each subsystem or "API" is now an instantiable class, and each system call/task for libGyro is implemented as a member function:

gyro::SystemAPI *gyroSystem; gyro::VideoAPI *gyroVideo; gyro::TimerAPI *gyroTimer; gyro::InputAPI *gyroInput; GameInput gameInput; void Init(int argc, char *argv[]) {     DBG = &Debug::getInstance();     gyro::VideoAPI::Flags flags;     //Program initialization      gyroSystem = gyro::SystemAPI::Create();     gyroVideo = gyro::VideoAPI::Create();     gyroInput = gyro::InputAPI::Create();     gyroTimer = gyro::TimerAPI::Create(); 

Also, for the first time since the "Gamma" build of the engine, the engine is back on every platform (DC, PSP, OSX, Linux, Windows, iPhone, iPad, iPod). I made sure to get every build of libGyro updated while I fixed the API itself.

A very important implication here is a proof of concept. Reimplementing the libGyro interface (as is) and compiling against it DOES allow us to move seamlessly to any other platform. We have even been talking with M_D_K about starting an Android smartphone build. M_D_K's work is completely in parallel with mine, so we are being insanely efficient by both working towards our separate goals. I'm pretty damn excited.

I will also be editing this post when I get home to add PSP/DC screenshots (I'm currently at school).

[b]ConversationSystem[/b]

I'm happy to announce that the ConversationSystem is now fully functional. I had actually been dreading reimplementing the bastard for quite some time. The original that I wrote two years ago on the Dreamcast (in pure C) was actually a nightmare and was some of the ugliest code I had ever written. The one that Marauder rewrote not too long later was also pretty ugly and inflexible (even though it was far better than my first attempt).

I guess that my skills have increased marginally since then, because this iteration of the ConversationSystem really only took a couple very productive days, is moderately attractive, and pretty damn flexible/versatile despite the complexity of the code. 

The look/aesthetics are definitely not finalized, but I would rather not spend a large amount of time messing with things like the UI until the time is right. It doesn't look terrible, and I think it will more than suffice during our initial development phases.

Dialogs (like everything else) are added to an entity as an attachable "Conversation" component. This component is then managed by the "ConversationSystem." 

Demonstrating a "character" with a "conversation" component. Note that the nametag "Marcel" follows the character on the X axis like a nametag. This works like our old textbox.

The Dreamcast is an "item" with a conversation component. This is how we will give random objects descriptions.

Here is an example of a "prompt" or a conversation screen that results in a decision. The first two decisions branch off to different areas of the conversation. The next ("Fuck Off") closes the textbox. The final, "Try Again," causes the conversation to loop back to the beginning.

Text appears on a per-character basis, giving it an oldschool 2D RPG typewriter effect. Holding down the button causes the text to appear much faster. 

The textbox also (a nod to Chrono Trigger) allows the player to continue walking during a conversation. If the player exits the conversation radius, the conversation ends. While in the conversation radius, if the entity that you are speaking to has a "character' component attached, the character always faces you. (So you can run around them in circles and they continue to look at you as though you are having a conversation). If the character ends up BEHIND the textbox, it fades to transparent and moves to the opposite end of the screen. This works much like it did with the old engine, but it looks far cooler and less obtrusive due to the alpha fading.

Here is a snapshot of the textbox in the middle of swapping ends of the screen. It was at the bottom and is now meandering up, because it was obscuring the Dreamcast.

The textbox allows you to flag any screen during any point in the conversation as "modal," which prevents the player from being able to walk away. 

The above screenshot really demonstrates the mechanism through which we will be creating these conversations. On the left, we have the source code that is deserializing each screen when a Conversation component is loaded. The text file at the right is the entity file where each entity is serialized for the engine to load. You can see the manner in which the conversation itself is stored. 

For now I had to write that by hand (which was actually not half bad, believe it or not), but a "Dialog Editor" will be included (relatively soon, goddamnit) with Marcel's editor. This will be accessible any time you attach a Conversation component to an entity.

Conversations themselves may also be generated dynamically (at runtime) through Lua. Perhaps the textbox will be used to display in-game storyline progression that really isn't a dialog between an NPC? Perhaps you want to use it to debug your Lua script? You can also pop the box and utilize it like a printf() call to help your debugging needs. Here are the public methods of the TextboxSystem:

public: 	ConversationSystem(); 	void Update(); 	void Render(); 	void ProcessInput(const GameInput &input); 	void Open(Entity &entity); 	void Open(Conversation &convo); 	void Open(ConversationDialog &dialog); 	void Open(bool modal, const char *text, ...); 	void Close(); 	Conversation *getConversation() const; 	bool isOpen() const; 	void setPartySystem(PartySystem *partySys); 	void setGuiSystem(GuiSystem *guiSys); 	//void setTexture(); }; 

[b]Agenda[/b]

As I have been trying to emphasize with every update, we are now doing everything we can to get the hell out of R&D and allow you creative people to start letting your imagination soar via level creation. Every new task is towards the goal of giving you guys what you need to do  your jobs.

The engine is almost to a point of being absolutely ready for any sort of level/terrain development. My final task is to reimplement the Lua system. (I bet you guys didn't even realize that it wasn't in Gamma, did you?) With this reimplemented, Tyler and all of you can begin scripting your levels and giving me feedback as to any new Lua wrappers that need to be implemented or fixed. 

With Lua implemented, the engine will be at a stable, sandbox state. All of my (and Marcel's) development attempts will turn to getting his Toolkit 100% caught up and integrated with the engine so that you guys have the ultimate development suite to give you everything you need to get your stuff done. :)

So yes, at the end of this week, expect both me AND Marcel to be full-time Toolkit developers. Expect a significant amount of progress, considering this week starts our Fall break.