Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Jun 2004
Offline Last Active Yesterday, 03:22 PM

#5193966 C# .Net Open Source

Posted by Mike.Popoloski on 21 November 2014 - 08:23 AM

The GC may be amazing, but why is barring you from having any control an amazing feature? Wouldn't it be nice if you could choose to opt in to specifying the sizes of the different heaps, hinting at good times to run the different phases, specifying runtime limits, providing your own background threads instead of automatically getting them, etc? Would it harm anything to allow devs to opt in to that stuff? Do the amazing features require the GC to disallow these kinds of hints?


You can do a lot of that now. You've always been able to hint that a new collection should be run (which you might want to do right after loading a new level, say). Newer versions of .NET let you disable the GC and turn it back on again for sections of your code, so you could leave it disabled for your main loop and then flip it back on again during level load. There are different levels to this feature as well; you can set it to *never* run, or set it to "low latency", where it almost never runs unless you get critically close to running out of memory. You can also manually compact the LOH, letting you choose good times to reduce fragmentation.


If you want even more control, like taking full control of thread scheduling of the GC or setting size limits, you can host the CLR, similar to how Unity works. There are a crazy amount of knobs to tweak there.


Of course, the simplest advice that avoids all of this is what it has always been in both the managed and native worlds: during the main loop of your game, don't heap allocate. Not necessarily easy, but simple to understand. It's certainly easier to do in C++, but also doable in C# (in fact, it was almost a hard requirement that you do that for Xbox Arcade XNA games, since the Xbox's GC was pretty crappy). Unlike in some other managed languages that will remain unnamed, the .NET CLR supports value types, so you can with just a bit of effort cut down heavily on the amount of garbage you're generating.


For the times you absolutely need heap allocations but really need to avoid the managed heap, you can always just *allocate native memory* anyway! There's nothing stopping you from malloc-ing some native memory blocks and doing your work there. I do this pretty commonly in my own projects for certain classes of memory where I need explicit control over lifetime or alignment.

#5075821 99 Bottles Of Beer Challenge With Least Amount Of Characters ?

Posted by Mike.Popoloski on 06 July 2013 - 06:56 PM


What? Wait... what? Can somebody translate that for me, because some things I didn't see yet in C# (or I saw but didn't have the need to use hence forgot it).

It's mostly some very clever applications of string formatting.


That said, Mike clearly knows way more fun facts about string formatting than I do smile.png



Oh, the things you learn by trawling through the MSDN documentation at random :)   So many bits of the BCL are completely unknown to most people.

#5075789 99 Bottles Of Beer Challenge With Least Amount Of Characters ?

Posted by Mike.Popoloski on 06 July 2013 - 02:51 PM


Also, I think C# and Java should include their using/import and class definitions.


I did, they add ~20-30 characters to your character count.



Actually, with the Roslyn shell you no longer need the surrounding class / Main function cruft, just as if you were using the python shell. Granted, you should still include the using statements, since they're required.


Also, I see your 300+ C# entry and raise you 250 (even beats some of the other languages)  biggrin.png

string f="{0:#;;",e=".\n",o="s;s;''} of beer",w=" on the wall",n="o more} bottle",x=n+"{1:"+o;
for(int a=99;a>=0;)System.Console.WriteLine(f+'N'+x+w+", "+f+'n'+x+e+
"{1:Take one down and pass it around;Go to the store and buy some more}, {1:#;99;n"+n+"{2:"+o+w+e,a,a-1,--a-1);

It doesn't require the conditional operator either, which is nifty.

#5074523 DirectWrite and DirectX 11

Posted by Mike.Popoloski on 01 July 2013 - 01:55 PM

It's a fairly straightforward concept, just lots of moving parts to deal with. Essentially you implement a custom ITextRenderer interface and plug it into DirectWrite, so the dwrite text layout engine says "here are the glyphs you want, and here is where you should put them".  Then it's up to you to render them at those spots. 


That library uses another piece of DWrite, a BitmapRenderTarget, to render each glyph to a memory buffer and then packs it into a Direct3D texture atlas using a bin packing algorithm. Then you have a texture atlas with various rendered glyphs, and you have positioning info, so you can just draw quads at those spots with the correct texture coordinates and it all works.

#5070293 C# timing code not functioning properly

Posted by Mike.Popoloski on 16 June 2013 - 05:40 PM

The TimeSpan struct defines a "tick" as exactly 100 nanoseconds long. In contrast, the Stopwatch class uses the performance counter built into the machine, and thus its frequency varies from system to system. You should use the Stopwatch.Frequency field to convert your delta ticks to seconds.


N.B. You can cache the Stopwatch.Frequency value on startup, since it's guaranteed not to change while the system is running.

#5064696 Optimizing code statements into expressions?

Posted by Mike.Popoloski on 24 May 2013 - 11:36 PM

There is so much wrong with this thread that it's mind boggling.


I have no idea why you think trying to force some random statement into an expression is going to make things faster, but it's really not. Trying to play tricky games with a language that compiles to an intermediate bytecode is also just laughably futile.


Furthermore, C# * absolutely* can be inlined, but you're not going to find it on the IL level, since it's a feature that's handled by the JIT and the CLR. It's also probably going to be a lot smarter about when to do it than you would be, taking into account the adverse affects it can have on polluting the instruction cache and potentially spilling registers in tight loops.


Additionally, boxing and unboxing are not going to have much of a performance hit on your application unless you're doing a ton of them. Allocations in a garbage collected environment are very fast, and small short-lived temporary objects are one of the best-case scenarios for the typical managed GC. It's unlikely to cause any fragmentation problems, considering that the GC moves objects in memory to avoid that very issue.


It's also not difficult to avoid boxing calls. Your nine thousand line program is actually pretty small as far as most games go, and it's absolutely possibly to avoid any boxing operations in a code length of that size, depending on what you're doing. As Frob said, if you find yourself needing to do it often, you need to critically rethink your design.


Despite all that, if you actually needed every single cycle available to you (and I'm not convinced that in your case you do), you should be working in a language that facilitates that kind of development, such as C++. Probably you're going to keep misguidedly doing what you're doing, but if nothing else this post should help others who might stumble upon this thread.

#5048890 Issue trying to create a shared resource

Posted by Mike.Popoloski on 01 April 2013 - 10:15 AM

I'm not too experienced with using the shared resource stuff, but I think that if you want it shared, you need to use the ResourceOptionFlags.Shared flag, not the KeyedMutex flag.

#5045292 SlimDX future?

Posted by Mike.Popoloski on 21 March 2013 - 09:57 AM

I can verify that switching from SlimDX to SharpDX is almost trivial, even for a newb like me, if you're concerned about continued development.


You are right, cephalo. But it is always better leave the well working code without any modifications.. So, before migration to SharpDX i wanted to know whether this is necessary. And i was surprised that no one gave me an answer about SlimDX further developing. As i read on slimdx.org this form is considered as main forum of SlimDX.


SlimDX works fine, and we still fix bugs from time to time. We'll probably do a maintenance release some time soon. It even works fine on Windows 8 desktop.


What we won't be doing is adding support for Metro apps on Windows 8, so if you need to target that you'll have to look elsewhere.

#5031875 Please vote to support request for DirectX tools for C#

Posted by Mike.Popoloski on 13 February 2013 - 10:52 AM

I don't get it. How do the tools not work with C#? Their shader compilation support is just an MSBuild task that runs FXC. No reason you couldn't also use it in your C# project; it's hardly language specific.

#5030158 Game development on: Linux or Windows

Posted by Mike.Popoloski on 08 February 2013 - 01:18 PM

What about Direct3D... I heard it's API is really crappy, so is the documentation. So, it could be hard to learn it, true?


False. It's actually the opposite; OpenGL's API hasn't changed much since the 80's and the documentation is practically nonexistent (in fact, if you go to the OpenGL website, it says "The two essential documentation resources that every developer should have are the latest releases of:" and then gives two links to Amazon books you need to buy).


It's much harder to learn to use effectively, since the API no longer reflects much of what happens in modern hardware, and there are multiple paths to accomplish most tasks, the right one being non-obvious or even changing depending on which hardware vendor or driver version you're using.


That said, if you're targeting any platform other than Windows, you don't have much choice but to suck it up and tough it out anyway.

#5029069 Using SlimDX in my project (DirectX11 in XNA)

Posted by Mike.Popoloski on 05 February 2013 - 10:36 AM

It's still supported. There hasn't been much reason to update; there are hardly any bugs and we support all the features we're going to support. We don't have any plans to add support for Metro or Win8-only features, since none of us have any interest in using those platforms.

#5029053 Using SlimDX in my project (DirectX11 in XNA)

Posted by Mike.Popoloski on 05 February 2013 - 09:58 AM

It's perfectly fine to include the SlimDX DLLs in your installer. We have some information on deployment with SlimDX here.

#5026668 [SlimDX] Shader Constants and their registers

Posted by Mike.Popoloski on 29 January 2013 - 12:26 AM

Also MapSubresource returns the data stream you should write to. Your old one is no good.

#5026636 [SlimDX] Shader Constants and their registers

Posted by Mike.Popoloski on 28 January 2013 - 08:50 PM

You should create the buffer once and just make updates to it each frame by calling DeviceContext.Map / UnmapSubresource.

#5025799 Pointers invalid between C++ and C#.

Posted by Mike.Popoloski on 26 January 2013 - 11:25 AM

Your pointer points to a local variable on the stack. As soon as your function ends on the managed side, the memory is popped off the stack and is no longer valid. Any pointers to it will be pointing to invalid memory.


Having native store a pointer to anything allocated on the managed side is very difficult to achieve. If your object is a local, the memory disappears when it goes out of scope. If it's allocated on the heap, the memory can be moved around by the garbage collector. My advice is to make a copy of the matrix and force updates when necessary.