Comments on the xna machine: Not Vacation

( I'm still working on this ;) )

2008-01-15T13:41:00.000-08:00

( I'm still working on this ;) )

Let me slap up an article on this subject later to...

2008-01-14T14:45:00.000-08:00

Let me slap up an article on this subject later tonight, I'll disclose all the Screen stuff as it is now and then go into what I think I want to do, I'd be interested to know what you think.

Now that I've had the chance to rattle things arou...

2008-01-11T19:03:00.000-08:00

Now that I've had the chance to rattle things around in my own thought box a bit ... I completely see where you're going now with the screens-as-top-objects. That should be the smoothest way to work things.

Now, working with the normal case of only a single camera involved in a screen, you would set its matrix within the world as if it were another sprite. However, the inverse of its matrix would then be applied to every sprite (and other drawn objects) within the screen right before drawing.

That would allow you to use the screens in a screen-handler for transitions (fade one out, switch to a different one as "current", fade it in) ... and it would allow the camera to move like any other sprite -- chasing, rotating, etc. -- and its matrix would be automatically applied when the screen's objects were drawn.

I think it's a solid and powerful approach. (In fact, I expect to use a variation on it in one of my own project. ;-D)

Cheers,
-Matt

Well I spent the weekend in my backyard building a...

2008-01-07T14:05:00.000-08:00

Well I spent the weekend in my backyard building a greenhouse kit w/ my wife, so "yes" to "still noodling".

This definitely helps me think outside my own little box here. In it's current implementation, Screens are the end-all, be-all parent node of an Update/Draw chain; but you're right - it doesn't have to be that way. I simply hadn't considered putting cameras "above" screens in the hierarchy. This really gets me wondering if the entire engine should fundamentally be camera-based. It's crossed my mind before, and it just seems to make more and more sense every time I think about it. What's really missing is a camera's matrix, which I'm guessing will be some kind of differential offset between "world" space of what it's following and the "camera" space itself.

Alright, well anyway I'm supposed to be "working" right now :) but the gears are turning...

Not sure if you're still noodling about how to mar...

2008-01-07T07:50:00.000-08:00

Not sure if you're still noodling about how to marry cameras to screens and the other objects, but I thought I'd throw an idea at you in case you wish to consider it ...

What if a "screen" was as you described (containing game objects), but did not have cameras as children. Instead, each camera would have a child screen.

Think of a screen as a space to hold things -- like a kitchen table currently holding a board game. (You might also have something useful -- like an options menu -- sitting on a nearby coffee table, etc.).

Cameras would be defined as a view of one of the screens. The camera could be defined by the rotational angle with respect to the screen, and how much of the screen was shown, etc. Perhaps you could then collect multiple cameras within a "display" object which represents the actual output to the player's display hardware.

As an example: You could define "camera 1" as showing a view of "screen gameplay" that was centered on player 1's vehicle and rotated to match that vehicle ... and "camera 2" could be showing a view of that same screen that was centered on player 2's vehicle ... and the Display object knows to show camera 1's view on the left half of the output display and camera 2's view on the right half of the output display for a typical head-to-head racing game.

You could still call a single, central object ("Display") to Draw, which would tell its children (the cameras) to Draw, which would each tell their children (the screens) to Draw, which would each tell their children (the game objects) to Draw. It would seem to fit your design, and allow the designer/developer to think about the game as if it were being shot like a live TV show.

Not sure if that's helpful to you ... but it was helpful for me to get the idea into a written form. ;-)

-Matt