Syntaxus Dogmata

An Insane Developer's Journal

Spritely Sprites in Spriteland

The last quandary I’m slated to tackle is the whole cascading effects feature I’ve wanted for VertX.  See this post I made several days ago for details.  Originally, I was ruing the task of getting all of that working in VertX, but now I’m not so sure it’s going to be the chore I was expecting.

What I’m discovering now is that I don’t have much cascading left to do in the hierarchy, really.  My initial thought was to have sprite objects able to contain other sprite objects, but after thinking about it, I’m coming to realize that such a thing would be overkill for what I want to do with sprites.  Instead, I’m leaning toward having sprites contain multiple graphics (Texture2D objects), and manipulating them during the sprites’ Update() and Render() cycles.  That way their locations and transformations can be relative/cascaded or not as the game developer chooses.

So, in the time it’s taken me to get to this cascading effects issue, I’ve removed the Widget class from the hierarchy, added the Frame class, and decided that sprites don’t need to contain other sprites.  These three things together has made cascading effects something of a non-issue.  All I have left to do, really, is create a sprite with multiple textures, and voila!  I’m in business.

Once that’s done, I have a decision to make.  I could proceed to work on the Animation class, which is pretty exciting and a big leap toward making VertX’s a viable game development framework.  I’m tempted, however, by the prospect of working on Tetris again.  I’m in this to make games, after all, not merely to make an XNA-based framework for game development.  Tetris wouldn’t require any animations (that I can foresee right now), so this is an opportunity to actually put my framework work to work and make it work.

Yeah, that sounds more appealing.  I’ll extend VertX as needed with future games that are more sophisticated.


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