About this blog
You don't have to be an excellent programmer to write a game, just look at this!
Entries in this blog
Shortly after the last update I realized things were headed in a really, really bad direction.
-I was randomly checking some handles using Process Monitor from Sysinternals when I noticed that I had a lot of repetitive file handles. It turns out that the config-loader I was using: SDL_Config doesn't properly release files. Every time I opened a file with it, the Windows handle to it stayed open. So I sucked it in and re-wrote a parser from scratch. It doesn't include the same functionality of SDL_Config(it's stupid about types and also has no support for [Groups]) but it's everything I need right now.
-Alongside this I realized that with SDL-Config taken out and my own grumpiness regarding adding [Group] support when I didn't need it in any of the other config files in my project, my GUI's config file was now unparsable. I had the choice to either add [Group] support or change the way I handled the file and I ended up choosing the latter. It now uses TinyXML to parse, meaning that in theory it can now support some pretty funky parent/child window relationships without the children having to explicitly know anything about the parent window(or even that they HAVE a parent window). It was a learning experience.
-After that, I then realized that I was hard-coding way, way too much of the individual classes together. Mostly this impacted the GUI, which was displaying gameworld information dynamically. However, this required that the GUI explicitly know what the World was and retain a pointer to it so that it could make boatloads of calls every frame. While this works for now, upon time it would have gotten unnecessarily complex and instead I opted to hack up a quick Messaging System. Emphasize the 'hack up' and ignore the 'quick' of that statement. I'm still working on getting everything back to the state it was in before and shifting as much hard-coded pointer functionality into Messages as I possibly can.
-After THIS, I need to implement framerate independant timing. If I get it working now, early on, it'll save me an uncountable amount of time in the future. However, it'll require some good sized re-writes of some objects which'll probably stall further advancement by another little while. It'll also allow me to do fun timing effects, possibly even in a per-object way.
What's different in this screenshot, you might ask. The only thing that I see is that now the GUI looks like it was laid out by a retarded ape who stuck forks in his eyes, you might explain.
It got that way because I dragged the windows to their positions, I respond.
GUIWnds are now fully draggable anywhere on the screen. While their Z-ordering sucks while doing this, it'll do until I bother with supporting root/child window relationships.
Another minute and I'll get it set up so that you can click to reset a window to it's default(config defined) position.
Other minor improvements are a bugfix in my rotational code for units. Now you can actually move the mouse with the rbutton down and they'll rotate as it moves, rather than once per click. Note to others: SDL_Event.button.state for a MOUSEMOTION event does not carry the current button state. It appears to only be used on a MOUSEBUTTON event.
Now to quit slacking and work on context menus.
Update: Screenshots suck, have some XVid
The ground textures are from a free texture pack from Here - Found via Garage Games.
The Unit sprites are borrowed from Relic Entertainment, they'll get swapped out whenever I find an artist.
The Unit Portrait is borrowed from Relic Entertainment, it'll get swapped out whenever I find an artist.
The Font is Arial Black.
The GUI Windows are using a simple Window PNG I cooked up and stretching it to scale.
The GUI windows are all configurable(width/height/xpos/ypos/type) via a text file - sadly support for handling different 'types'(Unit Info, FPS, Unit Portrait) require hard-coding into the GUI itself. I'd like to try and script as much of this as possible at a later point.
However, the GUI supports hot-swapping themes at any time once the GUIManager object has been created.
The engine itself is built like ghetto housing, and isn't half a modular and cool as I wish it would be. A lot of the various components rely far too much upon other components(The GUI is pretty much tied in tightly with the World object, just so it can retrieve Unit information, for instance. However, ravuya's excellent Propane Injector library has saved me a lot of time in the coding of underlying features like image loading and rendering.
I'm just running with the WH40k theme for now since I was in a big Dawn of War kick when I started the project. It'll get swapped once I finish up the engine and focus on an actual theme.
Work started officially on Hair Trigger recently. Doom3 caught my time this week, but I hope to put at least a few spare hours into getting things set up for the basic engine. Class heirarchies are a pain in the ass to set up gracefully. I'll probably get the very basics in first, so I can at least get things rendering. Being able to see my work means more motivation to improve what I see.
Work started officially on Hair Trigger recently. Doom3 caught my time this week, but I hope to put at least a few spare hours into getting things set up for the basic engine. Class heirarchies are a pain in the ass to set up gracefully, and I'm almost tempted to simply
Macros bug me.
lol programming joke
Trying to get a complete object-oriented system going for Hair Trigger. My mind is starting to bend and twist in the right ways, but it hasn't quite warmed up yet. Trying to figure out the basic class heirarchy and get it coded before I start worrying about actual GAMEPLAY code.
Been busy the past few days cranking through Stroustrup's official guide to C++. Still have a lot to go through before I'm going to feel confidant that I've recovered at least a portion of my old skills.
Note to new programmers: Be VERY careful about burning yourself out. It's easy to do, and it's hard to recover from. Also be prepared to neglect certain life obligations once you're out of school if you aren't already. There isn't a whole lot of time in the day, and between work, sleep, and a little leisure time, putting even an hour or two a day into the code can be difficult.
To jump again, I really enjoy Stroustrup's way of explaining and definition. I feel more comfortable with it than I often do with anything I've read published by SAMS. The code is clean and precise, no light jokes, no page long descriptions of obscure minutae. His explanations of things are good, and he focuses as much on the ideals of C++ as he does on the technical aspects.
However, I don't know if I'll ever get used to his bracketing.
just looks so weird and jumbled to me right now, especially since most code I've seen either uses one style or the other, not both.
On second thought, however, I'll probably use this as the place to keep track of the soon-to-enter development of my project, Hair Trigger.