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

Widgets, Frames and Screens — Oh My!

Lots of activity this week.

I decided to follow through with my plans to remove the Widget class from VertX. As of now, widgets are no more, and sprites are directly interacting with their screens. Unsurprisingly, the transition went smoothly.

One quandary down, two to go!

Next, I’m pushing ahead with the “Window” class I mentioned yesterday. I’m actually calling it a “Frame” class, and I’ve decided I’m going to start out by using the GraphicsDevice.Viewport technique I was speculating about yesterday. It won’t do everything I wanted, but at least it’ll be a very simple way to start out, and it’s a chance to learn about an interesting XNA feature.

Where I’m floundering is what the imposition of the Frame class implies. Much of its functionality will be extracted from the current Screen class, which up until now has been a customizable abstract class. Now that I’m looking at how much functionality frames will replace in the Screen class, I’m starting to think that not only should Screen not be abstract, but possibly a sealed class that treats all of its frames identically. This shifts all the “smart code” from the screen to its frames — a distribution of complexity I see as a good thing. I delight in useful simplicity, after all.

The problem with making Screen a sealed class is that it forces a level of complexity every time you make a new screen. By making Screen abstract, I’m able to encapsulate that complexity in the Screen class’s descendants. That way, it requires only a single “new” statement to transition from one screen to another, rather than constructing all the Frames required, and adding them to the screen one by one from outside the Screen class. If I rob myself of that encapsulation, it shifts the complexity from within the Screen class to exposing it to the rest of the framework — not a good thing!

Come to think of it, the “smart code distribution” perk I mentioned will be spread among the frames in any event. It won’t matter if Screen is a sealed class or not.

That settles it. I think it’s too high a price to pay just to keep things stable the closer you get to the VertXEngine in the class hierarchy. The screens should encapsulate all of their own setup code, which means keeping the Screen base class abstract. See? I knew this dev journal was good for something.

Hey, shut up. I wasn’t talking to you!

Apr 13, 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

So Full of FAIL

I know I promised an entry this week filled with nothing but daffodils and butterflies, but the truth is I have yet again restarted work on VertX.

I’ve decided not to keep XNA at arm’s length as I had originally planned, for a couple of reasons…

First and foremost, as I delved deeper into VertX’s functionality, I came to see how much time and effort I was putting into duplicating XNA’s utility classes (Vector2, SpriteFont, Rectangle, etc.) in order to keep from incorporating them directly in the VertX namespace.  Relatively speaking, a LOT of my code served this one purpose, and I still recognize it as necessary for my intended goal.  At some point, however, I saw just how many translations I was going to make between VertX objects and their corresponding XNA objects each and every cycle in the game loop, leaving actual game processing power at a small fraction of what it could be.  This would place a pretty severe cap on the caliber of games I could make with VertX, and I want to get as much horsepower out of it as I can before my aspirations outgrow XNA & C#’s capabilities.

Which brings me to the second reason.  At this time, I realized that if and when I hit this “glass ceiling” with XNA, it was unlikely that I was going to gain anything more from other C# game development frameworks.  It’s far more likely that I’ll be moving on to C++ as my language of choice, and interfacing with a low-level hardware API like DirectX, rather than some other higher-level framework in C#.

Granted, it’s possible that someone could invent an even more robust and powerful C# framework between now and then.  If they do, I’ll be eating my words.  Still, my gut says I’m making a winning move, mainly because even if I do end up rewriting VertX to fit a new high-level framework in C#…

1) It’ll still be easier than interfacing with something low-level, even if it’s not the plug-n-play solution I was originally hoping for, and…

2) I’ll still be getting as much horsepower out of it as I possibly can, without endless object translations between VertX and its host framework, hogging all the processing power in the primary game loop.

So yeah, I started over on VertX, and you know what?  The more I get into it, the more I’m convinced it was the right move.  The class hierarchy is so much more simplified now, and simple always brings a big smile to my face.  I’m able to focus more on VertX’s architecture instead of worrying how to access XNA’s features and data.

Already I’m back to where I was with VertX two restarts ago.  I’m rendering text on the screen, monitoring game performance, and I’m putting transforms to those text-based sprites as we speak (rotations, resizing, etc.).

My hopes are high for next week’s journal entry.  And this time, I mean it!  No, really!

Mar 17, 2010 Posted by | VertX™, Video Games | , , | Leave a comment