Originally Posted by Dimentio
You're forgetting that if we go that route, we'd need to ensure that whatever JITC we use, would be capable of converting to other architectures, like ARM, and to be prepared for needing to rewrite it repeatedly to keep up with changes. It's possible to make these very efficient, but it will never be as efficient as properly pre-compiling for the system architecture (and APIs) that you are using.
This will not increase performance of the current ZC model. In fact, it's guaranteed to be slower than whatever we use now, even with a JIT compiler, unless we did some seriously tedious performance adjustments. If you truly want it to be fast, you need to write your own graphics handler, instead of relying on Allegro, or any of its competitors. They all pretty much sacrifice performance for versatility.
If you want it to be insanely fast, go learn AMD64, or better yet, Power7, assembly. :p
I'm reminded here of that cross-engine game...'Shovel Knight'. Didn't its author rewrite it in 80386 assembly, so that it was capable of running at full speed on an 80836SX-16, or something insane like that?
For all its flaws, the popularity of Java started with the intention of having a 'fast, and efficient' cross-platform engine to run non-compiled code.
In any case, this thing isn't going to work for Android, or iOS, and that's a prime concern for future versions of ZC, especially in terms of system processing power, and efficiency; although I'll be the first to admit that by the time we're ready to address running it on a mobile device, the power of all such devices on the (first-sale) market will have doubled.
It also won't work on OSX, even on Intel architecture, nor so I expect support for that to come from the author. We'd need to provide it ourselves.
Reply With Quote