Hacker News Reader

Comment by tomlin | Hacker News Reader

Agree. I don't know if the Ruby interpreter is what I'd look to for performance in a game.

The irony is that Ruby was actually designed for this kind of thing. And in fact, RPG Maker XP’s Ruby Game Scripting System, a commercial usage of Ruby as an embedded scripting language for game dev, was released at least a few months prior to the first Ruby on Rails release if memory serves correct.

Do you have a source for the claim that ruby was designed for game development? I'm not saying it's wrong, I just have never heard that before.

Not necessarily game dev, but rather as an embeddable scripting language. There’s also mruby which is even more portable and designed to be more embeddable. My understanding is that in Japan, Ruby is often used as an embedded scripting language the way people might use Lua.

(I don’t have an exact source for this, it’s something that seems to come up periodically when talking about Ruby. Matz mentions it briefly when introducing mruby. I also don’t necessarily think it was conceived for this reason, but rather that over time, it fell into the niche and became influenced by it. But I’m not sure about that, either.)

I can vouch for Ruby's practicality as an embedded scripting language. The first time I used it was in a game engine (which, IIRC, also predated Rails) with a C++ core. Writing the high-level game logic in Ruby was pleasant, and hooking into C++ functions that did the heavy lifting kept it performant.

Unity’s implementation of C# is subpar to say the least. Watch the YouTube video, it demonstrates DragonRuby’s speed vs Unity. We can render twice as many sprites and are 1/8th the size.

We also expose C Extensions to the end user if they what blinding fast performance for critical paths.

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

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.

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.

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

It doesn’t use the standard Ruby interpreter (MRI), but a custom implementation that includes a compiler. I don’t know if it’s AOT compilation or JIT.

This is mRuby, not Ruby. Different things. Think in mRuby as Lua and MRI Ruby as Python

Reply on news.ycombinator.com