Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm am working on a collection of games for a custom digital tabletop installation (similar to Microsoft Surface tables). Each game will be an individual executable that runs full-screen. In addition, there needs to be a menu/shell overlay program running simultaneously. The menu/shell will allow users to pause games, switch to other games, check their game history, etc.

Some key requirements of the shell:

  • it intercepts all user input (mainly multitouch) first before passing it on to the currently running game (so that it can, for instance, know to pop-up at a "pause" command);

  • can reveal on arbitrary portions of the screen, with the currently running (but presumably paused) game still showing underneath, ideally with its shape/size being dynamic, to allow for creation of an animated in/out drawer effect over the game.

I'm currently looking into different architectural approaches to this problem, including Fraps and DirectX overlays, but I'm sure I'm missing some ways to think about this. What are the main approaches I should be considering?

(Note the table is currently being run by Windows PC, but it could potentially be a Linux box instead. By this I don't mean I need an OS-agnostic solution. I'd be happy with a Windows-specific solution. But I would be willing to consider switching to Linux and using a Linux-specific solution if it's much easier to achieve this in Linux.)

share|improve this question
2  
+1 nice to have some different questions about. –  Nick Wiggill Oct 28 '12 at 13:48
add comment

1 Answer

I don't think there's much to evaluate, really. Performance / responsiveness comes first, especially on an installation of this sort. You can use either DirectX or OpenGL deferred rendering / render-to-texture (RTT).

To do so, render the shell underlay to the default frame buffer (the front / onscreen buffer), render your active game overlay to a screen-sized quad, shift this quad to the appropriate position in world space as per current status of "drawer" transition, then render it's to the default frame buffer as well. You now should have the active game laid over the shell, and it's a very rapid operation and thus lends itself to slick transitions (given some nice interpolation math).

Re interactions, you can even make the under/overlay hit detection pixel-perfect if you read back the RTT data to CPU-side, per frame. In that case, you'd need to return at least the overlay buffer as a cheap, 1-bit mask RTT.

EDIT Another way is to go fully browser based, as you can do full screen mode. You could load the games in as modules rather than having separate "programs". The problem with the browser is you aren't going to get the same performance. You could still use WebGL (since you would have control over which browser you'd be using) for layering and fast graphics, but the games would need to be simple. Aside from performance, it might be a fair bit easier to develop this way, and still OS-agnostic.

share|improve this answer
    
Let me know if you have any questions ;) –  Nick Wiggill Oct 28 '12 at 16:59
    
Thanks! And just to check, this approach will work with the shell and individual game running as separate programs? –  Ghopper21 Oct 28 '12 at 20:55
    
Nope. One way or another, one and only one process is going to be able to get access to the GPU device context. The only way I can see you doing this otherwise, is to forego 3D acceleration together -- which I would not recommend. The other thing is this: If you're not yet sure whether you'll be going Win or Lin, with this approach that's okay. Whereas if you were to pick some OS-specific approach, then change to the other OS later, that might render the first approach obsolete and possibly not even replicable on the newly-chosen OS. I suggest waiting for further answers / ideas. –  Nick Wiggill Oct 28 '12 at 21:18
    
@Ghopper21 See my edit for a different tack. –  Nick Wiggill Oct 29 '12 at 9:33
    
Thanks Nick for the browser solution. I think I want to avoid that because of performance and other issues. But from your note I realize I was unclear about the Windows versus Linux part. I'll clarify in an edit to the question. –  Ghopper21 Oct 29 '12 at 12:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.