slime wrote:LuaJIT is as fast or faster than Java, AFAIK - especially when you use FFI bindings rather than the traditional lua-c api for things like the OpenGL functions. Check out https://github.com/malkia/ufo and https://github.com/ncarlson/eiga .
Minecraft utilizes OpenGL for most of its graphics work, instead of relying on software-side Java code to transform a 3d scene into 2d screen-space (which is what LÖVE "3D" things are doing, essentially).
Could Löve potentially perform and render a Minecraft-like game if it were given the correct access to OpenGL?
Also, what's the Illusionary Engine? The only "3D" game I see on StabYourself is Ortho, which is a 3D orthogonal puzzle game that is extremely simple. (But still pretty damn awesome and complex) I'd like to try this Illusionary thing if it's still around.
While yes, LuaJIT is faster than interpreted JVM code it's definitely *not* faster than JITed JVM code which is what all major desktop distributions do now. Sun has payed *really* smart people large chunks of money to make very well optimized translations from JVM bytecode to JITed x86.
In fact, if Java was more C like, it could be as fast as C or C++. Unfortunately Java uses reflection, bulky objects, quirky C to Java interfaces, only has arrays and objects instead of pointers, and over encourages polymorphism(speed being the issue that is). But I digress.
LuaJIT is very well optimized but due to the even more dynamic nature of Lua than Java and the fact that LOTS of work has been done on Java optimization, LuaJIT doesn't beat JITed Java code. LuaJIT with proper OGL exposure could definitely play minecraft but it would always be a bit behind in performance of the real thing. but yes, the performance is all there to do this, definitely, the size of a chunk might just be a bit smaller so it can fit in cache. you could do more computationally expensive parts in C or C like code(using cdata) however, that would put it on a level playing field.
ishkabible wrote:While yes, LuaJIT is faster than interpreted JVM code it's definitely *not* faster than JITed JVM code which is what all major desktop distributions do now. Sun has payed *really* smart people large chunks of money to make very well optimized translations from JVM bytecode to JITed x86.
In fact, if Java was more C like, it could be as fast as C or C++. Unfortunately Java uses reflection, bulky objects, quirky C to Java interfaces, only has arrays and objects instead of pointers, and over encourages polymorphism(speed being the issue that is). But I digress.
LuaJIT is very well optimized but due to the even more dynamic nature of Lua than Java and the fact that LOTS of work has been done on Java optimization, LuaJIT doesn't beat JITed Java code. LuaJIT with proper OGL exposure could definitely play minecraft but it would always be a bit behind in performance of the real thing. but yes, the performance is all there to do this, definitely, the size of a chunk might just be a bit smaller so it can fit in cache. you could do more computationally expensive parts in C or C like code(using cdata) however, that would put it on a level playing field.
Do you have benchmarks handy to back this up? From my understanding, a large part of the performance issues of Minecraft are due to Java's GC and OpenGL rendering - Minecraft looks simple graphically, but the voxel style makes optimization a little different than most other games.
(plus, LuaJIT is not at its peak yet - there are still plenty of optimizations that have not been done yet but are planned, especially dealing with the garbage collector).
I would also like to point out that the gameplay code of both Natural Selection 2 and Cobalt are written in Lua.
slime wrote:LuaJIT is as fast or faster than Java, AFAIK - especially when you use FFI bindings rather than the traditional lua-c api for things like the OpenGL functions. Check out https://github.com/malkia/ufo and https://github.com/ncarlson/eiga .
Minecraft utilizes OpenGL for most of its graphics work, instead of relying on software-side Java code to transform a 3d scene into 2d screen-space (which is what LÖVE "3D" things are doing, essentially).
Could Löve potentially perform and render a Minecraft-like game if it were given the correct access to OpenGL?
Also, what's the Illusionary Engine? The only "3D" game I see on StabYourself is Ortho, which is a 3D orthogonal puzzle game that is extremely simple. (But still pretty damn awesome and complex) I'd like to try this Illusionary thing if it's still around.
slime wrote:LuaJIT is as fast or faster than Java, AFAIK - especially when you use FFI bindings rather than the traditional lua-c api for things like the OpenGL functions. Check out https://github.com/malkia/ufo and https://github.com/ncarlson/eiga .
Minecraft utilizes OpenGL for most of its graphics work, instead of relying on software-side Java code to transform a 3d scene into 2d screen-space (which is what LÖVE "3D" things are doing, essentially).
Could Löve potentially perform and render a Minecraft-like game if it were given the correct access to OpenGL?
Also, what's the Illusionary Engine? The only "3D" game I see on StabYourself is Ortho, which is a 3D orthogonal puzzle game that is extremely simple. (But still pretty damn awesome and complex) I'd like to try this Illusionary thing if it's still around.
in theory it could, or at least a luajit build of love could
for example, since love provides a gl context, you could just use the ffi to bind to opengl functions and call those directly (the ufo library slime posted has opengl bindings already written, although you'd probably want to bind to glee or glew as well). in fact i'm already doing this to prototype something.
Jasoco wrote:Also, what's the Illusionary Engine? The only "3D" game I see on StabYourself is Ortho, which is a 3D orthogonal puzzle game that is extremely simple. (But still pretty damn awesome and complex) I'd like to try this Illusionary thing if it's still around.
Maurice wrote:Yeah, the game has cubes. Thus it's minecraft.
Thing is, it's not perspective, in that further objects aren't rendered smaller like in MineCraft and every other 3D game. All "cubes" are rendered at the same size straight back. It's more like Fez than MineCraft. You can see how they used this engine for Ortho though. It works there. But not as a Minecraft game.
Do you have benchmarks handy to back this up? From my understanding, a large part of the performance issues of Minecraft are due to Java's GC and OpenGL rendering - Minecraft looks simple graphically, but the voxel style makes optimization a little different than most other games.
(plus, LuaJIT is not at its peak yet - there are still plenty of optimizations that have not been done yet but are planned, especially dealing with the garbage collector).
My observations are based off of the general performance of Java as apposed to LuaJIT. Here is the most recent benchmark I could find between the 2 in the language benchmark game; I had to use the wayback machine but the information is still good.
It shows Java being, in general, much faster but *FAR* less memory efficient. Certainly locality, fragmentation, allocation times, and poor interfaces to native libraries(like OpenGL) could make Java less efficient in many cases but on a more general scale Java will be faster than LuaJIT. It could be that the large memory requirements of Minecraft make it better suited for LuaJIT but I think Java would still win if just speed was being measured.
That said, I think LuaJIT would still work very well.
Do you have benchmarks handy to back this up? From my understanding, a large part of the performance issues of Minecraft are due to Java's GC and OpenGL rendering - Minecraft looks simple graphically, but the voxel style makes optimization a little different than most other games.
(plus, LuaJIT is not at its peak yet - there are still plenty of optimizations that have not been done yet but are planned, especially dealing with the garbage collector).
My observations are based off of the general performance of Java as apposed to LuaJIT. Here is the most recent benchmark I could find between the 2 in the language benchmark game; I had to use the wayback machine but the information is still good.
It shows Java being, in general, much faster but *FAR* less memory efficient. Certainly locality, fragmentation, allocation times, and poor interfaces to native libraries(like OpenGL) could make Java less efficient in many cases but on a more general scale Java will be faster than LuaJIT. It could be that the large memory requirements of Minecraft make it better suited for LuaJIT but I think Java would still win if just speed was being measured.
That said, I think LuaJIT would still work very well.
Keep in mind that benchmark is using LuaJIT version 2.0 beta 5 or lower (the most recent is 2.0 beta 9). There have been numerous performance increases since then, especially in version 2.0 beta 6 and beta 7. As you mentioned, one of Java's main weaknesses ia memory management, and the roadmap for LuaJIT shows significant plans for improving garbage collection beyond its current (fairly good, especially compared to Java) state. Automatic GC taking up several milliseconds at inopportune times is one of the current major downsides to using a language like Java and Lua for games.
Do you have benchmarks handy to back this up? From my understanding, a large part of the performance issues of Minecraft are due to Java's GC and OpenGL rendering - Minecraft looks simple graphically, but the voxel style makes optimization a little different than most other games.
(plus, LuaJIT is not at its peak yet - there are still plenty of optimizations that have not been done yet but are planned, especially dealing with the garbage collector).
My observations are based off of the general performance of Java as apposed to LuaJIT. Here is the most recent benchmark I could find between the 2 in the language benchmark game; I had to use the wayback machine but the information is still good.
It shows Java being, in general, much faster but *FAR* less memory efficient. Certainly locality, fragmentation, allocation times, and poor interfaces to native libraries(like OpenGL) could make Java less efficient in many cases but on a more general scale Java will be faster than LuaJIT. It could be that the large memory requirements of Minecraft make it better suited for LuaJIT but I think Java would still win if just speed was being measured.
That said, I think LuaJIT would still work very well.
Keep in mind that benchmark is using LuaJIT version 2.0 beta 5 or lower (the most recent is 2.0 beta 9). There have been numerous performance increases since then, especially in version 2.0 beta 6 and beta 7. As you mentioned, one of Java's main weaknesses ia memory management, and the roadmap for LuaJIT shows significant plans for improving garbage collection beyond its current (fairly good, especially compared to Java) state. Automatic GC taking up several milliseconds at inopportune times is one of the current major downsides to using a language like Java and Lua for games.
i know luajit's binary-trees benchmark is in fact gc-bound. probably the same for fasta
