Syntaxus Dogmata

An Insane Developer's Journal

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

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: