Pumping the Guide

re: Pumping the Guide

aumfer — Thu, 11 Jun 2009 16:13:59 GMT

What about a non-blocking version of the API?

The function returns null if the user hasn't selected anything yet and I can just go about my day. Do you need to take control of program flow here?

immediate mode 4tw :)

re: Pumping the Guide

ShawnHargreaves — Thu, 11 Jun 2009 21:26:05 GMT

> What about a non-blocking version of the API?

Wouldn't that end up looking basically the same as what we have today with the separate Begin and End calls?

re: Pumping the Guide

DFHanson — Fri, 12 Jun 2009 00:56:00 GMT

I actually like the "screen grab" idea. You wouldn't have to force every game to use it; they still have the Begin/End pattern to follow if they want. It can be explicitly acknowledged that extra memory will be allocated for the screen grab, and it can be documented that "extreme badness" will occur if the blocking call is made in a background thread.

As long as you provide the normal Begin/End alternative for the games that can't handle these two problems, I think the screen grab blocking call would be a great option.

re: Pumping the Guide

DFHanson — Fri, 12 Jun 2009 00:57:41 GMT

Heck, you could just avoid the badness by throwing the almighty Code 4 if the blocking call is made in a background thread. :)

re: Pumping the Guide

caleb.vear — Fri, 12 Jun 2009 04:33:15 GMT

How about you implement the Guide functions as a component? Then when you call a Guide function you can pass in an implementation of some interface that manages the calls to the Guide and does whatever needs to be done after the gamer has decided what they want to do.

Alternatively you could just call the function on the Guide component and pass in a delegate that gets called containing the result. I think that that could be quite good and you could implement it on top of your current implementation.

re: Pumping the Guide

Dave Carlile — Fri, 12 Jun 2009 06:55:42 GMT

I created a static class to simplify dealing with the async nature of XNA message boxes. It's kind of a quickly hacked up thing in response to this post, so maybe there's a better way of handling it, but it seems like it allows you to at least pretend you're coding with blocking message boxes.

http://www.crappycoding.com/2009/06/simplified-xna-message-boxes/

I'm far from an expert on this kind of thing, so please feel free to poke holes in it.

re: Pumping the Guide

Kevin Gadd — Fri, 12 Jun 2009 08:19:39 GMT

I actually find the Guide APIs pretty straightforward to work with. I just wrap the Begin/End pairs into Futures and use cooperative threading to suspend my game logic until the Guide operations are complete. I would have had to wrap any blocking form of the APIs in a threadpool work item in order to get an asynchronous version, so I really appreciate that the XNA team decided to offer them as Begin/End pairs instead.

The C# compiler's support for iterators is perfect for this since you can write your asynchronous logic in the form of an iterator, and 'yield return' an object to suspend execution until it's time to continue. No pesky state machines to write! :)

Now if only creating and initializing a GamerServicesComponent didn't hang my main thread for like five seconds, I could do all my game's loading smoothly in the background while rendering frames...

re: Pumping the Guide

sirlantis — Sat, 13 Jun 2009 00:25:53 GMT

Well, I think there are a lot of guidelines which you want to stick to. Out of the blue I would go with this one:

- Disallow all calls to Guide from background threads.

- int Guide.ShowMessage("Title", "Msg", {"Yea", "Nay"})

blocks the game, renders a black screen or a provided Texture2D. This one is for all those people who want to go straight forward.

- If you want to use the async calls to the Guide, you have to call Guide.DoEvents() within your loops (preferably in the Update part). If you use the Game class, this could be taken care of already.

- Guide.ShowMessage("T", "M", o, delegate(int result) { if(result == 0) doIt(); })

will then add an delegate(){callback(result);} to an internal list "to be called". Guide.DoEvents() will then invoke all the delegates on this list, so that another call to the Guide will be from the main-thread again, to allow the regular chain of events:

"Do you want to save"? "Yes" -> "Which device"? "HDD" -> Save

- Drop all non-blocking calls to the Guide while the Guide is still in focus.

- While the Guide is in focus, all blocking calls will stop, wait for the guide to close, then their Guide will be opened, processed and then closed.

I can't really see why you would _need_ to use a background thread to popup the Guide. As I hate applications stealing my focus, background-threads should not open up modal dialogs.

However you could have a legacy option: Queue class from background threads and wait for a DoEvents from the main-thread to execute them. This would then cause a "black-screened" Guide. That would also be an alternative to the "dropping" of async calls to the Guide while the Guide is in focus.

Now I'm sure there is much not to like about this idea. But I think it's much easier to use for the common cases and will only cause "black-screen glitches" if you do somethink awkward. But it won't crash that easily.

re: Pumping the Guide

Kevin Gadd — Sat, 13 Jun 2009 11:31:09 GMT

After further consideration, I realized it was rude of me to talk about my Guide techniques without sharing them. So, I wrote an article with example source code that walks people through using my technique, and explains how it works:

http://www.luminance.org/code/2009/06/13/asynchronous-programming-for-xna-games-with-squaredtask

Hopefully people find it useful. (My pride is going to be terribly bruised if you respond and tell me how I'm misusing the XNA/.NET APIs, but I can take it, I swear.)

re: Pumping the Guide

CobaltHex — Sun, 14 Jun 2009 01:14:52 GMT

I'm working on a custom keyboard input panel, http://keyboardcontroller.codeplex.com/, that might be extended to a full input panel