- Popularity of unity.
- Tool development at gamedev companies (these are mostly win + c#
- C# is simpler than C++. Easier to start development, and less tols in the beginning to shoot yourself in the foot.
That said, I still prefer C++ at anytime, because I like writing efficient and performant code.
Depending on your workloads, you can also try using thread building blocks for the same set of problems, and you have to care less about doing os level thread operations. It won't solve your problems magically (you still have to handle data races, synchronization), but at least you will do less OS specific work.
Just based on an editor plugin, no. It's a requirement these days though.
What would make me considering looking into a new language are the following.
- great set of examples and documentation to start out
- easy ways to inerface with C code, easy ways to call and link together with c libs
- plugin for a multiplatform IDE, that has some for of auto-completion (std lib at least!)
- ways to interact with the community, reddit, blogs, IRC, stackoverflow like pages etc...
There are other things, but those are specific to my usual set of projects. (VFX where you need perf and to deal with tons of data) Or just the simple fact, that it gives me something that no other language can.
Updating positions, and a couple of global / constant variables on the gpu won't be a bottleneck, if you do things properly.
I dont see how it can be done any faster.
I did a simple experiment where I ray traced one sphere, no reflections, no shading, no lighting, no antialiasing. Just a ray sphere intersection for each pixel per frame. Doing one readbuffer and one writebuffer each frame in opencl did this simple image at 100fps. By eliminating the read and write and using gl_cl interop, it did 1200fps.
Rendering one sphere and one plane with antialiasing and reflections drops it down to 30fps. Doing it with one read and one write takes it below 1fps. This i thought was good considering the same image took over 2 minutes to render one frame 10 years ago. Obviously realtime raytracing is future technology and computers need to improve a fair bit to have a full rt raytracer with a million triangles and radiosity and the rest but in the mean time, this little test shows that the gpu has no problem rendering. The real problem is moving memory between global and host space as far as this little example is concerned. I understand when the scene gets more complex then the update between host and gpu will become less significant, but it is the most significant factor when it comes to moving this particular camera around the above red sphere.
Specify what read and write means in your case. Maybe post a few code snippets here. Using cl_interop in this case is super confusing. We were talking about passing parameters that describe the scene (ie, the ones you have to change based on the user's input) to the kernel. You can't avoid that. User input has to be processed on the CPU, and the scene changes have to be pushed back to the GPU somehow.