Syntaxus Dogmata

An Insane Developer's Journal

More about VertX Hierarchy Classes

Okay, I know this is a lot of Syndog Noise™ for one week, but there’s just so much to consider with this Frame refactor that I’m getting a bit overwhelmed.  And since writing it all out helps me organize my thoughts…

All this talk about encapsulating the instantiation of Screen objects in my last post has me second-guessing how this is currently achieved for all hierarchy classes in VertX.  When I first started piecing this beast together, I had a chicken-and-egg issue when it comes to hierarchy class composition of their parent and child objects.  After all, hierarchical classes would be impossible to instantiate if their constructors demanded a parent object and child objects as parameters.  By definition, no hierarchical class object could exist without a full set of preexisting hierarchical class objects to pass.

Catch-22 FTB.

To address this problem, I made it so parent and child objects could be added through accessor methods after construction completed, but before the SetUp() method was called by the engine.  If they hadn’t been added yet, then SetUp() would throw an exception and say it’s Miller time.

I never really liked this solution, to be honest.  It made me squirm in much the way Hanes Her Way do on Hulk Hogan.  Mired as I was in a conundrum of a hundred other dilemmas at the time, however, it was the only way I could see out of that particular issue.

Now I’m considering revising it so a parent object is required in every hierarchy class’s constructor, leaving the instantiation of any child objects to be encapsulated within the class itself, or by descendant classes if it’s abstract.  This is exactly the same as with the Screen class I mentioned in my last post, except this will be true for all classes at every level of the hierarchy.  From where I’m sitting right now, this comes off as a very clean and elegant solution that makes class hierarchy instantiation a breeze outside the API.

Time will tell.

So, before I introduce the Frame class, I’m going to give this solution a whirl.  For those of you who made it this far and managed to follow what I was gibbering about the entire time, I’ll let you know how it works out.  For those of you who didn’t, I’ll still let you know how it works out.  I’m flexible that way.  No need to thank me — your look of bemusement mixed with sheer horror is thanks enough.


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


By the way, I failed to mention what I used to draw the paper airplane in my last post.

I considered using the copy of Paint Shop Pro X I bought years ago, which has been my 2-D graphics application of choice since the mid-1990’s.  It’s a great tool, but my copy is several generations old now, and I don’t really feel like coughing up the cash to upgrade.  Ever since PSP went from a simple paint program to a full-fledged photo editing suite, it’s had a ton of features I just never use in my line of work.  All I need are the bare essentials to make graphics around which I can develop software.  Anything professional I need, I can leave to an actual graphic artist.

So I went on the prowl for something open source or freeware (or cheap at the very least), and came across a few names that seemed interesting.  Gimp sounded like a solid choice that’s withstood the test of time, but I didn’t care for the UI all that much.  Pinta caught my eye, but it too seemed geared more toward photo editing than graphic arts.  But Pinta did mention that it was based off of something called Paint.NET, so I gave it a try…

…and I fell in love.  Very few features proved too vague for me to figure out intuitively, and the tools are very much in line with what I consider essential for a basic paint program.

Thanks for the perk, you guys!  I have a feeling I’m going to be using Paint.NET a lot in the foreseeable future.

Apr 12, 2010 Posted by | Tools | , , , | 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