This project is read-only.

Release Note

This is now ready for download and experimentation.  This version (March 17th, 2013) has a sample showing a compute shader in a graphics program - the program displays moving sprites, rendered in Z order, with the Z sorting done in a compute shader.  We have also fixed a problem with models (didn't handle 32 bit indices properly, especially wrt adjacency indices) and have a sample that shows a model with a geometry shader using triangle adjacencies, generating a silhouette edge.  No new youtube demos, but the first two are still there (tesselation demo: and first simple compute shader demo:  Feedback is welcome, especially looking for experience with the installer so that we can get it right.

Project Description

The goal of this project (JBBRXG11 - pronounced Jibber) is to extend Microsoft's XNA game development system to allow use of DirectX 10 and 11 features, in particular geometry, tesselation and compute shaders (shader model 5).  The initial motivation was for use in project work in graphics classes at Waikato University.  We have been using XNA in classes since 2007, however the fact that the course on shader programmng couldn't fully explore modern technology in XNA became a problem.  In 2011 one of us (Bill) built a first version of this project, based on Visual Studio 2010, XNA 3.1 and DirectX 10.  This allowed use of geometry shaders.  In 2012 the project was ported to Visual Studio 2010, XNA 4, and DirectX 11 by James.  The project is incomplete in a number of ways - some of which are detailed below, but it seemed that the best way forward was to open source the project and see if anyone else was interested and how it might make its way in the surprisingly extensive world of XNA cloning. 

The JBBRXG11 system is not intended to replace XNA.  It works as an extension, built using the XNA libraries, replacing those classes that access the graphics system with new DirectX 11 code via the SlimDX library (our thanks and appreciation to the SlimDX group).  That being said, it proved necessary to rewrite a good deal of XNA.  In theory all the input, sound and gamer code should still work, but so far we have only tested mouse and keyboard input.  It is likely that the video code will need replacement.

Unlike other XNA clone projects, it has not been a critical goal for us to retain exact source code compatibility - we are trying to extend, not duplicate.  The greatest change is the use of DirectX 11 HLSL.  XNA shaders will require modification - in particular to use the "SV_" semantics, the "technique11" techniques and the new texture sampling system.  There are some other minor extensions - to allow declaration and use of "stream out" buffers, new primitivetypes to allow for geometry shader adjacency data, and tesselation input sets.

There are two major issues with the current state of the project.  The first is that it was originally built using the XNA 3.1 API.  The task of converting to the XNA 4 API is still incomplete.  This means that Effect's still require "begin" and "end" calls (rather than just the XNA 4 "apply"); there is still RenderState (the separate BlendState, etc are implemented behind the scenes, and generated as needed from cached RenderState changes; but need to be exposed - for the record I liked being able to make settings like CullMode with a simple assignment rather than having to manage a state object); it is still necessary to manage VertexDeclarations, and lots of other bits and pieces.  It is our intention to work through these issues.  None pose obvious problems, in fact most simplify the library, but they will take time.  The second issue is incompleteness - we have implemented the classes (and parts of classes) that we needed.  There is lots still to do, to allow any arbitrary XNA projects to be ported. There are also minor issues.

The project has implemented new content pipeline paths for Textures (2D and cube), Effects, SpriteFonts and Models.  The model processor accepts .fbx files.  Its functionality has been extended over the XNA importer to process skeletal animation - so it is possible to ask a Model to perform an animation very simply in JBBRXG11.

There is a performance issue at present.  JBBRXG11 projects start up slowly - because they always compile about 4 large shaders to implement BasicEffect.  We haven't decided what to do with this at present - options are; to cache compiled code (???) or to eliminate Basic Effect (bad, because its variants include the ability to do GPU based skeletal animation and that allows small programs to have animated assets) or to provide a user switch (ok?) or to do lazy compilation (not good if it leads to a huge glitch during game play).

However - positives - we can use geometry shaders and tellelation.  Our compute shader system works.  We have skeletal animation built in.  Lots of XNA, but not all, really still works.

Last edited Apr 27, 2015 at 11:40 AM by coms0108, version 9