Title says it all really. Python was proving to be a major pain and
broke lots of stuff. So: I changed to Lua instead. It's a much smaller
codebase, and I've already got basic bindings between it and the
engine written.
It's in the git repository now.
-Alastair
Adam
Ruby is slow, and ruby is extremely difficult to embed.
Not worth the effort.
Alastair
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Xsera Development" group.
> To post to this group, send email to xser...@googlegroups.com
> To unsubscribe from this group, send email to xsera-dev+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/xsera-dev?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
Please don't assume I'm making a sweeping generalisation.
I'm speaking from experience with Ruby, because I struggled for *six
months* to get it integrated with one of my past games at the advice
of someone in whose opinions I have a great deal of trust. Ruby is
really not designed for embedding: the API is awkward, and there is no
namespacing used at all, which meant I had to re-name a great many
internal functions to shoehorn Ruby in there. That was just the start
of my trouble: when things went wrong in Ruby it would crash the
entire game.
Objective-C is not much slower than C: its message passing systems
actually doesn't add a great deal of overhead and the main body of
functions are compiled in machine-code just as C is. Ruby, however, is
benchmarkably slower than Lua by an order of magnitude for some types
of code, particularly with the Lua/LLVM integration I plan to add at a
later date which will allow Lua to emit to native machine code at
runtime. Most of this extra functionality is functionality that we
don't need - Lua is light, extensible, adds little to the compile time
or size of the executable, and provides everything that we need.
I am not biased, I am just concerned with making the game as good as
possible, and for me that means not spending the majority of the time
trying to keep the very weak bridge between Ruby and C++ in one piece
- I'd rather go with Lua, which I know to work, and work quickly.
Alastair
It was me wasn't it?
> I am not biased, I am just concerned with making the game as good as
> possible, and for me that means not spending the majority of the time trying
> to keep the very weak bridge between Ruby and C++ in one piece - I'd rather
> go with Lua, which I know to work, and work quickly.
>
> Alastair
Seconded. The product needs to be the best we can make it. If that
means using Lua, then so be it. But I can't think of many (if any)
modern OS X apps that use Ruby extensively. While I like Ruby (and
Ruby on Rails), the language is not mature enough for usage outside a
very limited area.
It was Evan Seeds, and the product was MBS, if you remember back that
far. It was meant to be developed after Xenos and before... your
product, if you know what I mean.
Alastair