More poignant examples would be `dirent.h` and `system`. Getting access to the file system on a console, or the ability to start up a process out of band is not allowed.

Late reply, but maybe it’ll be useful to other people coming across this post.

1. mRuby is trivial to embed.

2. S7 Scheme is also trivial to embed.

3. LuaJIT will not work on consoles (proprietary CPU architectures), and JIT isn’t supported on iOS or Android. You have to use vanilla Lua.

4. Lua has historically been the default because it was first to provide a nice embed story.

5. Lua as a language leaves a lot to be desired (Ron Gilbert really disliked using it within his games)

6. This gist post goes into details wrt the deficiencies of Lua [1]

7. Here are two GH repos with Roguelike Tutorial. One in Lua [2], the other in mRuby [3]. It’s worth comparing and contrasting.

8. If I want extremely performant code, then I drop down to C. For scripting level/game code. mRuby is plenty fast [4].

[1] https://gist.github.com/amirrajan/2c42315ffef311600ecb2d8dcf...

[2] https://github.com/Lycea/Rogue/tree/master/components

[3] https://github.com/kfischer-okarin/roguelike-tutorial-2021/t...

[4] https://m.youtube.com/watch?v=MFR-dvsllA4

Creator of DragonRuby here. Send me an email and I’ll hook you up with a license to the game engine :-)

at[at]amirrajan[dot]net

Additional Links:

- Starfield Demo: https://www.youtube.com/watch?v=S-baJwEjUsk&ab_channel=AmirR...

- Starfield Source: https://gist.github.com/amirrajan/508f1a6aaf5352cab579104e61...

- Skybox/Coordinate System: https://www.youtube.com/watch?v=fvlRg3GvcLY&ab_channel=AmirR...

In the event that Godot becomes insolvent, the engine loses the ability to export to console. You must have a business entity to get access to those parts of the SDK. Losing the ability to go to console is a massive hit to the viability of the engine.

Godot doesn't directly offer console support anyway

https://docs.godotengine.org/en/3.0/tutorials/platform/conso...

Realistically this means if porting to console is a priority you should go with one of the dominate engines, Unreal or Unity.

Decided to do a flash sale given all the visibility the engine has gotten recently. You can get the Standard License free for the next 24 hours: https://itch.io/s/48411/dragonruby-game-toolkit-hacker-news-...

The FAQ covers this in detail under the "What is DragonRuby?": http://docs.dragonruby.org/#--frequently-asked-questions,-co...

> Python provides a better syntax in almost all areas

Examples?

Things I don't like about Ruby: %w{} et al., symbols, more implicit "magicy" things.

Ryan has a custom compilation of it actually. That editor will go to the grave with him :-P

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

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.