Hm... I'm more concerned about running user-land scripts and shaders than sprites. If I wanted raw pixel-blits per second I could just use SDL.

Do you have any concrete numbers on compute (ie. scripts)?

Do you support shaders?

eg. How would you do this in DragonRuby? --> https://github.com/keijiro/StableFluids

Ie. a compute buffer that renders a fluid simulation in real time?

There’s quite a few samples of people doing crazy things with Cuda. Not sure if you can access this demonstration: https://discord.com/channels/608064116111966245/674410581326...

These are other demonstrations of DRGTK’s performance capabilities: - https://twitter.com/Groteskly/status/1373668110482427906 - https://twitter.com/amirrajan/status/1361640855589842951 - https://twitter.com/amirrajan/status/1339575630187425792

Unity rendering sprites has nothing to do with C#. A big portion of their engine and rendering stack are implemented in C/C++.

Unity does also support C extensions... But due to cross platform mess it is not so popular (i guess).

> double the amount of sprites

It sounds a bit low? My experience is that with instancing and 2d array textures (2d games usally uses spritesheets) can be much much faster then 2x. I would guess 20x-200x faster than unity.

Huh, number of sprites per frame has little to do with the speed of C# in Unity. If anything it shows that Unity's default sprite renderer is inefficient.

You have any data to back up that claim? Unity C# is very fast; especially, if compiled to IL2CPP. Your video doesn’t prove anything. Make a lot of moving transform hierarchies and see how they compare. Unity sucks at this, but I bet it will still outperform In your tests.