Alexei Baskakov

Xna.Input.Keyboard has no events OnKeyUp and OnKeyDown, so I can't subscribe any object on this events using delegates. Is any reasons - why

I know that I can do this by myself (examine the keyboard state every Update and call those events), but it's an ideological/archetectural question: I don't want to "pull" keyboard every time, I need my objects to be "pushed" on a keyboard event. In general, "push" model improves scalability and maintainance of a system since It's syncronous - each object reacts the event immediatly when event call occur.




Re: XNA Framework XNA Architectu "push" vs. "pull" model

thedo

My guess on this would be this -

1: Not everyne wants/needs the push model you describe. Whilst it might not be the most inneficient thing in the world to check if a delegate is null, and if not then call it, there are a lot of people (myself included) that dont need it, therefore dont want any performance penalty for those who do want it.

2: Its reasonably trivial to implement, so much so that it may become one of these GameComponents that either everyone writes or uses (assuming someone somewhere sets up an uber repository of Gamecomponents). My take on this is that while its possibly bad that everyone is rewriting the same code, I'd rather have the clean API that allows us to add this functionality, rather than force it upon us if we dont want/need it.

Not sure about in .net framework 2, but events used to be real slow too, but that was in .net 1, so this may have improved to the point where its not an issue.

N






Re: XNA Framework XNA Architectu "push" vs. "pull" model

qrli

Reason 1) Console games use only pull mode while many PC games use push mode. XBox is a console.

Reason 2) The push model on PC depends on Windows message queue while there's no such thing on XBox.

Reason 3) You can use key events from Controls if you are using WinForms.

Reason 4) A push system can be really simple or very complex depending on your need. Consider character translation, key repeat, IME, etc. Some of those features are not supported on XBox.




Re: XNA Framework XNA Architectu "push" vs. "pull" model

Malmer

Having push in a game could potentially be really bad. Many games rely on the rendering to be done as often as possible and game state updates only to happen at fixed intervals (give or take some ms). Especially physics and AI could get hurt by this quite bad. If a push command comes in and modifies the game world while it is being rendered you're entering a world of pain man. A WORLD of PAIN.

But, if you do your keyboard thingie as a gamecomponent you should be safe, since this will only happen while you are in an update call anyways. Unless the event system is multithreaded, which I highly doubt.

So remember, a world of pain...





Re: XNA Framework XNA Architectu "push" vs. "pull" model

BlueG

It's funny... all these posts that mention console games and none that states the simplest truth: console games almost never use any keyboard input.

Still, XNA was meant for developing Windows games as well. To this end, my own disappointment was that they only support XBox controllers.

On the subject of pushing vs. pulling, though... the pulling method is really a lot more convenient for ordinary game control. If a key or button is down, then you do something, and if it isn't, then you don't. In a pull model, this can be done with a simple if statement. In a push model, you have to look for a down event, set a flag, check the flag where your action occurs, and then clear the flag when the up event occurs. That is the real reason consle style games tend to use a push model rather than a pull model. The pull model, as someone suggested, isn't that much faster. In fact, it can be slower depending on how its organized and used.

It's also much easier to reverse the pull model than it is to reverse the push model. And, for those cases where a mixed model is needed, creating your own event model will let us, the game developers, decide how to coordinate the two, rather than having it dictated by the framework. This is particularly relevant since, in games, you generally develop your own user interface system. On that last, many game engines include an interface system, but XNA is more of an API than a game engine. And that's not a bad thing; game engines are built on top of API's. Also, API's provide the foundation for a much broader range of games than a game engine will. Do we really want Microsoft producing an engine that, say, was only really good for creating first person shooters, arcade style games, or whatever else In any case, something such as an event model (for a push system) really belongs in that intermediate level of "engine" where we begin to determine how the system will really work.

Anyways, that's my two cents...






Re: XNA Framework XNA Architectu "push" vs. "pull" model

Alexei Baskakov

> console games almost never use any keyboard input.

That was just an example about event-driven (push-model) architecture. People here are seeing the elephant's trunk and ears only, not the elephant as a whole.






Re: XNA Framework XNA Architectu "push" vs. "pull" model

Alexei Baskakov

> A WORLD of PAIN.

No pain. The only thing you need - it's an experience in large-scale real game projects.

See http://en.wikipedia.org/wiki/Event-driven_programming






Re: XNA Framework XNA Architectu "push" vs. "pull" model

Jim Perry

BlueG wrote:
Still, XNA was meant for developing Windows games as well. To this end, my own disappointment was that they only support XBox controllers.

There's nothing stopping you from using DirectInput for controllers for PC games.






Re: XNA Framework XNA Architectu "push" vs. "pull" model

Promit

You don't want to do this as much as you think you want to.

The problem with a push model is it forces everything to respond to information at a certain point in time. This won't scale well with a threaded architecture. Suppose you're running a render thread and two game update threads. When do you cause the input to push Which thread do you push from And now your objects have to be able to handle an input event appearing in the middle of their update. And trying to solve this using locks is just going to make a mess of things, because now you're going to have to use fine grained locking for everything.

Pushed events sound good from a single threaded mindset. That's a mindset you need to break out of. When you throw parallel processing into the mix, this is a really bad idea.





Re: XNA Framework XNA Architectu "push" vs. "pull" model

BlueG

"There's nothing stopping you from using DirectInput for controllers for PC games." - Jim Perry

True enough. I'd already thought of this, but its still a disappointment. Much more so than having a "pull" model rather than a "push" model (which was actually more of an "oh, thank God" ).

I need to figure out how to do quotes and code examples in this forum... time to look around for the help section.






Re: XNA Framework XNA Architectu "push" vs. "pull" model

Gerix

I like push in really big sprawling programs. If you do too just put some polling code into your Update method, arrange a place for objects to register for various keyboard events, and you're good to go. A little more work but you'll end up with exactly what you want. You can even get fancy and arrange some cross thread notifications if you like.