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?

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.

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?

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

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.

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.

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.

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

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.

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?

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?

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.

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?

Minh said:

W3bbo said:

*snip*

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

Eh?

I didn't use XInput because the gamepad I had to work with was a Logitech one. Which means I have to use either DirectInput or WinMM, and WinMM's API was the simplier and quickest to integrate into my code. There's no politics at all.

If you're referring to my last sentance, that's unrelated. I was saying that people have successfully gotten the Xbox controller to work with DirectInput by providing their own drivers.

W3bbo said:

Minh said:

*snip*

Eh?

 

I didn't use XInput because the gamepad I had to work with was a Logitech one. Which means I have to use either DirectInput or WinMM, and WinMM's API was the simplier and quickest to integrate into my code. There's no politics at all.

 

If you're referring to my last sentance, that's unrelated. I was saying that people have successfully gotten the Xbox controller to work with DirectInput by providing their own drivers.

Oh OK. I misunderstood. If your logitec controller is way more sophisicated than the Xbox controller, then you have to avoid XInput.

Minh said:

BitFlipper said:

*snip*

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.

You are correct that if the only thing my game did was print an fps string to the screen, that would probably not be an issue. Throw in scene management, AI, collision detection, physics, weapons, enemies, sound, particle effects, a HUD, etc etc and things get a bit more complex. A game is very dynamic as there is a lot of interaction between objects and things come and go continuously (think of bullets, etc). Obviously you re-use objects as much as possible, but that is not the only source of allocations. It is possible to delay the inevitable GC, but that is all you can do - delay it.

Right now I am working on my collision detection algorithms. I have a relatively simple scene that I use to test it with. I am getting around 2000 - 3500 fps with this simple scene (on the PC). Looking at my code, I can't see an obvious place where memory is being allocated, yet the memory goes up roughly ~200KB every second. Granted, at those frame rates, even a small allocation would quickly add up (and it is not the fps counter - I checked that). This means I need to go and dig into the code and see what is going on. Now if I have a more complex scene, the fps would obviously drop, but at the same time the complexity would go up so I imagine the allocations per sec would remain more or less the same. And as the object graph gets more complex, a GC will become slower. I have not seen issues simply because currently my object graph is too simple - the GC can very quickly do a collect. But other people are running into this problem - just go to forums.xna.com and search for GC. Edit: "garbage" is a better term to search for here.

My point is - we should not have to worry about this (within reason). Why do we need to worry about the internal memory allocation details of the .Net classes when we use a high-level language?

BitFlipper said:

Minh said:

*snip*

You are correct that if the only thing my game did was print an fps string to the screen, that would probably not be an issue. Throw in scene management, AI, collision detection, physics, weapons, enemies, sound, particle effects, a HUD, etc etc and things get a bit more complex. A game is very dynamic as there is a lot of interaction between objects and things come and go continuously (think of bullets, etc). Obviously you re-use objects as much as possible, but that is not the only source of allocations. It is possible to delay the inevitable GC, but that is all you can do - delay it.

 

Right now I am working on my collision detection algorithms. I have a relatively simple scene that I use to test it with. I am getting around 2000 - 3500 fps with this simple scene (on the PC). Looking at my code, I can't see an obvious place where memory is being allocated, yet the memory goes up roughly ~200KB every second. Granted, at those frame rates, even a small allocation would quickly add up (and it is not the fps counter - I checked that). This means I need to go and dig into the code and see what is going on. Now if I have a more complex scene, the fps would obviously drop, but at the same time the complexity would go up so I imagine the allocations per sec would remain more or less the same. And as the object graph gets more complex, a GC will become slower. I have not seen issues simply because currently my object graph is too simple - the GC can very quickly do a collect. But other people are running into this problem - just go to forums.xna.com and search for GC. Edit: "garbage" is a better term to search for here.

 

My point is - we should not have to worry about this (within reason). Why do we need to worry about the internal memory allocation details of the .Net classes when we use a high-level language?

Yeh, it's stupid to say use a managed language because it saves you from having to concern yourself with memory management, and then tell programmers that actually they do have to tear their hair out worry about every single allocation because if they don't the GC is going to come and freeze up their gameloop while it examines THE WHOLE HEAP.

It's like you're actually worse off than the C++ programmer who only has to worry about freeing memory up at the right time and in the case of memory that's only needed for temporaries during the processing of a single frame, they can use a custom allocator that discards everything in one go at the end of the loop.

BitFlipper said:

magicalclick said:

*snip*

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.

float.ToString()?

return values from a function call is stored in the call stack or something right? It is push right at return and pop right at caller line. It is just C++. You don't need to release anything for that in C++. Unless XNA is so much different from C++ and C# that we will have to release every single return primitive? String is a special primitive that will be released automatically in C++. I am just talking about C++. And there is no additional action needed to be done in C++. C# is just doing the same as C++ on this part.

In C++, if you return an object, you don't release until you want to kill it. In C#, you can release it manually or wiat for GC. In XNA, I assume it is C#.

BitFlipper said:

Minh said:

*snip*

You are correct that if the only thing my game did was print an fps string to the screen, that would probably not be an issue. Throw in scene management, AI, collision detection, physics, weapons, enemies, sound, particle effects, a HUD, etc etc and things get a bit more complex. A game is very dynamic as there is a lot of interaction between objects and things come and go continuously (think of bullets, etc). Obviously you re-use objects as much as possible, but that is not the only source of allocations. It is possible to delay the inevitable GC, but that is all you can do - delay it.

 

Right now I am working on my collision detection algorithms. I have a relatively simple scene that I use to test it with. I am getting around 2000 - 3500 fps with this simple scene (on the PC). Looking at my code, I can't see an obvious place where memory is being allocated, yet the memory goes up roughly ~200KB every second. Granted, at those frame rates, even a small allocation would quickly add up (and it is not the fps counter - I checked that). This means I need to go and dig into the code and see what is going on. Now if I have a more complex scene, the fps would obviously drop, but at the same time the complexity would go up so I imagine the allocations per sec would remain more or less the same. And as the object graph gets more complex, a GC will become slower. I have not seen issues simply because currently my object graph is too simple - the GC can very quickly do a collect. But other people are running into this problem - just go to forums.xna.com and search for GC. Edit: "garbage" is a better term to search for here.

 

My point is - we should not have to worry about this (within reason). Why do we need to worry about the internal memory allocation details of the .Net classes when we use a high-level language?

post your code.

I did a collision detection engine where the static mesh are created at load time, and shouldn't incur any game time pressures to the GC.

You probably got a ref object in there somewhere that you think is a value object

magicalclick said:

BitFlipper said:

*snip*

float.ToString()?

 

return values from a function call is stored in the call stack or something right? It is push right at return and pop right at caller line. It is just C++. You don't need to release anything for that in C++. Unless XNA is so much different from C++ and C# that we will have to release every single return primitive? String is a special primitive that will be released automatically in C++. I am just talking about C++. And there is no additional action needed to be done in C++. C# is just doing the same as C++ on this part.

 

In C++, if you return an object, you don't release until you want to kill it. In C#, you can release it manually or wiat for GC. In XNA, I assume it is C#.

 

Really that is not how memory works in C#. It is not like C++ at all. Calling float.ToString() absolutely allocates a string, and even if you don't store it, it only means that it is not rooted  any more. It is still allocated until the GC determines that it isn't (there's the problem right there) and only then will it be released.

BitFlipper said:

magicalclick said:

*snip*

Really that is not how memory works in C#. It is not like C++ at all. Calling float.ToString() absolutely allocates a string, and even if you don't store it, it only means that it is not rooted  any more. It is still allocated until the GC determines that it isn't (there's the problem right there) and only then will it be released.

Guys.... This thread is for asking questions of the XNA team, not arguing about your position/percpetion/opinion/understanding of managed code, etc...... Please..

C

Minh said:

BitFlipper said:

*snip*

post your code.

 

I did a collision detection engine where the static mesh are created at load time, and shouldn't incur any game time pressures to the GC.

 

You probably got a ref object in there somewhere that you think is a value object

Well there is just way too much code to post it (and I don't really think this is the correct thread for it). I am sure I am not allocating ref objects during the game loop as I have carefully stepped through it looking for exactly that. The more likely cause is that I am using the .Net or XNA classes in such a way that garbage is created that I am unaware of. This is a minefield where innocent "mistakes" lead to garbage. Examples of things that could create garbage during the game loop:

• Calling anonymous methods or closures.
• Setting/clearing delegates or event handlers.
• Using an enum as a key in a dictionary. Simply doing a lookup creates garbage in this case.
• Doing "silly" things like wanting to create strings using "+" or "string.Format, etc.
• Adding/removing items out of a LinkedList. It is very common to have objects added/removed from linked lists in the game loop. So now you have to roll your own linked list, or use something other than linked lists.
• Accessing value types via an interface will cause them to be boxed (was not aware of this).
• Some enumerators create garbage. Good luck figuring out which ones do and which ones don't. Quick: Does foreach() on a Dictionary ValuePair create garbage? Often it seems safer just to fall back to for() if you are unsure (where the collection allows this).
• Using yield in order to enumerate objects.
• And who-knows-what-else happens behind the scene as you use the built-in .Net classes.

The point is, you might not create garbage while using your own classes/structs, but there are many cases where simply doing things that look innocent causes garbage to be created.

This is a quote from Shawn Hargraves (works on XNA Game Studio at MS):

    You can achieve good performance by avoiding allocations, so the garbage collector will never run. This works regardless of how complex your heap may be.

    You can also achieve good performance by keeping your heap nice and simple, so the garbage collector will finish quickly. This works regardless of whether you allocate memory during gameplay.

    But you cannot achieve good performance by mixing these two approaches! There is little to be gained by allocating only a medium amount of memory and having only a medium complex heap. That will produce a game which has a medium size glitch every medium number of seconds.

    If your goal is to avoid garbage collection glitches altogether, you must pick just one path and follow it to the bitter end.

This just isn't ideal. An incremental GC would help since then you don't need to worry about creating some amount of garbage (within reason) at each frame, no matter how large your object graph is. Having to pick between one of the two above approaches and then ensuring that you stick to it really complicates things. Java has an optional low-pause incremental collector, why not .Net?

EDIT: @Charles: Sorry, only saw your post after I posted. Will stop posting now. If someone wants to discuss the details further, we can create another thread.

Charles said:

BitFlipper said:

*snip*

Guys.... This thread is for asking questions of the XNA team, not arguing about your position/percpetion/opinion/understanding of managed code, etc...... Please..

C

So to boil it down into a question for the XNA team: Will the XBox version of XNA ever get to run the desktop CLR or see significant improvements to the garbage collector on the current runtime?

BitFlipper said:

magicalclick said:

*snip*

Really that is not how memory works in C#. It is not like C++ at all. Calling float.ToString() absolutely allocates a string, and even if you don't store it, it only means that it is not rooted  any more. It is still allocated until the GC determines that it isn't (there's the problem right there) and only then will it be released.

I see, so string is not a special premitive in C#, while it is special premitive in C++. Got it.

magicalclick said:

BitFlipper said:

*snip*

I see, so string is not a special premitive in C#, while it is special premitive in C++. Got it.

std:string isn't a special primitive in C++ either. It's just a class wrapper around a null-terminated array of char (or wchar_t or some other type if you're using STL). In .NET String is a "special" class in that it can be treated as a const and has special in-memory behaviour (see String Internment) but whatever.

Anyway, Charles said this thread is about questions to pitch to the XNA guys, not each other.

phones will also get more advanced capabilities soon..

in general i think microsoft should market directx more agressivly to developers, and xna is agreat way to do that 

(more directx/xna content/tutorials on c9 would also be awsome btw ) 

also, major BUMP on @bas's question on kinect support  

CreamFilling512 said:

Are there any plans to improve the JIT compiler for XNA on Xbox, GC, and other core runtimes?  Some basic changes like more aggressive method inlining would go a long way.  Currently you have to write messy code to get the best performance .

How far ahead are you with the XNA build for XBOX 3?  (no harm in trying)

also would like to know where they see XNA going in the future. Though that's a pretty obvious question. but it's interesting seeing now that XNA is the only platform for developing high end games on wp7, given that XNA was originally a project primarily aimed at indie developers, it's now been given a lot more responsibility to be a top class platform for big developers to produce games too. Not that i think there's one thing wrong with that. I think it's exciting for game making tools used by big developers to make high end games are accessible and usable by the humble bedroom programmer.

aL_ said:

when will xna have better support for dx11 and windows programming? i realize xna is mostly for xbox but it seems so strange to not support the latest (or even second latest) version of the graphics framework of the largest gaming platform in the world

phones will also get more advanced capabilities soon..

 

in general i think microsoft should market directx more agressivly to developers, and xna is agreat way to do that 

(more directx/xna content/tutorials on c9 would also be awsome btw ) 

 

also, major BUMP on @bas's question on kinect support  

Yeah this. XNA only has DX9 right now. Time to support DX11.

The WP7 version of XNA does not allow you to provide a custom shader program. Why is that? As far as I can see the hardware is shader-based. Are there any plans to improve this in future versions?