Anyway, on to the journal entry!
In my old design (before the rewrite) everything was in the namespace SideScroller (Animation, TileSet, TileMap, etc.) Obviously some of these can be separated out since they're used in other 2D stuff (Animation for example.) In my new design Animation has been given it's own file, but I still had everything else in SideScroller (since this is my side-scroller map system.)
Anyway, after looking through my code (was changing to vertex-buffers instead of my test user-primitive draw code) I realized that my TileSet and TileMap class had absolutely nothing to do with a side-scroller. Needless to say, I now have Animation2D (containing AnimationTypes and Animation), Game2D (containing TileSet and TileMap), and SideScroller (containing BaseEntity, BaseEntityController, and TileTypes (tile types that are specific to side-scrollers.))
I also finished my random number generator earlier. Nothing big, just uses srand() and rand(); I might implement the mercienne twister (I think that's right) later on.
I also added a Grid class to simplify drawing a colored, arbitrarily sized grid (you get to choose both grid size (column and row count) and node size (width and height).) I used a line-list instead of the "triangles in wire-frame mode" because it looks neater. Eventually I'll go through and optimize it to use a line-strip, but I'm too busy at the moment (and it's not very important; it's on my to-do list though.) I did implement a function that would let you specify two arrays for widths and heights (one width for each column and one height for each row; not one for each node), but it didn't really seem helpful, so I commented it out for now. The grid can't be resized at runtime (yet, I may add this, but again this isn't at the top of my list), but it can be moved (you supply a position to the Grid::Render() method and it creates a translation matrix. I'll probably add rotation and scaling later.)
I kind of lied the other day; about the GUI. I just can't bring myself to write non-generic code for something that I could (and will) reuse later on. For example no matter what I'm going to need scrollbars for the editor's GUI (e.g. for scrolling around the tile-set when I'm choosing a tile.) So, instead I'm going to take a different approach. I'm going to write the base class for my GUI library and then I'm going to add controls to it as I need them (I'll add the basics that I've missed at a later time.) This will allow me to have my generic GUI without trying to write all kinds of code that I'm not going to need right now. This makes me happy since I won't have to write the code for the text-box just yet (I'm planning on implementing multi-line text-boxes, drag selection, ctrl-direction word skip, shift-direction selection, etc. (the basics IMHO).)
As an added note, I'm thinking of adding a built-in IRC chat-box. I eventually plan to write games that are multiplayer (not really MMO, just multiplayer) so an IRC chat system would be useful there, but it'd also be convenient for singleplayer games. I know some (or maybe most) might have the mentality "if I'm playing a game I don't want to chat (unless it's an MMO)", but personally I'd love to be able to have my IRC channel open in-case someone needs me (like Raymond) or you could find a chatroom and ask someone where an item is or something. I don't know, I think it would be pretty nice/useful even in a single-player game. Opinions?
I've also redesigned my debug console (I haven't finished the code though.) Some people are still going to say that it's too complex, but meh. Anyway, here's a quick feature list so far:
- As you're typing it'll narrow down choices into a drop-down-list control from which you can select an option.
- Built-in key-to-command as well as key-to-action binding. Shortcuts can also be bound (e.g. Bind "I + W" "Show Inventory.Weapons".)
- Commands will be simple one word commands with space-separated arguments (e.g. SaveMap "some_map.map" or Bind "I" "Inventory".)
Game specific command-handlers
- Commands will be checked for in a list and then passed to the current game instance's HandleCommand() before they're considered "unknown". This means that any command can be handled or ignored (if it's a built-in command you can just remove it from registry.)
- Plain text files with a command on each line. The game will be able to specify a start-up script file (allows the user to bind certain things at startup.) Commands will be supplied to interact with script files ("LoadCmdScriptFile/SaveCmdScriptFile "filename" and a few others.)
- Console.Dump will dump the console to the specified file (or ConsoleDump.txt if no filename is supplied.) Console.OverflowDump will dump all contents from the point it's enabled until it's disabled or the app closes (the word overflow is used because lines will only be dumped once they're removed from the console (the vector fills up and I start removing items) or when the app closes.)
- Not really a feature of the console itself, but the font system supports text coloring (I'm talking about per-word coloring, not just full string color.)
Technically, you could do per character coloring as well.
- Kind of like a breakpoint. You can check for it in-code and set it in-game (allows you to break after certain circumstances.)
- Enables single-frame mode, which allows you to move a single frame at a time. You can make things easier by binding the command to a key.
I have to say that this is the first engine design (that I've done) that I've actually liked. I know I keep saying that, but it surprises me [razz]. Most of the coding time spent on my old engines was doing redesigns of different systems, but I've only redesigned a few things this time and I don't spend all my time thinking I should have done something different. The only thing that I don't like about it (that I can think of at the moment) is that it's not platform independant, but I don't have any clue how OpenGL works (so I can't write a DLL based graphics system) and I don't have another system to test code on (I'm not buying a Mac and I really don't want to install another OS on this PC.) To be honest the only reason I think about cross-platform is because of Ravuya [lol].
"So why don't use you a free/open-soure graphics engine that supports both, like Ogre3D or Irrlicht?" I hear you ask: because I don't wanna [razz]. Seriously though, I might move to one of these at a later time, but it'll be after I've made a 3D game. And that still doesn't solve my other problems, like endianess and file-system differences (I know, I can use a third-party library for that as well.)
I'll blabber on some more about the engine design later today; for now I'm going back to work. I know I've said this a lot in the past, but I'll be putting some of the new engine's files up for download soon. They'll be in lib form for now (once I've finished the engine I'll release the full source, probably under the WTFPL license. I don't know though, if it turns out really well I might charge $100 USD for it and come up with some witty slogan that tries to force you to buy it using peer-pressure.)
I've decided that I'm going to keep my readers updated by supplying links to Raymond's/EDI's new journal entries. Some of you might already be keeping an eye on him (via RSS or whatnot), but I figure it might be helpful. if not, oh well, it's not like it takes tons of time or anything.
Anyway, here's his first two entries for those that haven't seen them: