1 |
So I've been experimenting with the engine a lot recently. Not just the engine, but developing for it too (Unit Level Ups). I've come to realise two things:
|
1 |
So I've been experimenting with the engine a lot recently. Not just the engine, but developing for it too (Unit Level Ups). I've come to realise two things:
|
2 |
\n
|
2 |
\n
|
3 |
1. Lua is quite slow. This hasn't really been a problem for Zero-K outside of 32-player lobfeasts, but for Unit Level Ups I'm starting to realise it's quite hard to make everything extendable, maintainable and performant. Often, one of those three is sacrificed.
|
3 |
1. Lua is quite slow. This hasn't really been a problem for Zero-K outside of 32-player lobfeasts, but for Unit Level Ups I'm starting to realise it's quite hard to make everything extendable, maintainable and performant. Often, one of those three is sacrificed.
|
4 |
[s]2. Lua has a 1.6GB (or somewhere abouts) memory limit. Again, not a problem for Zero-K, but as more units, content and mods are added we're going to get quite close to the memory limit.[/s]
|
4 |
[s]2. Lua has a 1.6GB (or somewhere abouts) memory limit. Again, not a problem for Zero-K, but as more units, content and mods are added we're going to get quite close to the memory limit.[/s]
|
5 |
(CORRECTION: LuaJIT used to have a 1GB memory limit, but with the 64-bit GC it now does not. Lua's memory limit is 4GB I believe, I just got confused. But LuaJIT 2.1's GC can handle lots of memory a lot faster)
|
5 |
(CORRECTION: LuaJIT used to have a 1GB memory limit, but with the 64-bit GC it now does not. Lua's memory limit is 4GB I believe, I just got confused. But LuaJIT 2.1's GC can handle lots of memory a lot faster)
|
6 |
\n
|
6 |
\n
|
7 |
LuaJIT will fix both these issues: its 64-bit garbage collector is capable of handling much more memory, and it has a built in JIT compiler (which can be disabled if we encounter sync issues- its interpreter is also much faster than Lua 5.1's)
|
7 |
LuaJIT will fix both these issues: its 64-bit garbage collector is capable of handling much more memory, and it has a built in JIT compiler (which can be disabled if we encounter sync issues- its interpreter is also much faster than Lua 5.1's)
|
8 |
\n
|
8 |
\n
|
9 |
That's why I've started a LuaJIT fork: https://github.com/pts1667/spring
|
9 |
That's why I've started a LuaJIT fork: https://github.com/pts1667/spring
|
10 |
\n
|
10 |
\n
|
11 |
I've
made
some
progress,
but
it
still
doesn't
compile
on
Windows
(
native
nor
cross-compile)
due
to
(
a)
LuaJIT
not
supporting
cross-compile
to
a
64-bit
Windows
host
yet
(
I
don't
think
you
can
link
PE
objects
in
MinGW)
and
(
b)
Spring
build
system
not
supporting
MSVC.
This
will
take
significant
work
so
if
anyone
wants
to
help
please
PM
me.
|
11 |
I've
made
some
progress,
but
it
still
doesn't
compile
on
Windows
(
native
nor
cross-compile)
due
to
(
a)
LuaJIT
not
supporting
cross-compile
to
a
64-bit
Windows
target
yet
(
I
don't
think
you
can
link
PE
objects
in
MinGW)
and
(
b)
Spring
build
system
not
supporting
MSVC.
This
will
take
significant
work
so
if
anyone
wants
to
help
please
PM
me.
|
12 |
\n
|
12 |
\n
|
13 |
Don't expect anything yet, though. Currently with the basic testing I have done I think it works. No idea if it syncs. Make sure to configure with -DNO_CREG=TRUE
|
13 |
Don't expect anything yet, though. Currently with the basic testing I have done I think it works. No idea if it syncs. Make sure to configure with -DNO_CREG=TRUE
|