XNA C# Development - Simple Q&A Thread

[J1M]

I find those literal strings in your parameters terrifying. I don't even use literal strings for text labels, lol.

 

[SCO]

They're short/long user descriptions, the method called on the object and the 'default keybinding' so they are final.

Yeah, i probably should be using bundles, but i don't actually care about internationalization.

If you're talking about the end run around the static system by creating such a thing as a 'DynamicAction' with reflection - no way that i would let the java static typing system sodomize me with the verbosity of subclassing dozens of actions. The method and arguments are checked as compatible in the constructor anyway, it's only a hidden mine if it's actually dead code.

Though to be honest, if i had done that, i wouldn't have this 'lazy singleton' problem since they would not store Application.instance, but use it directly.

 

[J1M]

Yeah I saw that the first couple were just descriptions, but the "fullscreen" and "alt ENTER" look like commands/key binds. I would want those to be some sort of delegate/action/function pointer and the others KEYS.ALT | KEYS.ENTER flags or something.

Obviously, if it isn't broke, don't fix it.

 

[SCO]

Sure... delegates could make the lazy part easy (if C# delegates can be used with static methods anyway) - but that is for java 8, not 7. When i upgrade i will change that not to use reflection.


The alt ENTER string stuff is not my idea, it's how swing defined 10 years ago their runtime parser for keystrokes. I kinda agree. Bitfields suck especially for things that are used 1-100 times over a application lifetime (they cache the keystrokes). Now if it used some sort of compile time extension of the type system...

 

[J1M]

Sure... delegates could make the lazy part easy (if C# delegates can be used with static methods anyway) - but that is for java 8, not 7. When i upgrade i will change that not to use reflection.


The alt ENTER string stuff is not my idea, it's how swing defined 10 years ago their runtime parser for keystrokes. I kinda agree. Bitfields suck especially for things that are used 1-100 times over a application lifetime (they cache the keystrokes). Now if it used some sort of compile time extension of the type system...

I'm going to try and add key bindings tonight. My plan is to store them as a set of enum flags that represent the modifier keys (NONE, CTRL, ALT, SHIFT) and another member that represents the key that has been pressed. So two typed integers, not a union of 100 bits.

 

[SCO]

Keystrokes are good, but the main problem there is the binding.

Swing uses some frankly retarded abstraction:
map<KeyStroke, GlueObject> (inputmap) and map<GlueObject, Action> (actionmap)
this was done for different keystrokes in the inputmap - different pressed keys - to be able to lead to the same action or not in the actionmap.
However it is retarded because when you're doing keybinding, that is changing the keystrokes that lead to a glue object, you need to guarantee that the old keystroke is removed, and that the glue object is not removed by accident.

The maps are prepared to have many keystrokes have the different glue objects that lead to many (or the same) actions, but they AREN'T prepared without a lot of pain to change the keystrokes themselves since invariants like - don't put the same keystroke in the map for different glueobjects since glueobjects are fixed and should always be in the map and overwriting is the same as deleting - aren't checked at all.

Basically swing has coding-time flexibility but doesn't help at all with some invariants.

BTW; if you use this design you probably want your keymappings GUI to prevent overwriting if the user configures tries to use the same keystroke for the different glueobjects (the old one would get deleted in the inputmap) and show a error and prevent saving (feedback) in your GUI otherwise.
If you're designing from scratch, the InputMap could probably be a 'InputMultiMap' if you don't think your users will get confused about the same keystroke activating two actions.

I ended up adapting this design to use a enum as the glue object and action container and that caused the other serialization problems.

 

[J1M]

Swing sounds a little like a jumbled mess. I'm rolling my own for the most part, and I don't care about things like chords. I will contain the multimap problem you describe at the user settings level and simply clear any key combination that already exists when a user sets it to a different action. Anyone advanced enough to be changing their controls is advanced enough to clue in when a setting is cleared.

 

[SCO]

That's the reason i ended up using enums + interface with the actions inside as glueobjects - allow named access to the actions, they are easy to 'enum'erate and i could see if something was missing (or show it was missing) in a generic manner. Clearing the keycombination must allow the action to be restored when the user tries to add it again.

The maps annoys me though - it looks like a leaky abstraction. Probably just giving up on the maps and just have enums + actions + mutable keystroke + default keystroke and iterating over them to find duplicate keystroke settings would be enough.
However, then serialization wouldn't really work without additional work (enum + mutable keystroke).

 

[SCO]

BTW, you probably want to turn off your keystroke processing in textfields or if the focused window is not toplevel - ie, it's a dialog (this one if you're going for global shortcuts).

 

[J1M]

BTW, you probably want to turn off your keystroke processing in textfields or if the focused window is not toplevel - ie, it's a dialog (this one if you're going for global shortcuts).

Yeah, I just have a callback that a textinput control grabs control of. If it's null, then I check for keybindings. Will have to adjust the ordering if I ever add copy/paste though.

 

[SCO]

Interestingly enough some applications don't bother to disable shortcuts in textfields - they just make every 'app' level shortcut require a non-text modifier key (CTRL-A for instance, not SHIFT-A) so you don't need to disable.

Tempted to copy that since it looks more user friendly.

 

[J1M]

Interestingly enough some applications don't bother to disable shortcuts in textfields - they just make every 'app' level shortcut require a non-text modifier key (CTRL-A for instance, not SHIFT-A) so you don't need to disable.

Tempted to copy that since it looks more user friendly.

You don't plan to allow keybindings like SHIFT+3 for player actions?

 

[SCO]

In a game, probably not - a better solution to this problem is a complete context switch where no game shortcut works (like doom 3 ingame monitors, or VTMB monitors).

But in a application? If you try to CTRL+F on your browser, write something and do it again, the text gets selected, and it's because the key dispatcher is not filtering on focused textcomponents, or is whitelisting CTRL or ALT shortcuts since they don't produce text - there is probably something screwy with utf-8 inputmethods though.

 

[J1M]

I guess it depends on the type of game you are making. Flight simulators, MMOs, etc. all require more than the number of hotkeys you have available without modifiers. Although currently I don't think I support just using Left ALT or Right CTRL. Will have to test that.

EDIT: Excellent. It worked without changes. It even allows stupid shit like CTRL + LeftAlt, lol.

 

[SCO]

BTW J1M, in AWT there is also the 'action' keys that i just noticed now when coding my code to skip filtering CTRL or ALT or META.
These are problematic (F1...F12, arrows, delete, END, etc) since although they don't produce text, some are used in text components for direction, deletion - so they should skip activating additional actions when in a textcomponent (or any component that uses them anyway).

edit: interesting - it works (doesn't activate the action) if actionkeys are allowed to activate actions in textfields. This is because the event is already consumed by the actions in the textfield so it never calls the callback that is supposed to activate the global actions. So actionkeys can be whitelisted for textcomponents too - they'll just do nothing if used on a focused textcomponent.

Still this is just probably not very relevant for games, where such complex keyboard driven components are not very common, and certainly not on the same context that the game shortcuts operate on.

 

[J1M]

Yeah, I also have problems with the keys F10, F11, and F12, but that is probably because they are doing some default windows action that I haven't disabled in XNA. F1-F9 work though.

 

[Destroid]

Any of you tried MonoGame?

 

[J1M]

Yeah, I also have problems with the keys F10, F11, and F12, but that is probably because they are doing some default windows action that I haven't disabled in XNA. F1-F9 work though.

By default in a windows menu F10 triggers the System key, which activates the current window/form's main menu. Pressing this button in a windowed XNA game will set the cursor back to the default mouse pointer and move focus out of your game. Terrible news all around.

Here's how to fix it:
1) Include System.Windows.Forms as a reference to your project.
2) Add the code below to your game's initialize method.

//Suppress F10 so that pressing it doesn't set focus to the game window's menu
Form winForm = (Form)Form.FromHandle(this.Window.Handle);
winForm.KeyDown += new KeyEventHandler((sender, eventArgs) => {
    if(eventArgs.KeyCode == System.Windows.Forms.Keys.F10 && eventArgs.Modifiers == System.Windows.Forms.Keys.None) {
        eventArgs.SuppressKeyPress = true;
    }
});

Assuming that you are polling the hardware as part of your input design, this will have no effect on your game's input. In my case, I can now use F10 as a keybind.

 

[J1M]

Any of you tried MonoGame?

Sounds like a great idea for an open source project, but my game is nowhere near the point where I would try to make use of it. (ie. after counting the money of initial release)

For those who are wondering: MonoGame is an effort that is trying to make porting from XNA to iOS/Android/whatever as easy as possible.

 

[J1M]

It is pixel shader time. The last time I looked at pixel shaders nVidia and ATI were developing competing standards. From the looks of things Microsoft's HLSL won, and Cg is exactly the same syntax as HLSL. More importantly, HLSL is what XNA uses for a content type known as an Effect. These effects are a part of the content pipeline the same way textures are, but they store pixel shader code instead of color data.

I found a nice refresher/overview of the subject here:
http://www.catalinzima.com/tutorials/crash-course-in-hlsl

And an excellent piece of XNA pixel shader sample code here:
http://create.msdn.com/en-US/education/catalog/sample/sprite_effects

That sample code restricts itself to applying effects on flat sprites, but there are other tutorials for 3D:
http://create.msdn.com/en-us/education/catalog/?contenttype=0&devarea=14&sort=2&lc=1033&p=1

I've been poking around with HLSL in Visual Studio 10 and was pleasantly surprised to find that it is actually compiled, which means finding basic errors and typing mistakes isn't like looking for a needle in a haystack. I also found this plugin, which provides syntax highlighting:
http://nshader.codeplex.com/

If anyone has a plugin that provides .fx files with code completion/intellisense support I'd love to know where I can get it. (Supposedly this is included in the upcoming Visual Studio 2012)

Additionally, if anyone knows of a good tutorial for writing a depth buffer in XNA I would like to see it.