Effect API changes in XNA Game Studio 4.0

Effect API changes in XNA Game Studio 4.0

  • Comments 37

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.
  • How do shared effect parameters work now?

  • 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?

  • 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.

  • 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.

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

  • > 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.

  • > 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.

  • > 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.

  • 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...

  • 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.

  • > 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.

  • 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

  • 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!

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

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

Page 2 of 3 (37 items) 123
Leave a Comment
  • Please add 7 and 2 and type the answer here:
  • Post