Skip to main content
added 425 characters in body
Source Link
Andrew Russell
  • 21.3k
  • 7
  • 57
  • 103

No. There's no official way to do this in the API.

If you were insane, you could perhaps use reflection to get at the underlying DirectX objects, and then trick them into reusing a window and triggering a content reload at the right time. (Only one device context can be attached to a window at a time, basically)

You could let them have separate windows. Although that could introduce issues, especially if they both need to be full-screen.


You should build your mini game and your main game into separate classes within the same program. Each of those classes should have Update, Draw, Initialize, etc methods. You should then have some kind of master controller to call those methods to have only one game active at a time (this could also simply be in your main game class).

You can use separate content managers for each game/mini-game, allowing you to unload the content for each of them once they're done.

Consider looking at the Game State Management sample.


To answer your edit:

Yes. A kind of plugin system like this should work just fine.

Be aware that, once loaded into a process, you won't be able to unload the plugin DLL without unloading the whole process - although you can unload its resources in the usual way. (Note for anyone else coming across this: You can unload when using AppDomains, but I am reasonably sure that this won't play nicely with XNA.)

No. There's no official way to do this in the API.

If you were insane, you could perhaps use reflection to get at the underlying DirectX objects, and then trick them into reusing a window and triggering a content reload at the right time. (Only one device context can be attached to a window at a time, basically)

You could let them have separate windows. Although that could introduce issues, especially if they both need to be full-screen.


You should build your mini game and your main game into separate classes within the same program. Each of those classes should have Update, Draw, Initialize, etc methods. You should then have some kind of master controller to call those methods to have only one game active at a time (this could also simply be in your main game class).

You can use separate content managers for each game/mini-game, allowing you to unload the content for each of them once they're done.

Consider looking at the Game State Management sample.

No. There's no official way to do this in the API.

If you were insane, you could perhaps use reflection to get at the underlying DirectX objects, and then trick them into reusing a window and triggering a content reload at the right time. (Only one device context can be attached to a window at a time, basically)

You could let them have separate windows. Although that could introduce issues, especially if they both need to be full-screen.


You should build your mini game and your main game into separate classes within the same program. Each of those classes should have Update, Draw, Initialize, etc methods. You should then have some kind of master controller to call those methods to have only one game active at a time (this could also simply be in your main game class).

You can use separate content managers for each game/mini-game, allowing you to unload the content for each of them once they're done.

Consider looking at the Game State Management sample.


To answer your edit:

Yes. A kind of plugin system like this should work just fine.

Be aware that, once loaded into a process, you won't be able to unload the plugin DLL without unloading the whole process - although you can unload its resources in the usual way. (Note for anyone else coming across this: You can unload when using AppDomains, but I am reasonably sure that this won't play nicely with XNA.)

Source Link
Andrew Russell
  • 21.3k
  • 7
  • 57
  • 103

No. There's no official way to do this in the API.

If you were insane, you could perhaps use reflection to get at the underlying DirectX objects, and then trick them into reusing a window and triggering a content reload at the right time. (Only one device context can be attached to a window at a time, basically)

You could let them have separate windows. Although that could introduce issues, especially if they both need to be full-screen.


You should build your mini game and your main game into separate classes within the same program. Each of those classes should have Update, Draw, Initialize, etc methods. You should then have some kind of master controller to call those methods to have only one game active at a time (this could also simply be in your main game class).

You can use separate content managers for each game/mini-game, allowing you to unload the content for each of them once they're done.

Consider looking at the Game State Management sample.