fullscreen mode

Mar 3, 2012 at 1:51 AM


I was wondering if there is a built-in way to trigger fullscreen mode?



Mar 3, 2012 at 4:57 PM

Most of the samples should work if you ALT+ENTER into or out of full screen mode.  The samples that use the RenderApplication as a base class should resize the appropriate render targets as well, but not all of them have been updated yet.  If you find one that doesn't work properly post it here and I will take a closer look at it.

Mar 4, 2012 at 4:29 AM
Edited Mar 4, 2012 at 4:30 AM

I've been lurking on this list whilst I (gradually) make my way through Jason's book (which is completely awesome btw).

I was briefly confused by this too, the key point is that this is automatically handled by DXGI. I think the behavior can be controlled by this call:
And I'm guessing you ask the question because you want to do it programmatically. Fortunately this is trivial:
SwapChainConfigDX11 Config;
Config.SetWidth( m_pWindow->GetWidth() );
Config.SetHeight( m_pWindow->GetHeight() );
Config.SetOutputWindow( m_pWindow->GetHandle() );
Config.SetWindowed(false); // go to fullscreen!
m_iSwapChain = m_pRenderer11->CreateSwapChain( &Config );
m_pWindow->SetSwapChain( m_iSwapChain );

Jason [Kinzer] (not to be confused with Jason Zink ;-)
Mar 4, 2012 at 4:37 AM
Edited Mar 4, 2012 at 6:38 AM

I have the book too but I didn't notice this. Thanks both Jasons!


Mar 4, 2012 at 6:47 PM

Thanks for the post Jason - that is really great.  Also, thanks for the comments on the book - I really appreciate your feedback! 

I'm not sure if you have access to the wiki or not, but if so, would you be willing to put a short page on it that describes what you need to do to start up in full screen?  If you don't have access, then I can of course add it in myself...

Thanks again for the post!

Jason (Zink) :)

Mar 5, 2012 at 3:20 PM
Edited Mar 5, 2012 at 3:21 PM

Sure thing: I'd be happy to help. My cursory examination didn't reveal an 'edit' button however. I don't know well, anything really, about codeplex, but I noticed in the 'what's new' an old bullet for 2009 that states: "We also introduced a[n] ... Editor role where this team member can only modify the wiki". So perhaps I would need to have this role to do so?

Yeah, I'm really enjoying the book and H3. I've been tearing my hair out b/c the other engines I've played with (e.g. Ogre) make it quite difficult to map concepts back to their fundamentals because of the layers and fallbacks; and if one only only cares about DX 10/11 this just serves to obscure (e.g. instancing is actually a simple concept but when an engine has to support pseudo-instancing for older cards, throw in GL support, and so on, things gets waaay more complicated). On the other hand tho using raw DX just feels like banging so many rocks together. So I think H3 hits the ideal level of abstraction here: not obscuring DX, but streamlining.

Oh, and as long as I'm hijacking the thread, I should note I'd love to see additional stuff (herewith follows the Christmas list). Stuff like LOD+imposter system or demo (C4 engine does this well), content pipeline support (XNA does this well, assimp may help a lot here), and additional demos showing simpler techniques like how to do skyboxes, how to reduce batch count using techniques such as instancing and texture arrays, how to render grass/clutter efficiently, and so on. Oh yeah, and I'd like my laptop gold-plated too. I'm more or less a neophyte atm, but if I end up doing some of this and it looks useful I'll definitely contribute back (this is code for "you may get pestered as I try to figure out how to do it" ;-)



Mar 5, 2012 at 11:07 PM

Congratulations - you are officially our first editor :)

Thanks for the comments on the engine.  Several others have also made the comments that it could use a few more basic concept type of samples and demos, so that is worth considering.  At some point I would like to add some additional content to the book (either in a second edition, or perhaps as a free download) that addresses the beginner stages in a bit more detail.

The topics that you mentioned sound like a good variety - perhaps we should create something in the wiki for requested samples?  That way as people develop them, or we get some free time, then we can try out building the samples and adding them into the engine distribution.

Thanks again for the comments, and I would encourage you (and anyone else out there) to write a review on Amazon for the book.  Good or bad, your opinion will help others decide if the book is right for them or not!

- Jason

Mar 6, 2012 at 2:10 AM
Edited Mar 6, 2012 at 2:22 AM

Ah ha, I have an 'edit' button now. (the power... the power!)

I added that and -- as a service to the lazy and/or those who don't have doxygen+dot installed -- a link to a chm that I find vaguely useful on occasion while going through the book. The only thing I did was modify the doxygen cfg file and appropriately resize the hieroglyph icon, so nothing special... perhaps the sort of thing best to not bother with if it's not integrated into the build process, but will leave it as-is for now anyway.

I also took the liberty of restructuring the main page into something that may scale better (under the optimistic assumption more will be added). This was based on roughly 3 seconds of thought, so I won't be offended if you go back to what you had before if that made more sense to you ;-)

That sounds great re: examples and additional content. I will begin formulating my wishlist more precisely. I have every intent on trying my hand at some demos as soon as finish the book. If (when) I do I'll plan on posting them and would greatly appreciate expert (i.e. your) criticism on how the solution can be improved.

BTW, on a somewhat related note, do you have a rough roadmap of sorts for what you want to add/improve on the engine?

- JK

Mar 7, 2012 at 10:13 PM

Those are some good updates - thanks for making them.  I also appreciate the doxygen file, and we may have to discuss how to integrate that into the engine distribution.  I'm no expert in doxygen, but it would be a good thing to add support for.  If you are interested in contributing in this area, please send me a email!

I do have a rough roadmap, but I haven't explicitly written it out just yet.  I can add that to the wiki though, and then open it up for comments to see what is important to you guys for it.  Hopefully over the next few days I can get that in there...

Mar 8, 2012 at 1:19 PM
Edited Mar 8, 2012 at 1:20 PM

I'd be happy to help. My experience is mostly with makefiles so probably the only question is how to integrate into the VS solution/MSBuild process. Hopefully relatively trivial... and barring that a manual batch file could of course be whipped up in minutes.

(And thanks for the roadmap - it's always nice to know where the author see things headed)

Mar 9, 2012 at 10:54 AM

I typically use the pre- and post-build events system in Visual Studio for copying files around and things like that.  This more or less uses a command line reference to do what you want to do.  The only concern I would have with putting it into these events is that the docs would be generated every time someone compiles the engine, which may not be optimal.  I'm open to suggestions for integration if anyone has ideas about what the best way to make it easy to generate the docs are, without the requirement to build it every time...

About the roadmap - it doesn't have to be just me :)  I like getting feedback and suggestions from others, so keep in mind that it will be a very "live" roadmap!

Mar 11, 2012 at 4:01 AM
Edited Mar 11, 2012 at 4:02 AM

Agreed: exactly never would I want to rebuild the documentation on every compile (especially with the doxygen config I have at the moment, it takes a good minute or so). From what I can see there are 2 basic approaches one could take:

1 - Create a post-build step for each desired project and a new configuration (in addition to the standard debug/release) and then enable the step only for that configuration.
2 - Create a new dummy project and with the post-build step and it can simply be enabled/disabled in the configuration manager and/or (re)build explicitly as one would build any project
I've opted for (2) as it's trivial to setup and easy to manage (simply go into configuration manager and just selecting documentation project if you want it, or rebuild it explicitly if desired).
Following is a link to a project called 'Documentation' that is meant to be copied into the Source directory and then added to the solution. Probably by default it should be switched off...
Note it contains the required resources and generates into a directory called Api under the main directory. Also note the doxygen config file assumes dot is in the path, and htmlhelp is in the standard location ("C:\Program Files (x86)\HTML Help Workshop\hhc.exe"). We might want to tweak it for more of a 'minimal' build so it's faster and has fewer dependencies (no dot, no chm, only public api).