This project is read-only.

Draw Depth and UserInterface

Feb 21, 2011 at 6:09 PM

I have my own SpriteBatch instance which I use to draw textures to the screen. In addition, I am using the GuiManager to draw various controls, both in the menus and as part of the in-game HUD.

The problem is, since I am adding my game-objects to Components after my GuiManager, they are being drawn over the top of my HUD.

 

I have tried using the "DrawOrder" property, but to no avail.

 

 

Any ideas?

Feb 21, 2011 at 7:00 PM

DrawOrder should have the desired effect as long as your HUD is also drawn by a GameComponent that's added to the Game.Components collection (versus manually from within Game.Draw(), in which case it would depend on whether you do your own drawing before or after calling base.Draw()).

I just checked the behavior by creating a small DrawableGameComponent that prints "Hello World" on the screen:

  • If I don't assign the DrawOrder property at all, the order in which the components are added to the Game.Components collection seems to define the drawing order (no idea if this is documented or might change by random)
  • If I assign -1000 to the GUI's DrawOrder, the "Hello World" is always printed on top of the GUI
  • If I assign +1000 to the GUI's DrawORder,the "Hello World" is always printed behind the GUI

You could manually trigger the GUI's Update() and Draw() methods instead of adding it to the Game.Components collection as a workaround, but that really shouldn't be necessary. I can't spot anything in the code either (it's just an integer property that triggers an event when changed, all the sorting stuff is done by the collections in the Game class)

Feb 21, 2011 at 8:12 PM

Got it fixed... I was rather stupidly ending my SpriteBatch after base.Draw()

 

Another question:

Are there any known issues with the InputManager?

When I use the IsKeyDown methods, they read opposite values untill I have pressed all of them at least once!

 

My code in the Update() method:

            KeyboardState keyboardState = inputService.GetKeyboard().GetState();
            Vector2 adjustment = Vector2.Zero;

            if (keyboardState.IsKeyDown(Keys.Up))
            {
                adjustment -= Vector2.UnitY;
            }

            if (keyboardState.IsKeyDown(Keys.Left))
            {
                adjustment -= Vector2.UnitX;
            }

            if (keyboardState.IsKeyDown(Keys.Down))
            {
                adjustment += Vector2.UnitY;
            }

            if (keyboardState.IsKeyDown(Keys.Right))
            {
                adjustment += Vector2.UnitX;
            }

            if (adjustment != Vector2.Zero)
            {
                view.Adjust(adjustment * 2.0f);
            }

 

Feb 22, 2011 at 10:01 AM
Edited Feb 22, 2011 at 10:05 AM

Yep, that's a bug that slipped into the CodePlex release. See this thread: InputManager.GetKeyboard().GetState() returns wrong states for isKeyUp and isKeyDown.

I've already tracked it down and fixed it, you can find updated binaries on my build server: https://devel.nuclex.org/teamcity/viewLog.html?guest=1&buildId=lastSuccessful&tab=artifacts&buildTypeId=bt13.

I'll do a full CodePlex release as soon as I figured out another bug with the PrimitiveBatch class, hopefully by the end of this week :)

EDIT: Whoops, sorry for the weird font sizes. Must have copied & pasted the font's style, too, when I selected the other thread's topic title.

Feb 22, 2011 at 2:14 PM

Ah, excellent. I'm in no hurry, I doubt a beta of my project will be ready before the next Nuclex release anyway.  :-)

 

 

Quick question:

 

I currently create all of my game-components (stuff that inherits from GameComponent, DrawableComponent, Component etc.) in my Game class.

Each game-state takes, through its constructor, all of the game-components it requires.

My Game class manages the which game-states are active etc. through a GameStateManager.

When a game-state is entered (inside the OnEntered() method), it calls Initialize on all of its game-components. This causes each component to set itself up, adding itself to Game.Components etc.

When the game-state is closed, it disposes/disables all of its game-components.

 

Is this an appropriate architecture to use with Nuclex?

Feb 25, 2011 at 9:54 AM

Definitely. I designed the game state management system as open as possible so it work in almost any kind of design, regardless of whether a game state is a game in itself using its own components or whether it's just a short-lived condition the game can be in.

In my own game, game components outlive game states (for example, there's only one global GuiManager / IGuiService - when the main menu state is closed, it simply detaches its screen from the GUI and when the game play state starts, it attaches the screen for the game's HUD to the GUI). Sub-states (eg. in-game inventory screen) are realizes as game states that are pushed on top of the game play state. But that's just one way to do it.

Feb 27, 2011 at 5:22 PM

Excellent!

 

I didn't want to run into any issues down the line from improper use..