I also got an output-only debug console in place (mostly for debug purposes right now), but I'll add input for it at some point.
Last, but not least, I got the tile engine and camera system up and running. I just need to decide if I'm going to do auto-tiles or just completely manual tile setting. The latter would be easier programming-wise, but I'm using RPG Maker XP resources until I get most, if not all, of the content in place. Meaning, for the former, I'd have to take any RMXP auto-tile that I want to use and manually cut it apart and append it to every tileset that I want to use it with.
Hm...I just had a thought. I could have the tilesystem load the auto-tiles and then manually cut it apart and hack it together in a way that would make working with it at render time easier. Though, that pretty much falls into the category of memory vs speed. Meh, if they can do it manually at run-time using GDI (which I'm assuming on both parts, seeing as how it's so god-awful slow), I should have no problem at all doing it with Direct3D.
The hardest part for auto-tiles will be figuring out the algorithm for choosing which tile or tile-chunk to render. If any of you remember, I did this once before (with a different tile format) and it took FOREVER. That was a while ago though, so I'm hoping it will go much faster this time (meaning, I'm aiming for tomorrow night.)
I've had thoughts of just buying RMXP and using that to do it, but the engine features are way too generalized, in some places things are handle very oddly (i.e. setting up a door), and some things just plain don't work (or I'm not really understanding how the specific thing is supposed to work). For example, the wait function inside of the move event function doesn't work; to get the processing to wait I have to chop the movement path into separate move-wait pairs (this ties to setting up doors as well. The way they have it setup, you have create an event and then attach)
One of the main issue for me though, is the fact that the whole thing is based on an archaic system. Single state UI, no mouse interaction, etc. This can easily be circumvented (to an extent; also, I'm not sure about mouse interaction) using the scripting system, but it'd take way too long. Playtesting a brand new project takes around 30 seconds to starts, so tinkering with scripts is out of the question (especially for anyone without any patience.) Don't get me wrong, it's a great system and it has come a LONG way since RM95, but it's still pretty much based on the same system (out of the box.)
I was going to try using RMVX...that is until I downloaded it. It's the newest addition to the family, yet it's a HORRIBLE mix of RM2K and RMXP. They did well on improving the look of the UI, but they replaced multi-layer maps with a single-layer map, stuck with their ever-faithful 640x480 resolution, and replaced all of the awesome resources RMXP had with shitty constant-size, 90's Console RPG graphics. The IDE looks better than ever, but the engine seems to be going backwards.
Lol, I can almost hear the comments: "If you think you can do better, then do it." Hopefully, once I get this project done with, I'll have the start of an engine that I can use to make something that is better. We'll see though; no promises. I might just say screw it and switch to 3D once this is finished.
Anyway, I wandered way off there. Here's a little screeny of the engine as it stands:
The only issue I'm having is with my font; for some reason quite a few characters don't show up (all of the A-Z, a-z, and 0-9 show up fine). I'm assuming it's something wrong with dbGameFontLib, but as my Tweet points out, before I can test it I have to rewrite it so that it uses the new dbeals library (which expanded upon and replaced dbeals.ToolBox.) Not top priority as it still renders everything I need correctly. The rewrite will also include a couple minor upgrades: my old-school outline system and letter-based gradient rendering. Text looks a lot better with a gradient applied IMO. I'm using the old school outline system (rendering the letter 5 times: offsetting the position by a pixel in each direction and then rendering it at the output position) because it's a lot simpler than doing it the correct way and it doesn't require shaders. If it proves to be a bottleneck, I'll try some way to improve it or simply omit it.
I'm also thinking about including the text-effect system I was talking about when I wrote dbGameFontLib. The idea is pretty simple; I'll provide an interface (probably dbGameFontLib::BaseTextEffect) that will have a single methods:
void Update(real32, Vertex*)
Then, there will be a separate class (probably dbGameFontLib::TextObject) that will be component based. A small example:
// class ShineTextEffect : public dbGameFontLib::BaseTextEffect
// class SineTextEffect : public dbGameFontLib::BaseTextEffect
MyTextObject.SetText("Why hello thar! My name is $0xff800000
// in my update function
// in my frame function
That's the general idea anyway.
I'm rambling and wandering, so it must be time for bed.