Building upon my last spike, I put together a basic use of these new features in DX11. Again using SlimDX, this time to render a 16 control point bezier patch.
The fact that you can’t debug a Hull or Domain shader in PIX made getting this right a bit trickier. Hopefully, MS will resolve that in the next release.
The loss of my desktops SSD recently ‘inspired’ me to finally examine a simple graphical technique I’d previously never implemented: depth map shadows. I’d always read about the technique, and on the surface, it’s rather simple, but I’d never implemented it myself to really grok it. And since I was restricted to my laptop for a while and in a graphics mood, I had at it.
I also used it as an opportunity to hack out the basics of using SlimDX to get stuff on the screen. The first bit was mostly navigating through all the gotchas to get a cube and a plane rendering, then get them lit, then get them shadowed. Ultimately increasing my knowledge of DX11, SlimDX development all in one go with a one-off.
And what’s a graphics post without a demo video?
If you make the size of your buffer when batching simple primitives evenly divisible by 2 and by 3, you don’t need to do anything special if you have to flush before the user calls End().
I’m not much of an artist, but this might make an ok background in an in progress project.
In my projects, I’ve been using various Game State Management schemes generally derived from the pretty good XNA Game State Management Sample. (The rest of this post assumes you’re familiar with that particular implementation) Now, this sample incorporates a loading screen, which does the trick, but it is not animated; it does not launch a separate thread to load on while giving some visual feedback that the machine hasn’t locked up. Telling your users that you’re loading is only about half the point: indicating progress or at least animating something to tell them you haven’t locked up/died is the other half.
I’ve been thinking a bit about this problem lately, and I think the solution may be to redesign the GSM system to always assume a new screen is going to load slowly, therefore always showing the loading screen. The base GameScreen class should be placed in a loading state: the screen we are transitioning away from flips from it’s ‘normal’ state into a ‘loading’ state, and waits til the load is complete to actually transition off. With the base GameScreen just specifying the state, inheriting screens can customize how they display the loading on a per screen basis, or a intermediate class could be defined that just defines how loading is displayed in that particular game and all leaf node screens inherit from that screen. This makes for a very easy and clean way to make sure loading works the same way across the entire application.
Screens that load quickly will probably just blink from one to another without really displaying the graphic, and ones that are slow will automatically display the graphic. If the transition is bumpy, one could set a flag (loadingIsSlow = true) to indicate to use the second thread to load and show the loading screen.
The issues of XNA’s GraphicsDevice being thread safe need to be addressed, but that’s a different post.
I discovered some unexpected behavior while working on Shmup You this past week. On the Xbox 360, creating an infinite recursion via a property won’t cause a stack overflow exception. Instead, the screen will black, and the Visual Studio debugger will lose all symbols and stacks on every thread.
So this yields a black screen:
public int Foo
{
get{ return Foo; }
}
and not a stack overflow exception.
As we speak, I’m about half-way through the design phase of my capstone project here at RIT.
The capstone process for the Masters of Game Design and Development program I’m pursuing is divided into two phases: 1 quarter design and 1 quarter development. The goal of this process to create a fun game in groups within that 25 or so week period. We’re currently ending Week 5 of the 11 week design quarter. Spring quarter (starting in March) is when we will be developing this game, to be finished near the end of May.
I’ve formed a 3-person group with Joe Pietruch and Kelley Piering, and we form Imaginary Radius. We’ll be detailing our process at that link.
The end goal of our capstone is the production ‘Shmup You’, a competitive asymmetric shmup for the Xbox 360.
As mentioned previously, I was asked to plug my painterly work onto Shelf-Life. The results are not quite as good as I’d hoped, but it’s something.
Mesh-resolution independence is something I’d hoped I’d be able to produce, but the geometry shader output limitations prevent much subdivision. It means I can’t generate too many brush strokes for large triangles.
Over Thanksgiving Break, I started getting good painterly results under ‘controlled’ situations. Spheres and other simple structures with very regular geometry work very well.
You can see the indentations from the bump map show up as brush strokes on the final image, which is awesome.
The next thing Professor Egert asked me for, since this demo is working off the same base code as Shelf-Life, was to plug this onto Shelf-Life. That was accomplished before the end of Christmas break, and will be the subject of my next post.
In pursuing my painterly rendering project, I’ve generated the following as a kind of intermediate step.
Pixelized sphere
Kind of interesting, no?