(for devs)If you would recreate Spring again from zero?

[eriatarka]

exactly what I had in mind. sleep is elegant, coroutine.create+coroutine.yield isn't. I could deal with that, but I doubt modders would like to wrap their heads around this.

Couldn't coroutine.create be handled by the Lua-as-unitscript binding system? Just "coroutine.yield" would be fine. Also, I don't know enough about how Lua works, but could the yield statement be wrapped in a "sleep" function? I mean, in most coroutine languages that's a nonsense concept, but Lua might be different.

Yes and yes. Unit scripters would just have to call some sleep() function.

[imbaczek]

Doesn't coroutine.yield, uh, yield to caller? For sleep() to work as expected, it'd have to yield to some higher frame; you'd need a continuation or something. (Of course, I haven't got the faintest idea how Lua's coroutines work, so I may be wrong ^^)

[lurker]

Cob is very much compiled, just not to x86 code. Would a lua bytecode file really run on a plain, simple, virtual machine?

COB is compiled to bytecode, Lua is compiled to bytecode. Yes, there is a Lua VM. I don't see the big difference. Except that a team of very clever guys has spent years optimizing the hell out of Lua; I doubt that amount of effort has gone into COB.

Hmm, I checked wiki, and it looks like I was wrong. I had thought lua was mostly just tokenized.

Code: Select all

function <factorial.lua:1,6> (10 instructions, 40 bytes at 003D5818)
1 param, 3 slots, 0 upvalues, 1 local, 3 constants, 0 functions
        1       [2]     EQ              0 0 -1  ; - 0
        2       [2]     JMP             2       ; to 5
        3       [3]     LOADK           1 -2    ; 1
        4       [3]     RETURN          1 2
        5       [5]     GETGLOBAL       1 -3    ; factorial
        6       [5]     SUB             2 0 -2  ; - 1
        7       [5]     CALL            1 2 2
        8       [5]     MUL             1 0 1
        9       [5]     RETURN          1 2
        10      [6]     RETURN          0 1

[Pxtl]

Doesn't coroutine.yield, uh, yield to caller? For sleep() to work as expected, it'd have to yield to some higher frame; you'd need a continuation or something. (Of course, I haven't got the faintest idea how Lua's coroutines work, so I may be wrong ^^)

Depends on the implementation. Since Lua is such a dynamic language, maybe it just walks up the stack until it finds a coroutine stack frame and then yields from that? The "coroutine.Create" method would just mean that function X is marked as a coroutine on the stack.

There are lots of possible implementations that would allow for such things. If eri says it works, then I'll take his word for it and say "cool".

edit: as for optimization, I don't know the Lua compiler, but I know python. Python looked compiled, but it was really wasn't much beyond tokenized. Any reference to the member of any object was still a hit to the hashtable - the only things that had been improved beyond hash hits were local variables, which were compiled into offsets of the local stack frame. Still, the compiler pre-generate hash-keys at least. I presume Lua, being a dynamic language, works similarly.

You can optimize the hash hits a lot, but ultimately they're slower than just handling numbers in arrays. COB is all numbers in arrays, and all your variable names are just offsets, so it's potentially far faster.

Still, as has been said - Lua has a lot more manpower focussed on it, so it may be actually faster than COB, simply by being better optimized.

The true ideal approach would be the Supcom one - a VM'd language like DotNet. But that's a whole other ball of wax. Proper sandboxing is a little tougher in DotNet though - Lua is far more appropriate to embedding.

[jcnossen]

The true ideal approach would be the Supcom one - a VM'd language like DotNet. But that's a whole other ball of wax. Proper sandboxing is a little tougher in DotNet though - Lua is far more appropriate to embedding.

IIRC, supcom uses Lua, it only uses .NET for the lobby, which is why the actual game is so cpu demanding. Even projectiles are done in lua.

[Dragon45]

Personally, I'm waiting for a popular game scriptable with Python. or Scheme.

[Pxtl]

Personally, I'm waiting for a popular game scriptable with Python. or Scheme.

Tried it with Python myself - the problem is that the official Python distro is inappropriate for this use. It's not well-optimized, and it's not sandboxed - how would you feel if you DL'd a mod that wiped your harddisk? Any game that wants to use Python as a scripting language has to roll their own derivative version of it, which is too much work. Lua solves that problem by being designed from the ground-up for embedding.

I'm sure there are Scheme variants that are similar to Lua for that, but Scheme is illegible to most mortals.

[eriatarka]

Doesn't coroutine.yield, uh, yield to caller?

Nope. Python has that behavior, and the concept is called generators there (a slightly less generic/powerful form of coroutines). Lua however has proper coroutines, where you can yield from any stack depth. (See http://www.lua.org/pil/9.1.html, discussion at the bottom.)

The argument that COB is compiled to just "numbers in arrays" does hold some water though. Lua would probably still do some string operations at runtime; although most of it would be very fast hash lookups, I guess. We'll never know without benchmarks.

Now don't get me wrong, I'm not the one proposing to switch everything over to Lua. In fact, one of the things that annoys me is that everyone's favorite reply seems to be "Do it in Lua". The core engine text renderer is broken? Oh well, let's just do a new one in Lua. Want some fancy effects on your unit? Render your model in Lua. And so on. (No offense meant to anyone.)

Lua is a nice little language, but although a fast one, it's still only a scripting language. One really has to evaluate such uses of it critically. Is this and this a feature that has wide applicability (such that many mods could benefit from it) and should be fast? Then put it in the engine. Else, if it's a one off thing or speed doesn't matter, go ahead and put it in Lua. That's my opinion, of course.

[KDR_11k]

Personally, I'm waiting for a popular game scriptable with Python. or Scheme.

Battlefield 2 used Python IIRC.

[imbaczek]

newer source engine (event script 2.0 or whatever it's called) and civ4 also use python.

of course, Lua is much more popular - if not it's syntax, I'd actually like that language, since it's so small and relatively fast. of course, true JIT'ed scheme/lisp with proper type annotations would be faster still (as in, near C speed.)

eri: cool, good to know.

[jK]

1. it is true that Lua does hashlookups for global variables/functions, that's why trepan always recommend to localize those thingies (a huge list at the head of each lua file with: local min = math.min ...).
2. if you fear that Lua is too slow, check this http://luajit.org/luajit.html (1-~10% faster). iirc upspring already `use` it.
3. Lups shows very well that it is possible to write a particle engine with Lua, you only need much optimization (do huge math in c or on the gpu etc.). And i don't want to miss 100% free positional particles (the pos-tag in Lups is in Lua-code, so you can spawn particles in any form).