Bryan's profileBryan's spaceBlogListsNetworkMore  |  Tools Help |
Bryan's spaceGame development/Graphics/DirectX/XNA |
||||||||||||||||||
|
Games I've made using XNA
|
March 25 XNA Sample : Skinned Model InstancingI created a sample on Skinned Model Instancing using the XNA Framework. It shows how you can use instancing techniques in order to draw very large amounts of independently animated characters at once.
The basic idea is to use a texture to encode all the animations, and then use standard instancing techniques to send both transformation data and an animation frame index, and then look at the texture using vertex texture fetch to pull the animation data out, and finally use that animation data to apply traditional skinned animation.
In the sample, you're in arena filled with a bunch of dwarves. If you move close the dwarves, they'll start cheering for you. If you move even closer, they'll get so excited they'll start jumping in the air!
Sample:
Paper:
The code is well commented and thus the paper is simply an optional read to give you a high level overview of how this all works.
 The inspiration for this came from an nVidia developer sample on skinned model instancing in DirectX10 - Bryan Dudash wrote an awesome sample about it.
Thanks to Bryan & nVidia for allowing use of the dwarf and arena art assets for this sample!
If any of you need lots of 3-D animated characters in your XNA game, I hope you find this useful!
The sample is Xbox 360 only, but there is no technical reason you can't implement this on a PC. I simply don't have a graphics card that supports vertex texture fetch on hand right now, so there is no way for me to test a PC version. All the hard work is done - you just have to implement hardware or shader instancing and use the same technique as is done in the sample. If you have questions about it or need help let me know!
UPDATE: Ingo found a great bug on xboxes with German language - the positions don't get read properly and therefore you don't see any dwarves. I have a fixed version but the uploader isn't giving me any love, so in the meantime if you run into that issue please follow his fix in the comments ;-) Thanks to Ingo for finding & solving that! March 23 QuarxQuarx is my 5th game utilizing the XNA framework, and my first game on the Xbox 360. I'm a big fan of Dr. Mario, and really like the multiplayer, so I wanted to bring that sort of fun and intensity to the Xbox. Luckily, my brother decided to help out with the artwork, and we had a game going in a short time.
There were some interesting things about the project. I used Quarx as a project to test my UI editor to the extreme, and identify things that needed to be changed. All in all, I feel that AnarchyX really helped enable Quarx and give us a very polished and robust UI. I believe that the turnaround time for creating UI for Quarx was much, much faster, due to the following things:
Also, I was able to pinpoint some weaknesses in the framework and bugs and fix those for our next project. Graphically, the game isn't too impressive. However, the gameboards are actually rendered in 3d to a rendertarget. Post processing effects are applied (a weird bloom effect/gaussian blur). Also, when you lose, a special effect is played which makes the atoms fly apart. Most people probably wouldn't even realize its rendered in 3d. The AI was an interesting challenge. Initially a did a depth-first search of solutions based on all the possible places the current piece could end up. Turned out this was way too expensive :-) I setled on a heuristic based algorithm where I look at all the potential moves you could make from the top (so unfortunately the AI doesn't know "complicated" moves like sliding the piece under other atoms ), but it seemed to work fairly well. It was also very cheap. The AIs are pretty well balanced and the hard difficulty level is challenging. The puzzle mode was also challenging, in creating puzzles. My brother and both contributed puzzles to the game. It actually took a lot longer than we both expected to come up with all the puzzles for the game. I think people enjoyed puzzle mode though :-) It was a blast developing a game on the Xbox360. The XNA team did a very good job of making the development experience on the XBOX as pleasant as possible. It was also interesting just the number of bugs we found while we were going through our final test passes and how many "little" issues were found. There gets to be a lot of test cases and there can be a lot of interesting issues - since you have to handle all kinds of events, like controllers disconnecting, storage devices connecting/disconnecting/not being connected at all, players signing in and out at any point in the game, etc. One thing I wish we would've implemented was something that is pretty standard in most Xbox games - an initial starting splash screen that just says "Press Start". This lets the game know which controller is the "primary" controller. This would've been nice for us and would've added a little polish - currently, every controller is the primary controller :-( We thought about adding LIVE functionality but decided against it because we weren't sure it would be worth the extra time investment. It was probably a smart move because I don't think many people have tried or bought our game (of course, you might argue that if it had LIVE support, it might be a different story - I'm not sure about that). Anyway it was a lot of fun to develop. One criticism is that its too expensive - $5. We feel that you get a pretty good value considering you get multiplayer, puzzle mode, and can play against computer players. However at the same time we'll probably lower the price to $2.50 at the end of March to try and get more people to try it :-) If you're reading this... you should check out our game!
FileSystemWatcherAll in all, i love .NET. It makes things so easy. Classes logically encapsulate behaviors and it is a breeze to simply use Intellisense to find the functionality you are seeking.
I've only found a few (VERY few) exceptions in .NET that have made things harder for me. One such exception is the FileSystemWatcher. Just looking at its interface, it looks great - I give it a path, and a filter, and it sends me event notifications when things have changed! Friggin sweet! I've used the FileSystemWatcher successfully in several apps. One such app was a level editor for an XNA XML format. It was pretty cool - you'd change the XML, or a file referenced by the XML, and whenever FileSystemWatcher detected a change, it would reload the level. This makes it really easy to iterate and improve the level. However, there is some behavior that happens under the hood and dependency on threading + the thread state apartment of the current thread that isn't intuitive or obvious. Also, it is not very well document, and it is difficult to troubleshoot why it is not working (besides trying a bunch of things :-) )
I've found that with FileSystemWatcher - I get one of two scenarios. It either works, or it doesn't.
When I first tried to use FileSystemWatcher, the events didn't fire like I expected. I found the first error - I hadn't set "EnableRaisingEvents" property to true. This was easy enough to fix, however, I hadn't expected that I needed to do this based on other .NET classes with event handlers, like WinForms classes. Not a big deal though and understandable that you may want to control this functionality.
However, after enabling that, FileSystemWatcher still didn't fire events for me. I was sort of upset - I did everything I needed to, right? Turns out not. For whatever reason, maybe due to the Win32 API calls FileSystemWatcher makes, I needed to declare my app as running in single threaded apartment mode. This is kind of crazy too because as far as i know in .NET 1.0 apps would be run in STA by default. I could imagine some peoples apps breaking between .NET 1.0 and .NET 2.0 because of this. I added [STAThread] to my main function and everything was peachy, which was great, but it was tough to find info about why I needed to do that. I recently ran into a similar issue again. This time, I was creating a custom designer for an XNA panel in AnarchyX. The panel is called an "XMLLayoutPanel", its basically the AnarchyX equivalent of XAML. You supply a data file to it, in XML, and it creates the panel accordingly. One feature i wanted for this was simply design time editing - you should be able to have the UI editor, and the XML data file, open in the editor, and every time you save the XML it will refresh the editor window.
So this is cool, and sounds straightforward to implement. I'll just hook the designer ComponentChanged event, look for the property "DataFile" being changed, and when its changed, I'll have a FileSystemWatcher monitor the actual live file for changes, and redraw it after each change. Should be straightforward and maybe 20 mins of coding, max.
Turns out.. it wasn't. I set up my FileSystemWatcher as described above - setting the path, filter, EnableRaisingEvents, etc. Nothing was happening. No events fired. I was a sad man. In this case, I had no way to change the apartment state of the thread, because its the component designer in visual studio and I was worried about causing destabilizations or creating hard to find bugs (and actually I don't think you can set the apartment state again, while its running anyway). Too bad I didn't have a Main() function I could put [STAThread] on to save the day :-D
I found out, though, that FileSystemWatcher has a property called SynchronizingObject. This gives an ISynchronizingObject which can fire the event on (like Control.Invoke). This is what you need to use for Cross-Thread calls between WinForms objects to get the call to happen on the object's control. So that makes sense - I'll give FileSystemWatcher a synchronizing object on the thread i'm running and everything should be alright. I thought this was going to save the day for me. For AnarchyX, I use a class derived from Control to host the designer window. This implements ISynchronizeInvoke, and should get the event fired on the proper thread. So I set the SynchronizingObject to that by calling IRootDesigner.GetView(), and thought my problems were over.
Unfortunately... didn't work. Still a mystery to me why I couldn't get the FileSystemWatcher to work in this instance, in design time.
I resorted to an alternative solution of creating a thread using System.Threading.Timer, checking to see if the last write date of the file had changed since last time we polled (every 1s or so), and if so, reload the XML panel. This seemed to work OK but was not as nice of solution as just usinig the prepacked FileSystemWatcher :-) It kind of was a hack - if I set the poll time to 100 ms, i would get errors on saving the file ("file is already in use"). Setting the poll time to 1s or greater seemed to give acceptable results.
July 23 Megatexturing and new UI stuff..I've waylaid megatexturing for now. The work to payoff is not very high. The reason is that, although a very cool feature; for indie games it is not so practical. Especially XNA games which have to be less than < 150 MB. Therefore, i'll be focusing more on other projects.
My current project is creating a windows designer for my UI system. Its very promising, Stephen Styrchak's blog has some great info about getting started.
Before I knew it was even possibel to create a windows designer, I built an editor into my engine, which could be accessed during run time by pressing a key combo (like ctrl-E or something). It let you do some stuff like move and resize elements, and save and load panels from XML.
However, this windows designer stuff is way cooler. You get to leverage things like the Property Editor, toolbox, etc - basically for free. And it serializes your components into code, which is awesome. There is no "magic" happening - whenever you make a change to the UI you can see the corresponding code. In addition, code serializaiton is way faster at run time - the Xbox XML deserialization is very slow, and writing content writers for XML gets tedious. You can't get much faster than code serialization because there is nothing to be loaded (besides the assembly of course) at run time.
So I'm really excited about this. There has been all this talk about .NET enabling "Rapid Application Development" - I'm hoping things like this could bring "Rapid Game Development" to the masses.
i'll have a video soon =) Public folders
|
|||||||||||||||||
Send a private message
Subscribe to RSS feed
Tell a friend
Add to My MSN
Add to your network
Sign up for alerts
|
|
