Effect API changes in XNA Game Studio 4.0


Where in previous XNA versions you used to write:

    effect.Begin();
    effect.CurrentTechnique.Passes[0].Begin();

    DrawStuff();

    effect.CurrentTechnique.Passes[0].End();
    effect.End();

With Game Studio 4.0 this becomes just:

    effect.CurrentTechnique.Passes[0].Apply();

    DrawStuff();

What in previous versions would be:

    effect.Begin();
    effect.CurrentTechnique.Passes[0].Begin();

    DrawStuff();

    effect.Parameters["lives"].SetValue(9);
    effect.CommitChanges();

    DrawOtherStuff();

    effect.CurrentTechnique.Passes[0].End();
    effect.End();

Is now:

    effect.CurrentTechnique.Passes[0].Apply();

    DrawStuff();

    effect.Parameters["lives"].SetValue(9);
    effect.CurrentTechnique.Passes[0].Apply();

    DrawOtherStuff();

Editors note: if you profile the new Apply method with the 4.0 CTP, you may notice it is slower than the old CommitChanges. Don’t worry: this is just a temporary state of affairs due to some missing optimizations that didn’t make it in time for the CTP release.

We also took out a bunch of stuff:

  • Removed the low level shader APIs (VertexShader, PixelShader, SetVertexShaderConstant, SetPixelShaderConstant, GetVertexShaderConstant, GetPixelShaderConstant, ShaderConstantTable, ShaderProfile, ShaderRegisterSet, and ShaderSemantic). These duplicated the same functionality that is also available using Effect and EffectParameter, but in a form that was closely tied to DirectX 9, and which could not be efficiently implemented with DirectX 10 or 11. Effects provide an abstraction that sits naturally on top of multiple native layers, and the vast majority of our customers preferred the Effect API in any case.

  • Removed EffectPool. This was confusing, and turned out to be nowhere near as useful as it seemed on the surface like it ought to be.

  • Removed EffectParameterBlock. This looked like it could be a useful optimization technique, but in fact always made things slower anytime anyone tried to use it :-) 

  • Removed assorted other boring and rarely used doodads (EffectFunction, Effect.Creator, EffectParameter.SetArrayRange, and EffectTechnique.IsParameterUsed).

Finally, we upgraded to a more recent version of the Windows HLSL compiler, which means that:

  • You can use newer HLSL features such as loop control attributes.

  • Shader model 1.x is no longer supported. Game Studio 4.0 requires at least shader model 2.0.

Comments (37)

  1. Yes! Updated HLSL compiler, 4 years coming, but we got there in the end 🙂

  2. Jamie says:

    Those are great changes but I am sad to see the Effect.Creator go i have used that in the past.

    Now what we really need is syntax highlighting and intellisense for effect files!

  3. MischaW says:

    Ah great to see it’s getting more and more DX10 and 11 ‘compatible’. DX10/11 support in xna 5.0?

  4. PolyVector says:

    YAY! A newer HLSL compiler! *tears of joy* 😀

    Shawn, if you don’t stop mentioning DX10 you’re going to get nerds spreading baseless techulation on their blogs, hehe. 😉

  5. FieldsOfCarp says:

    Just a note on something I found yesterday.

    The new HLSL compiler doesnt like using "PixelShader" as name for the errr pixel shader routine.

  6. ShawnHargreaves says:

    > The new HLSL compiler doesnt like using "PixelShader" as name for the errr pixel shader routine.

    Yeah, apparently that counts as a reserved keyword now.

    You wouldn’t believe how many of our unit tests this particular restriction broke! Seems like a lot of people chose that as the name for their shader function 🙂

  7. David Black says:

    Will there be any new options for the effects processor and/or allow overriding the effects processor and the routines to choose compiler options?

    I find it rather painful that I have to basically re-impliment the effects processor/error handling/line numbering etc. Just so I can do things like disable specific optimizations.

    Which is very important to work around bugs in the effects compiler, admitedly most of the current bugs I run into have probably been fixed in the newer version, but still…

  8. Shawn, is it still possible to compile with the old fxc and load in an effect with a byte[]?  For SM1.1 compatibility?

  9. ShawnHargreaves says:

    > is it still possible to compile with the old fxc and load in an effect with a byte[]?  For SM1.1 compatibility?

    This is not possible. There is no way to use 1.x shaders with XNA 4.0, and thus no way to run 4.0 games on 1.x shader hardware.

  10. David Black says:

    In fact, is a custom effects processor possible with 4.0.

    eg this could be a problem if I cant create an effect from a byte array and the effect compilation function are not present(although this could be worked around using interop). Also, not sure if it is just my system, but using the function to compile an effect from a file instead of memory has never worked.

  11. Jon Watte says:

    > Shader model 1.x is no longer supported. Game

    > Studio 4.0 requires at least shader model 2.0.

    Yess!!!

    Will all effects live in the same pool now? Or can I no longer use "shared" variables?

  12. ShawnHargreaves says:

    > Will there be any new options for the effects processor and/or allow overriding the effects processor and the routines to choose compiler options?

    That’s currently my next-but-six blog topic (I have a giant list of stuff I want to write about, slowly working my way through it all 🙂

  13. David Black says:

    >>>That’s currently my next-but-six blog topic (I have a giant list of stuff I want to write about, slowly working my way through it all :-)<<<

    Cool, I thought we must be getting to the end of the 4.0 blog topics by now:-)

    Hmmm, looking at the CTP docs, it does seem possible to disable optimizations. Which is a little blunt, just disabling all optimizations.

    However I guess it is a whole other topic if fxc optimizations are a benefit at all since the drivers are rumoured to do a bunch of optimization themselves….

  14. ShawnHargreaves says:

    > Cool, I thought we must be getting to the end of the 4.0 blog topics by now:-)

    No end in sight yet I’m afraid 🙂

  15. nice ,,

    shawn is there support for a ealy out to save the compute

    if(somthing)

    return

    and can you post more about the xbox360 special feutures of shaders

  16. Jack says:

    How do shared effect parameters work now?

  17. Jack says:

    If I want to use a newer fx compiler (in the future) will I still have to use jwatte’s custom effect content processor? Or can the fx compiler version be configured in Game Studio?

  18. default_ex says:

    About the effect pool being removed. Does this mean our shared parameters will not function as expected?

    And have ya considered pointing the error messages at include files when they come from them? It’s kind of confusing at first when you double click an error message that says it came from line 20 of a include file, but it takes you to line 20 of the effect file.

  19. Frank Purse says:

    Hi Shawn,

    Is there going to be an updated xna 3.2 to allow existing windows projects to be used within vs2010; out of the box?

    Though currently I can get most of my projects working in vs2010 by frigging it; I cannot get it to compile any effects.

    Are there any actual dates when a xna version will be supported with the newer vs?

    Is it correct that xna 4.0 is just for mobile development?  Looking on the web this seems a bit unclear and there seems to be confusion?  Can I also target windows with 4.0?  Thank you.

  20. XNA 4.0 is for all Paltforms exept Zune. But the CTP is just for Windows Phonne.

  21. ShawnHargreaves says:

    > How do shared effect parameters work now?

    They don’t (or rather, they work just the same as any other parameter: the "shared" keyword is ignored). We removed support for effect pools.

  22. ShawnHargreaves says:

    > If I want to use a newer fx compiler (in the future) will I still have to use jwatte’s custom effect content processor?

    As of 4.0, the XNA effect format is no longer exactly the same as native D3DX (we added some extra metadata that speeds up various runtime operations) so you can only compile XNA shaders using XNA. Effects compiled with other versions of fxc will not work in XNA.

  23. ShawnHargreaves says:

    > Is there going to be an updated xna 3.2 to allow existing windows projects to be used within vs2010

    No. Game Studio 3.1 integrates with Visual Studio 2008. Game Studio 4.0 integrates with Visual Studio 2010.

    > Is it correct that xna 4.0 is just for mobile development?

    Incorrect. Game Studio 4.0 supports Windows, Xbox, and Windows Phone.

  24. David Black says:

    I noticed a number of people talking about shared parameters, I would be really interested to know if they actually provide any sort of performance gain.

    This is something I have been thinking about supporting for a while, since eliminating the need to set parameters in general has proved quite a performance gain. (eg adding lazzy lights which only set parameters when lights move or per instance materials so I dont need to update world transforms etc).

    I guess there will be no choice if I want to move to XNA 4, but more of the reasoning behind the removal would be good. Perhaps it would even provide insight into further optimizations…

  25. Can we still load in shaders from files/strings during runtime?  

    This is how my winforms particle editor works.

    It also makes playing around with and testing shaders much easier.

  26. ShawnHargreaves says:

    > Can we still load in shaders from files/strings during runtime?  

    On machines that have the full Game Studio installed, yes (stay tuned for my next-but-N post when I get around to talking about that).

    On machines that just have the XNA Redist, no.

  27. Shawn i have a ?

    The pixelprocessor in xbox360 can you speed up things here

    like you a surtend amount pipelines that are decated to vertex processing and a surdent amont decated to pixel processoring

    a realy big request 70% of pipelines to pixel processoing and 30% to vertex processoing

    Best Regards

    Michael Hansen

  28. Gabriel Reiser says:

    Shawn,  removing EffectPools and Semantics completely breaks my game engine Reactor 3D.  I use Semantics to feed variables to 3rd party shaders and I do this using EffectPools for shared variables like CameraPosition.  I love Semantics!  I have a bunch of prebuilt shaders in my engine but expose a way to set effects on meshes, actors, landscapes, particles, etc.  I force my users to use Sematics to I can set variables for them that aren't available in the public api.  Removing Semantics means everyone must conform to my EffectParameter naming conventions…  something I think should have to be done.  I like that you guys updated the Effects API but removing the 2 most useful aspects of HLSL is nonsense!

  29. ShawnHargreaves says:

    Gabriel: I think you misread this article. We did not remove effect semantics. Pools are indeed gone however.

  30. Quang Anh says:

    What about Effect.End()? No need anymore? Then how can I stop using an Effect?

  31. ShawnHargreaves says:

    There is no such concept as "stop using an effect". You just apply whatever effect you want to use, then draw stuff. If you later want to draw stuff using a different effect, applying that other effect will replace the first (assuming both effects set the same underlying device states, anyway).

  32. seanjames says:

    What happened to the "Border" address mode? It says that it's deprecated now in the compiler… "The effect state 'BorderColor' is obsolete and can no longer be used." Trying to assign "border" to the AddressU or AddressV values gives the error "The effect state 'AddressU' was assigned an invalid value." Did something change? The HLSL docs still list border as an address mode.

  33. ShawnHargreaves says:

    > What happened to the "Border" address mode?

    Border addressing is not supported in Game Studio 4. Details here:

    blogs.msdn.com/…/state-objects-in-xna-game-studio-4-0.aspx

    And some background here:

    blogs.msdn.com/…/breaking-changes-in-xna-game-studio-4-0.aspx

  34. John Doe says:

    > There is no such concept as "stop using an effect". You just apply whatever effect you want to use, then draw stuff. If you later want to draw stuff using a different effect, applying that other effect will replace the first

    What should I do if I want to draw some stuff with an effect, and later want to draw stuff using no effect at all? Even if there is no such concept as "stop using an effect", I am sure you understand what I mean. 🙂

  35. ShawnHargreaves says:

    > later want to draw stuff using no effect at all?

    That makes no sense. You can't draw anything without using an effect, any more than a painter could paint something without using any paint or a printer could print something without any ink.

  36. John Doe says:

    >That makes no sense. You can't draw anything without using an effect, any more than a painter could paint something without using any paint or a printer could print something without any ink.

    could I translate that as "call spriteBatch.End() and then spriteBatch.Begin() again"?

    I am sure my terminology is not precise… but that does achieve the effect of 'drawing with no special effect'…

  37. ShawnHargreaves says:

    SpriteBatch uses an effect internally, as does anything that draws graphics via the GPU.

Skip to main content