Syntaxus Dogmata

An Insane Developer's Journal

Frames Are On!

I finished the introduction of Frames into VertX.  They work great, and the Screen class has been refactored the way I described in my last post.  Screens became so simple, in fact, that I wondered if I hadn’t made a huge mistake and turned it into something of a vacuous class.  But looking at it now that everything’s working, there’s enough functionality there to justify its existence, I think.

As I worked, the thought occurred to me about how adding frames affected things like collision detection and mouse clicks in the future.  VertX doesn’t feature such things right now, but it will fairly soon, and I couldn’t help but wonder if adding frames into the hierarchy wasn’t unwittingly sabotaging such matters.

I figured collision detection wouldn’t be a problem, as long as I made it a rule that sprite collisions would only be detected between sprites in the same frame.  Implementing this rule would make frames quite useful, in fact, as they would separate out the sprites whose collisions I don’t care to detect from those sprites whose mutual interaction I do care about.

Mouse clicks, on the other hand, nearly made me reconsider what I was doing with frames.  Every time the player clicks somewhere on the screen, I have to figure out what it is the player is clicking at.  It’s a form of screen-wide collision detection that transcends all sprite layers — including any frames that happen to overlap at those screen coordinates.

Obviously, this already violates the rule I established two paragraphs up, and I don’t envy the poor bastard (me) who is responsible for writing the algorithm that works through all the frames and sprite layers in order to serve up the sprite that was clicked… if any!  Not only that, but it must do so in a manner that doesn’t severely impact performance for that game cycle.  How would it look if every time the player clicked the mouse, the game froze for an eighth of a second just to figure out what it was they were clicking at?

If you’re waiting for ol’ Syndog to pull a proverbial rabbit out of his hat with some slick mathematical solution coupled with a brilliant coding twist, expect to be waiting a while.  I get the feeling the solution to this problem will require a lot of experimentation and trial & error engineering to pull it off.

But just because my hat is bereft of all lagomorphs in this matter, that doesn’t mean I don’t have a few tricks up my sleeve.

The first is a flag I’ve already implemented the Frame class, labeling it as mouse-sensitive.  If there are no “clickable” sprites in a particular frame, then there’s no reason why the mouse click algorithm should consider that frame at all.  That alone can cut out a huge number of sprites from the process of elimination.

Another idea I had was to make only one frame mouse-sensitive at any given time, which would narrow the field even further, but I think that’s too impractical a limitation to place on the game developer.  When it comes to the organization of their sprites among the screen’s frames, I want them to have as much liberty as possible.  Mouse sensitivity will certainly affect the way they organize their sprites among the frames, but I don’t consider it overly restrictive, as having only one mouse-sensitive frame would be.

One way or another, I’ll work it out.  Who knows?  Maybe I’ll get lucky, and the process won’t be all that intense to begin with, and I’ll find I was concerned over nothing.  Were I a gambling man, that’s not the way I would bet, but stranger things have happened.

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