Syntaxus Dogmata

An Insane Developer's Journal

On To Frames!

All right, so it took more effort than I thought, but after much weeping, wailing and gnashing of teeth (and I don’t mean in a good way), I achieved what I set out to do in my last post.  No longer is the SetUp() method having to check for valid objects among the parent and children along the class hierarchy.  It required a few default objects to be made, which I hadn’t anticipated, but there you have it.  This also bought me the liberty to review the code already in place, and make a few minor adjustments.  Mostly it was eliminating code that I’d written under pretenses that ended up not working out in the end, and I neglected to go back and remove it.

So now, on to frames!

You’re gonna want to slap me around after I spent all that time fussing over sealing the Screen class a couple posts back, but I’m reconsidering the conclusion I reached.

If you’ll recall, I decided against it in order to keep screen creation simple.  If the Screen class isn’t extensible, that means all the custom, game-specific objects that compose a screen (sprites mainly) would have to be instantiated and added to the screen by the outside world, making that code more complex than it needs to be just to set up a screen.  I delight in simplicity, and the mechanism of choice by which I achieve it is through encapsulation.  That means the Screen class will need to be extensible, and I still stand by that.

So no, I’m not contemplating a sealed Screen class in the future (not that I’ll confess to, anyway), but I am thinking of abstracting the Update() and Render() methods from its descendant classes.

This wouldn’t make sense if the Screen dealt with all manner of sprites, all bouncing around the screen higglety-pigglety.  How else would the screen manage the various drawing effects and parameters of all those sprites?  The way XNA employs the SpriteBatch ensures any standard algorithm set in stone would be implausible.

But now the screen isn’t dealing with all those sprites.  With the introduction of the Frame class, sprites are now effectively abstracted from the Screen class.  Instead, screens deal exclusively with frames — a far simpler notion — leaving the frames themselves to deal with all those pesky sprites.  All it would take is for the Screen class to store its frames in a standard collection, and then call their execution methods successive to the order they were added.

In short, I’m making a compromise here between the two extremes of letting the game programmer go nuts overriding the fundamental operation of screens, and shutting them out of all customization completely with a single keyword.  Screens will execute the same across the board, but will remain extensible for the purposes of composition setup.

In the words of Gurney Halleck, “Behold, as a wild ass in the desert, go I forth to my work.”


Apr 14, 2010 Posted by | VertX™, Video Games | , , | Leave a comment

Sprites FTW, Quandaries FTB

Well, with the advent of a bitmapped on-screen paper airplane (with alpha channel transparency, no less!), I’ve achieved what I set out to do last weekend.  It was about as simple to achieve as I expected, but now that I’m to the point where I feel like returning to the Tetris game using VertX as my framework, I’ve come up with a few quandaries I’m trying to address…


I’m about to enter what I call my “muse mode,” which means I’m really just talking to myself, and documenting it for my own future reference and that of my therapist, attorney, legal guardian, royal concubine, etc.  Anything I say in here cannot be used against me in future posts, as I’m merely waxing philosophical, if not outright rhapsodic.


Currently, VertX sprites are wrapped in the Widget class, which I had intended to use as a logical single screen entity containing one or more sprites.   Now that I’m looking at the architecture from a game perspective, however, I’m starting to see a lot of functional redundancies between sprites and widgets.  I find myself asking, “Why not just couple the logic of widgets with the display data of sprites, and cut out the middle-man completely?”  All it would take is for sprites to be able to contain and render other sprites (which they could easily), and voila.   I’m seriously considering it.  It would remove a layer of complexity in the VertX hierarchy, and I’m having trouble seeing any down side to it right now.

Assuming I go ahead and remove the Widget class completely, the simplification would be a short-lived reward, as I’m considering introducing a Window class that would sit between Screen and Widget/Sprite in the hierarchy.  This would effectively make it so widgets/sprites would be drawn within their window’s boundaries, rather than the screen itself.  Assuming each window would cascade its transforms such as rotation and scale, this would make thumb-nailing the action a total breeze for the game programmer.  It would also help organize all the many and sundry contexts used in a single screen.  With every sprite/widget belonging to the same screen, it’s a huge hassle to organize everything under a single floating point value for layer depth sorting.  With windows, each layer depth float would be window-dependent, and therefore much simpler to manage.  For example, if Window A and Window B overlap and are drawn successively (each in their own SpriteBatch.Begin() – End() block), it is assumed that everything drawn in Window A would be overwritten by everything in Window B, regardless of the layer depth values of their sprites.  The windows themselves would be an added level of organization as far as screen draws go.

I’m tempted to try this using XNA’s GraphicDevice.Viewport feature. It automatically cascades position coordinates and crops anything drawn outside its boundaries, just as I would want a Window class to do.  If I go with this technique, however, I wouldn’t be able to cascade things like scaling, which I think would be very handy and potentially cool as a special effect.  If not, then I’ll have to handle cropping myself — something I’m not sure how to do in XNA, if it’s even possible.

All of this brings up an even larger quandary.  The whole idea of making VertX hierarchical in nature is for cascading effects.  For example, if you rotate a widget, all the sprites that widget contains would automatically inherit that rotation, and behave accordingly when they’re rendered on the screen.  VertX doesn’t have this cascading feature yet, and I’m trying to work out a way to make it work — not just for screen coordinates, but for transformations as well.  I’m thinking the answer lies in the execution methods (Update and Render, specifically) passing along the various offsets of the parent as they’re called.  Each item in the hierarchy can add its own offsets as they’re rendered, or pass them along to child items as needed.

The question is how to pass along the cascade data.  RenderSettings seems like the perfect containing class with which to do this, but not without a couple concerns…

1. RenderSettings is a class.

I did this deliberately so that I could pass these particular values by reference, and have any settings adjustments automagically show up in any item that references the RenderSettings object.  Low overhead is a wonderful thing when you’re tweaking settings sixty times every second.  Problem is, this doesn’t lend itself well at all to cascading values along the screen hierarchy.  To do this, I would have to create a new object every time a cascading adjustment is made before passing it along to child entities, which would undo any performance perks I gained by making it a class in the first place.  I’d have to make RenderSettings into a struct, which means auditing all the existing code that uses RenderSettings objects, and making sure they’re not relying on value-by-reference adjustments.

2. The fields in RenderSettings weren’t selected with cascading effects in mind.

This means there might be fields in RenderSettings that make no sense to be cascaded along the hierarchy.  I’ll have to go over them one by one to see if any of them don’t belong.  If RenderSettings turns into a struct as I’m considering above, then it’s essential that all fields have a reason to be cascaded, otherwise C# will spend time repeatedly copying memory locations for no reason with each game cycle.  To make things worse, there might be additional fields not currently included in RenderSettings that I need cascaded.

If I find any fields in RenderSettings that fit this description, I would need to split up RenderSettings into more than one aggregate type.  I’m not happy about this, as there’s a logical reason I’m lumping these fields in RenderSettings in the first place.  Here’s hoping I don’t have to.


If you’re wondering why I haven’t already checked RenderSettings for errant fields, it’s because all these quandaries came up about ten minutes before it was time to head into work this wild and woolly Monday morning.  I had to head out literally mid-whiteboard as I pondered the matter.  Figures, doesn’t it?

So in summary, I have three screen hierarchy issues I need to settle this week…

  1. Whether to remove the Widget class.
  2. How best to introduce windows.
  3. How to add cascade effects.

So much for pushing forward with Tetris this week.

Apr 12, 2010 Posted by | VertX™, Video Games | , , , , , | Leave a comment

Let’s Get This Party… Scrolling!

After taking a week off from all C# development, I return with glad tidings on the VertX front.  Two weeks ago, I succeeded in returning text sprites to the screen, bringing VertX back up to where it was before all the many and sundry refactorings that took place.  After working with it for a couple weeks, I’m confident this is the architecture I’m going to stick with.  No more sweeping refactors!

Anyway, regarding text sprites, my next step was to make the text scroll across the screen.  Nothing fancy — just a ticker-tape type scroller using a True-Type font.  A minor victory, to be sure.  I spent most of my time trying to figure out a way to scroll it smoothly, but I got it going as smoothly as I’m ever going to.  Good enough for now, anyway.

Next on the agenda is texture sprites, which is a much larger stride from the gamer’s perspective.  I don’t expect too many problems, though.  The foundation is already laid with text sprites, so it should just be a matter of duplicating what’s already been done, except throwing up preloaded bitmaps instead of text.

Apr 05, 2010 Posted by | VertX™, Video Games | , , , | Leave a comment

“I am the KeyMaster (App)”

While putting together Ken’s bingo game example this past weekend, it occurred to me that with all the game development studies I’ve been pursuing lately, I haven’t really grasped console input in C#.  After digging into the Console class, and its corresponding ConsoleKey enumeration, the further thought occurred that the nomenclatures they assign to many keystrokes make about as much sense as Muhammad Ali in a post-match interview on ABC’s Wide World of Sports. (Thank you, Microsoft!)

Masochist that I am, I decided to address the matter once and for all, so I thew together a little thing I call the KeyMaster.  Nothing too complex, really.  All it does is read each keystroke from the keyboard, and reveal any relevant data aggregated among C#’s ConsoleKeyInfo struct members.  You’ll find the complete source at the bottom of this post.

KeyMaster also offered me the opportunity to get some delegate practice in.  Ctrl-C and Ctrl-Break are handled differently, both of which typically close console applications.  KeyMaster intercepts a Ctrl-C just fine, but C# throws a tizzy fit if you dare attempt to intercept the Ctrl-Break the same way.  C’est la vie.

Anyway, here’s the complete source.  Hopefully someone will find it useful…

using System;

namespace KeyMaster {

	public class KeyMaster {

		protected ConsoleKeyInfo myKeyInfo;

		// delegate for handling special keystrokes (ctrl-c & ctrl-break)
		public void ConsoleCancelEventHandler(object sender, ConsoleCancelEventArgs args) {
			ConsoleSpecialKey key = args.SpecialKey;

			// check for ctrl-break
			if (key == ConsoleSpecialKey.ControlBreak) {
				Console.CancelKeyPress -= ConsoleCancelEventHandler;                    // remove the special keystroke handler delegate

			// ctrl-c was pressed
			myKeyInfo = new ConsoleKeyInfo((char)3, ConsoleKey.C, false, false, true);      // handle ctrl-c like other strokes
			RefreshDisplay();                                                               // show it on screen
			args.Cancel = true;                                                             // cancel closing the app

		public void RefreshDisplay() {
			Console.Write("\nPress a key...\n(Ctrl+Break to Quit)\n\n");
			Console.Write("\t   Character: {0}\n", myKeyInfo.KeyChar);
			Console.Write("\tNomenclature: {0}\n", myKeyInfo.Key);
			Console.Write("\t   Modifiers: {0}\n", myKeyInfo.Modifiers);

		public void Run() {
			Console.CancelKeyPress += ConsoleCancelEventHandler;                            // add the special keystroke handler delegate

			do {
				RefreshDisplay();                                                       // show the latest keystroke info on screen
				myKeyInfo = Console.ReadKey(true);                                      // wait for another keystroke
			} while (true);


	class Program {

		static void Main(string[] args) {
			KeyMaster km = new KeyMaster();



Mar 22, 2010 Posted by | Tools | , , , , | Leave a comment

VisualStudio Sucks!


I just wanted the world to know that Visual Studio has to be one of the most asinine IDEs on the planet.  Even with ReSharper, it’s just this side of intolerable, what with…

1. …such atrocious default settings that I’m still trying to ferret out amidst the vast and labyrinthine options window.  Ever hear of a search feature, Microsoft?

2. …IntelliSense making grossly erroneous judgment calls that take more time to correct than if I’d just typed them out myself in the first place.  I swear, if IntelliSense needlessly qualifies a member with its full namespace for me one more time, I’m going to single-handedly discover the Higgs boson!

3. …naming conventions that would make Marquis de Sade cringe.  I want the name and address of the idiot savant at Microsoft who decided that starting every public member with a capital letter was a good idea!  Can we say “rampant name collisions?”  What, was IntelliSense not stumbling around in the dark enough for you already, you had to keep pulling down that window shade?  Yes, I know it’s because of compatibility issues with Visual Basic and its ever-so-quaint case insensitivity.  Please don’t get me started on Microsoft’s blind and laughable attempt at making BASIC into an object-oriented language in the first place.

4. …NO BEER! ’nuff said.

As I said above, ReSharper conceals many of Visual Studio’s sins.  This is a very good thing, otherwise my list of grievances would be much longer.  Still, there’s only so much it can do as a mere plug-in.

I really miss IntelliJ IDEA.  Hell, at this point, I even miss Eclipse!  I wish someone with an IQ higher than a high school gym teacher would invent a new and completely original C# IDE, built from the ground up.

Are you listening, JetBrains?


Mar 21, 2010 Posted by | Uncategorized | , , , , , , | Leave a comment