Coffeehouse Thread

38 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Interview with XNA Team

Back to Forum: Coffeehouse
  • User profile image
    tina10

    I am interviewing a few of the members of the XNA team next week and want to ask them your questions.  What would you like to ask them?

  • User profile image
    magicalclick

    How easy is it to tap into GPU accellerated physics? DX11 can do GPGPU, so, any plan that doing GPGPU physics is easier on XNA? Sorry for the dumb question, I am not familiar with XNA developmet.

     

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    W3bbo

    Give us some history of XNA, back to the MDX roots. I remember reading how MDX was started as Tom Miller's personal side project before the execs took notice (since DirectX-for-VB6 was outdated). If this is correct, can you flesh out the details?

     

    Also: XNA supplanted MDX, but it leaves developers without an officially sanctioned simple and lightweight API for adding multimedia functionality to Managed non-game applications. Case in point: I was porting some C++ code to C# which included some code to control a robot with a gamepad, I had to use the certifiably ancient WinMM Joy* functions because XNA was inappropriate and SDL.NET/Tao had an unworkable build process. (Please, no comments about MSRS).

     

    Also, will the whole DirectInput/XInput thing be sorted out soon?

  • User profile image
    BitFlipper

    What kind of work is being done to improve the GC? The current GC is not ideal for use in something like games where a GC cycle can cause an interrupt long enough to cause noticeable frame dropping. If this wasn't a problem, then people would not come up with some horrific hacks in order to do simple things like write integers to the screen. Notice in that "solution", they get access to the private string that is embedded in StringBuilder in order to have a mutable string that doesn't create garbage when changed. And how would you write floating point numbers to the screen without creating garbage?

     

    Specifically, I think an incremental GC would work better. There might be slightly more overhead, but that is a good compromise if things run smooth otherwise.

     

    It is nice to use .Net for something like games, but it is a drag that we need to use Reflector to figure out which classes and methods are going to create garbage. It kind of takes away from what makes .Net great if you have to program like that.

     

    Does the XNA team have any say in the GC development? I believe XNA is a good opportunity to showcase improvements in the GC in this regard. These kinds of improvements can help in non-game development as well.

  • User profile image
    Minh

    W3bbo said:

    Give us some history of XNA, back to the MDX roots. I remember reading how MDX was started as Tom Miller's personal side project before the execs took notice (since DirectX-for-VB6 was outdated). If this is correct, can you flesh out the details?

     

    Also: XNA supplanted MDX, but it leaves developers without an officially sanctioned simple and lightweight API for adding multimedia functionality to Managed non-game applications. Case in point: I was porting some C++ code to C# which included some code to control a robot with a gamepad, I had to use the certifiably ancient WinMM Joy* functions because XNA was inappropriate and SDL.NET/Tao had an unworkable build process. (Please, no comments about MSRS).

     

    Also, will the whole DirectInput/XInput thing be sorted out soon?

    Why couldn't you use XInput?

  • User profile image
    Minh

    BitFlipper said:

    What kind of work is being done to improve the GC? The current GC is not ideal for use in something like games where a GC cycle can cause an interrupt long enough to cause noticeable frame dropping. If this wasn't a problem, then people would not come up with some horrific hacks in order to do simple things like write integers to the screen. Notice in that "solution", they get access to the private string that is embedded in StringBuilder in order to have a mutable string that doesn't create garbage when changed. And how would you write floating point numbers to the screen without creating garbage?

     

    Specifically, I think an incremental GC would work better. There might be slightly more overhead, but that is a good compromise if things run smooth otherwise.

     

    It is nice to use .Net for something like games, but it is a drag that we need to use Reflector to figure out which classes and methods are going to create garbage. It kind of takes away from what makes .Net great if you have to program like that.

     

    Does the XNA team have any say in the GC development? I believe XNA is a good opportunity to showcase improvements in the GC in this regard. These kinds of improvements can help in non-game development as well.

    You could mitigate the GC by pre-allocating all your objects... not for the lifetime of the game... but whatever makes sense. Like a level

  • User profile image
    Charles

    Related to BitFlipper's question, of course. How is managed code performance maximized in the XNA Framework?

    C

  • User profile image
    BitFlipper

    Minh said:
    BitFlipper said:
    *snip*

    You could mitigate the GC by pre-allocating all your objects... not for the lifetime of the game... but whatever makes sense. Like a level

    Yes you would typically do that, but how do you do simple things like:

     

    float fps = 123.4f;
    string frameRateText = "FPS: " + fps.ToString("F2");

     

    ...without creating garbage? You can try to use StringBuilder but you are limited (how do you format floats, for instance?), and as soon as you call StringBuilder.ToString(), you are back to square one. Also, many of the built-in classes create garbage that you might not even know about. For instance, using enums as the key in a dictionary creates lots of garbage if you access it every frame. Or assigning delegates or events, or calling anonymous methods, etc etc.

     

    Basically, right now we have to pick through the framework and figure out what is going to create garbage and avoid using it. I would say it is almost impossible to create a complex game that doesn't create garbage during each frame. Ideally we should have an incremental GC that doesn't trigger long GC cycles so that we don't even need to worry about what creates garbage down to this fine level. If the game creates a small amount of garbage every frame, it should not matter.

  • User profile image
    magicalclick

    BitFlipper said:
    Minh said:
    *snip*

    Yes you would typically do that, but how do you do simple things like:

     

    float fps = 123.4f;
    string frameRateText = "FPS: " + fps.ToString("F2");

     

    ...without creating garbage? You can try to use StringBuilder but you are limited (how do you format floats, for instance?), and as soon as you call StringBuilder.ToString(), you are back to square one. Also, many of the built-in classes create garbage that you might not even know about. For instance, using enums as the key in a dictionary creates lots of garbage if you access it every frame. Or assigning delegates or events, or calling anonymous methods, etc etc.

     

    Basically, right now we have to pick through the framework and figure out what is going to create garbage and avoid using it. I would say it is almost impossible to create a complex game that doesn't create garbage during each frame. Ideally we should have an incremental GC that doesn't trigger long GC cycles so that we don't even need to worry about what creates garbage down to this fine level. If the game creates a small amount of garbage every frame, it should not matter.

    Can you be a bit specific? Which one is the garbage? float fps? or + fps.ToString("F2")?

     

    fps is typically from a global variable anyway.

    and fps.ToString("F2") is released right after the line ends.

    if your float fps is in a method, it is released right away also.

     

    And none of them has anything to do with garbage. Isn't garbage only exists when you have class object? like car carObj = new car();

    Anyway, you can manually release obj too, just like C++. I am not expert on this, but, I remember they just say you shouldn't do it too often.

     

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    BitFlipper

    magicalclick said:
    BitFlipper said:
    *snip*

    Can you be a bit specific? Which one is the garbage? float fps? or + fps.ToString("F2")?

     

    fps is typically from a global variable anyway.

    and fps.ToString("F2") is released right after the line ends.

    if your float fps is in a method, it is released right away also.

     

    And none of them has anything to do with garbage. Isn't garbage only exists when you have class object? like car carObj = new car();

    Anyway, you can manually release obj too, just like C++. I am not expert on this, but, I remember they just say you shouldn't do it too often.

     

    The float is a value type so it is not a problem in this case. But calling float.ToString() allocates a string, which is a ref object. You say fps.ToString() is released right after the line ends. Released to where? This has everything to do with garbage.

  • User profile image
    ZippyV

    - How should we make a choice between creating a native DirectX 11 application or a managed XNA application?

    - Will future versions of XNA support VB.NET? (What's stopping them from supporting it?)

  • User profile image
    W3bbo

    Minh said:
    W3bbo said:
    *snip*

    Why couldn't you use XInput?

    XInput is limited to only the Xbox 360 controllers, Logitech joypads aren't applicable, so you need to use DirectInput or WinMM. Contrariwise XInput does not support Logitech (or any other) controllers. People have successfully written DirectInput drivers for the Xbox 360 controller, so I feel it's just Microsoft being awkward.

  • User profile image
    rhm

    BitFlipper said:

    What kind of work is being done to improve the GC? The current GC is not ideal for use in something like games where a GC cycle can cause an interrupt long enough to cause noticeable frame dropping. If this wasn't a problem, then people would not come up with some horrific hacks in order to do simple things like write integers to the screen. Notice in that "solution", they get access to the private string that is embedded in StringBuilder in order to have a mutable string that doesn't create garbage when changed. And how would you write floating point numbers to the screen without creating garbage?

     

    Specifically, I think an incremental GC would work better. There might be slightly more overhead, but that is a good compromise if things run smooth otherwise.

     

    It is nice to use .Net for something like games, but it is a drag that we need to use Reflector to figure out which classes and methods are going to create garbage. It kind of takes away from what makes .Net great if you have to program like that.

     

    Does the XNA team have any say in the GC development? I believe XNA is a good opportunity to showcase improvements in the GC in this regard. These kinds of improvements can help in non-game development as well.

    Bitflipper is right, the Compact Framework blows. The Xbox 360 has got 512Mb RAM so why the CF? Even WP7 has 256Mb. Surely that's enough to justify something more sophisticated?

  • User profile image
    Ian2

    rhm said:
    BitFlipper said:
    *snip*

    Bitflipper is right, the Compact Framework blows. The Xbox 360 has got 512Mb RAM so why the CF? Even WP7 has 256Mb. Surely that's enough to justify something more sophisticated?

    Does the team think it would be possible at some point to introduce XAML and / or event driven programming without compromising the platform?

  • User profile image
    felix9

    IIRC there was a proposal to enhance the integretion of WPF and XNA, far beyond D3DImage, and its dropped in the roadmap of WPF 4 release, will it rise again ??

  • User profile image
    Bas

    This is undoubtably going to be a 'no announcement yet' type response, but it has to be asked: Kinect support?

  • User profile image
    Minh

    BitFlipper said:
    Minh said:
    *snip*

    Yes you would typically do that, but how do you do simple things like:

     

    float fps = 123.4f;
    string frameRateText = "FPS: " + fps.ToString("F2");

     

    ...without creating garbage? You can try to use StringBuilder but you are limited (how do you format floats, for instance?), and as soon as you call StringBuilder.ToString(), you are back to square one. Also, many of the built-in classes create garbage that you might not even know about. For instance, using enums as the key in a dictionary creates lots of garbage if you access it every frame. Or assigning delegates or events, or calling anonymous methods, etc etc.

     

    Basically, right now we have to pick through the framework and figure out what is going to create garbage and avoid using it. I would say it is almost impossible to create a complex game that doesn't create garbage during each frame. Ideally we should have an incremental GC that doesn't trigger long GC cycles so that we don't even need to worry about what creates garbage down to this fine level. If the game creates a small amount of garbage every frame, it should not matter.

    I would think this is an overkill / pre-mature optimization. They say the Xbox GC at 1MB allocations, so if you have a small string, say 50 chars, then your periodic GC runs at 1,000,000 bytes / (50 chars * 2 unicode bytes / char) = 10,000 strings / 60 strings / sec / 60 sec / min / 60 min / hr = 2.78 hrs.

     

    So, if all your game does is the fps string, then GC will run once every 3 hrs... Of course, that won't be all it does, but you get the idea.

     

    Optimizations you could do is only update the fps once every second, instead of 60 times a sec... Or there's a SpriteBatch.DrawInt32 user routine out there that doesn't use strings... Or do a pre-compute string table...

     

    The idea is to mitigate the effect of GC, not elimitate it. If you can keep GC to a manual process you do that can't be seen by the player, then that's a huge win.

  • User profile image
    Minh

    W3bbo said:
    Minh said:
    *snip*

    XInput is limited to only the Xbox 360 controllers, Logitech joypads aren't applicable, so you need to use DirectInput or WinMM. Contrariwise XInput does not support Logitech (or any other) controllers. People have successfully written DirectInput drivers for the Xbox 360 controller, so I feel it's just Microsoft being awkward.

    So you didn't use it based on philosophical grounds and not technical ones?

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.