3 ms·

Good stuff, just a question, why c#?

by xchip 8y ago

electricslpnsld 8y ago
Not op, but outside of C++, C# is probably the widest deployed language (on the CPU) in the game industry by virtue of the Unity engine.
- rossnordby 8y ago
  To make things a little stranger, it's worth mentioning that I'm not sure if bepuphysics v2 works well with Unity right now. Attempts in the last several months by users trying to upgrade from v1 to v2 had... less than ideal results under that runtime. The library is .NET Standard 2.0 compliant, though, so in theory it should work. It may require some extra work on the runtime side of things. As time goes on, I'd hope that mono/CoreRT or whatever the AOT story ends up being/CoreCLR converge and Unity can embrace them for all their target platforms. (Burst is also an option, but that would require a massive rework in bepuphysics that I can't really afford to do given that my projects aren't on Unity.)
GordonS 8y ago
Erm, why not? Seriously question.
rossnordby 8y ago
That's a good question. It almost wasn't; there was a period post-WinRT, pre-"microsoft open sources everything" where investing a huge amount of effort in the ecosystem didn't seem like it would make sense. I did consider a more traditional (for the games industry) path of C++, but even simple things like the effort required to keep build times reasonable were... not appealing. And modules kept getting kicked back. Even back then, I was considering rust as a preferred alternative. And then everything went open source, some fruits of Midori started getting rolled in, and a focus on performance appeared. Stack that on top of the fact that C# has some pretty darn good tools, and I was comfortable jumping in more deeply. Notably, I did not just start making bepuphysics v2 at that point. It's sort of the tip of the iceberg- bepuphysics v2 is C# because all the other private stuff I've built is C#, and it's nice to minimize the developmental and runtime overheads between projects when possible.

Good stuff, just a question, why c#?

by xchip 8y ago

Good stuff, just a question, why c#?

Not op, but outside of C++, C# is probably the widest deployed language (on the CPU) in the game industry by virtue of the Unity engine.

rossnordby 8y ago
To make things a little stranger, it's worth mentioning that I'm not sure if bepuphysics v2 works well with Unity right now. Attempts in the last several months by users trying to upgrade from v1 to v2 had... less than ideal results under that runtime. The library is .NET Standard 2.0 compliant, though, so in theory it should work. It may require some extra work on the runtime side of things. As time goes on, I'd hope that mono/CoreRT or whatever the AOT story ends up being/CoreCLR converge and Unity can embrace them for all their target platforms. (Burst is also an option, but that would require a massive rework in bepuphysics that I can't really afford to do given that my projects aren't on Unity.)

GordonS 8y ago

Erm, why not? Seriously question.

rossnordby 8y ago

That's a good question. It almost wasn't; there was a period post-WinRT, pre-"microsoft open sources everything" where investing a huge amount of effort in the ecosystem didn't seem like it would make sense. I did consider a more traditional (for the games industry) path of C++, but even simple things like the effort required to keep build times reasonable were... not appealing. And modules kept getting kicked back. Even back then, I was considering rust as a preferred alternative. And then everything went open source, some fruits of Midori started getting rolled in, and a focus on performance appeared. Stack that on top of the fact that C# has some pretty darn good tools, and I was comfortable jumping in more deeply. Notably, I did not just start making bepuphysics v2 at that point. It's sort of the tip of the iceberg- bepuphysics v2 is C# because all the other private stuff I've built is C#, and it's nice to minimize the developmental and runtime overheads between projects when possible.