Re: LuaJIT C++ API with templates advice
- From: Mike Pall <mike-1308@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 23 Aug 2013 17:28:00 +0200
Daniel Thompson wrote:
> --> Does anyone have pointers for me in regards to exposing
> C++/templated API's to the LuaJIT FFI?
That's not only a tough job, IMHO it's also a dead end. One really
doesn't want to inflict the complexity of C++ templates upon a
dynamic language, which can do without them just fine.
> --> Have I misunderstood the capabilities of LuaJIT and the FFI
> / Am I actually just being completely retarded in my approach?
Maybe it's a symptom of developers coming from a C++ background,
but I see most of them going on an eternal hunt for ever more
complex frameworks to pile abstraction upon abstraction. They end
up with monsters that need gigabytes to run and have a molass of
dependencies, which are doomed to break when you look too close.
This isn't targeted at you -- it's just a general observation.
I've read the description of that "Entity Component" Framework and
looked at the code. It seems to be just a lot of C++ code that
works around the deficiencies of the language when it comes to
loose coupling of components.
You could write the core abstractions in a couple lines of Lua.
Looking at their example, you'd start with a plain Lua table as
the base object. The process function of that "Movement" class
would simply do: 'self.x = self.x + self.vx*world.delta' plus the
same for 'y'. That's it! No need for extra encapsulations,
painfully slow getters or anything of that kind.
LuaJIT is fast enough to write your entire game with it. It mainly
depends on which layers you want to write yourself. I'm assuming
you don't want to paint the pixels yourself (but you could). So,
technically, at the lowest level you'd link directly against (say)
OpenGL libraries and there you go.
> --> Should I just give up and use Unity/GameMaker etc? :)
The real question is what do you want to work on for the next few
years? It seems to be a common theme with aspiring game developers
to feel the need to write their own game framework.
Inevitably they find out this is A LOT OF WORK due to the inherent
complexity of the task. Most of them get burned out soon. In the
end, we've got yet another abandoned game framework, but still no
new game ...
There are plenty of game frameworks to choose from and it might
make more sense to try out several of them and contribute fixes
for their deficiencies. That is, unless you have some irrefutable
selling point for your own framework and are serious about taking
the plunge.
[In this case, I'm the last one to stop you. Everyone told me I was
crazy doing what I did with LuaJIT -- but I knew it had a unique
selling point and I knew I could make it work. Ok, so I didn't know
what was ahead of me, but then I set out for mostly uncharted
territory. Well, luckily, I didn't know ... :-) ]
--Mike
Other related posts:
