Xna drawable game component order

Improve this question. Kenji Kina Kenji Kina 1 1 gold badge 7 7 silver badges 15 15 bronze badges. As you say, though, I don't think VeraShackle's answer should be the one with the most upvotes, so I'm marking your answer as correct again.

Novice programmers use it because it is "there" and it "works" and they don't know any better. They see my answer telling them they are " wrong " and -- due to the nature of human psychology -- reject that and pick the other "side".

Which happens to be VeraShackle's argumentative non-answer; which happened to pick up momentum because I didn't call it out immediately see those comments. I feel that my eventual rebuttal there remains sufficient.

And I am a professional game developer using XNA. The pedigree of my answer is impeccable. Show 3 more comments. Active Oldest Votes. So you could have components like maybe a Camera or a FPS counter? But the API is still usable Here's why you shouldn't use it: Basically it comes down to what is easiest to write and read and debug and maintain as a game developer.

Doing something like this in your loading code: player. Draw ; enemy. Viewport; player. Draw cameraOne, spriteBatch ; enemy. Draw cameraOne, spriteBatch ; GraphicsDevice. Draw cameraTwo, spriteBatch ; enemy. Draw cameraTwo, spriteBatch ; Admittedly you could share the camera and spriteBatch using the similar Services architecture. Improve this answer. Andrew Russell Andrew Russell That pattern is all about composing objects out of multiple components.

The XNA classes are geared to one-component-per-object. If they fit perfectly in your design, then by all means use them. But you should not build your design around them! See also my answer here - look out for where I mention DrawableGameComponent.

But I'd much prefer to use the player. I'm finishing a Flixel game right now, which draws objects in the order in which you add them to the scene. The FlxGroup system alleviates some of this, but having some sort of Z-index sorting built in would have been nice.

If you use a retained-mode API, or implement your own , the ability to change draw-order on the fly is definitely important. In fact, the need to change draw-order on the fly is a good reason to make something retained-mode the example of a windowing system comes to mind.

Show 1 more comment. Got challenge this one for the sake of a bit of balance here I'm afraid. There seem to be 5 charges in Andrew's reply, so I'll try and deal with each in turn: 1 Components are an out-of-date and abandoned design.

VeraShackle VeraShackle 3 3 silver badges 4 4 bronze badges. Which may have draw and update methods and so on. Read my answer here for some of my more detailed thoughts on architecture. Should I use a GameComponent for my sprites or not? Add a comment. Amble Lighthertz Amble Lighthertz 88 3 3 bronze badges. Superbest Superbest 1, 9 9 silver badges 15 15 bronze badges. The root object maintaining the state of the game world has an Update method that looks like this: void Update UpdateContext updateContext, MultiInputState currentInput There are a number of entry-points to Update , depending on whether the game is running on the network or not.

Neil Knight Neil Knight Add a comment. Active Oldest Votes. Improve this answer. Technically my answer is "opinionated" an informed opinion, no less , not "biased". If you need a game-global, data-driven, component-based system for your game - then obviously use GameComponent s - don't duplicate the functionality. However, like the Singleton pattern, that architecture is not ideal most of the time, as I describe in this answer. Just because the API exists does not mean it is the only way or the best way to structure your game.

I won't tell you which approach is better, but this is how you would do it without using GameComponents: In the game's Draw method, you call the Draw methods of the particle systems in the order you want: smokePlumeParticles. Draw gameTime ; explosionSmokeParticles. Draw gameTime ; projectileTrailParticles.

Draw gameTime ; explosionParticles. Draw gameTime ; fireParticles. Draw gameTime ;. Some bad examples would be creating a drawable component for every instance of a unit in a RTS, or every instance of a tile, or every instance of a UI element, or every instance of a character or bullet or particle, etc.

The drawable component provides an update and draw method that is called for each update and draw automatically by the game loop. That's all it really does. I'm puzzled to why your game ran slower when you made your entities not inherit the component class, but rather update and draw in a loop in your game's update and draw methods. There must be something else going on in your code that's causing the slowdown.

Just how many entities are we talking about? And are we creating and deleting entities during the middle of game play? Thank you for clearing that up, im not actually doing a scene graph but i suppose some of the results are similar. So now i know to go down the route of the non drawable component version.

There is no creating and deleting of objects during gameplay at the moment, but there will be later. I was thinking perhaps the iteration of the lists and then the iteration of the Dictionaries is slow, because the game entity update looks like this: public virtual void Update Microsoft. Add element. I personally try to design my update logic to not rely on a fixed time step. The reason for this is to prevent a slowdown if the game can only update 20 times this second opposed to 60 times the default.

No, the draw component does not cull anything for you. It also updates and draws depending on if you are using a fixed time step.

Of course, we can name the spritefont whatever we want -- we will need to change the spritefont file itself to get the font we want. If we open the. We can change any of the properties that we like in this file like, for instance, changing the font to Courier New and font size to Now that we have a SpriteBatch that we can use to draw elements on the screen, and a font to draw, we can update our draw method:.

We run our code and get What happened? We created a new GameComponent class, but we never created an instance of this class and added it to our game. So, in the constructor of our game, we can create and add a frame counter component:.

Note that there is nothing magic going on here -- the superclass Microsoft. Game contains a collection Components of GameComponents, and on every update cycle it calls the Update method of each component and on every cycle it calls the Draw method of all DrawableComponents.