I switched to the Forward renderer and the frame rate is fine ( the Forward renderer works a lot better on my laptop than the Deferred one ), so I think that it isn't a real problem.
did you verify both variations really follow the exact same code paths?
They should be taking the same path because the only difference between the tests I did was the hxml flags.
And is your scene even CPU bound?
I don't know exactly. It is just a basic Armory scene with textured meshes. It shouldn't really be doing much other than rendering, moving the camera, and whatever logic comes with that.
I should probably try testing it on some other computers to see if they behave at all the same.
I have a question about the performance impact of including the entire
armorylibraries in a game build for Krom. Here is my setup in more detail.
I have the following extra parameters added to the
hxml( by setting the in the
--macro include('kha', ['kha.graphics4.hxsl.*', 'kha.netsync.NodeProcessClient', 'kha.netsync.Example', 'kha.HaxelibRunner', 'kha.internal.*']) --macro include('iron', ['iron.data.GreasePencilData']) --macro include('armory', ['armory.system.*']) --macro include('haxe', ['haxe.macro.*']) --macro armory.system.Modding.exposePack('arm') --macro armory.system.Modding.exposePack('kha') --macro armory.system.Modding.exposePack('iron') --macro armory.system.Modding.exposePack('armory')
I'm using this to allow for modding. The code for any mods is loaded in at runtime using
evaland I am using the
armory.system.Modding.exposePack('arm')macro to add the
@:exposemetadata to the packages so that the mods can access the exposed APIs.
This obviously defeats stuff like dead code elimination, but I can't know ahead of time what portions of the API mods are going to use, so I have to include the entire API in the game output.
My problem is that by simply adding the
includemacros, my Armory game's frame rate is a lot lower. I don't have a very good computer, but for my test scene that I simply fly around in:
- Without the includes the frame time averages around 35ms.
- With the includes the frame time averages around 55ms.
I thought that maybe the file size was the problem, but the file size difference is only roughly 300kb. Also If I uglify the bigger file the difference is only 100kb, but the performance difference still stands.
Anyway, my question is whether or not there is any way to help this or if that is just how it is. I was surprised that the performance was so different when I wasn't using any of the extra APIs or doing any extra work, my program is just bigger because there are more classes and functions. Or could it just be that my computer is slow ( slow disk speed and low graphics ) and that it just exaggerates the effect.
Ah, very good information. Thanks.
So the primary use of loadable dlls would be to integrate with native APIs, not for optimization of any sort, but it could still be useful.
Also good to know about Krom on iOS and consoles; I was assuming Krom would run similarly on consoles. I've got a lot to learn about this stuff so thanks for answering my questions.
I am trying to compile Krom on Linux and just wanted to make sure I was doing it in the way that made most sense for development. I am able to successfully compile it using Koremake like the Readme explains, but I wanted to know if there was a different way that I should build it for debugging purposes. Are there "Release" and "Debug" build modes that make a difference?
I noticed that the Readme said that debugging setup isn't automated on Linux IDEs yet. I don't need to have a debugger if it is not setup yet, but I did want to make sure there wasn't a debug build mode that would make it compile changes faster ( it seems to take a really long time running
ldwhen I compile it after making changes, not sure if that is just because of my laptop being slow ).
OK, so, Krom is awesome. I've established that. It is the easiest and the best way to handle dynamically loading code for mods, it outperforms the C++ target for Armory, it will be available on consoles and mobile devices soon, and it is using the fastest runtime available. It's great.
Still, there is one disadvantage that I recognize compared to the C++ target and that is being able to interact directly with other native C++ libraries. For example, with Armory, for physics it is using the Bullet library for the C++ backend. For Krom it uses an Emscripten compiled version of the Bullet C++ library. That is fine, but that wouldn't work if you needed to interact with something like native APIs for mobile phones or for desktop integrations. Yes, you could fork Krom and add those C++ libraries and bindings, but then you have to maintain a fork of Krom for your purpose. Not ideal.
What would be awesome is if you could make native Krom extensions like you can for NodeJS. You could compile like a
Maybe there is already a way to do this. If there is, Krom is still awesome. If there isn't, maybe it could be even awesome-er ( yes it's a word despite whatever your dictionary tells you ). So @Robert, what's the verdict?
I'm not sure exactly how debugging would work or how much work it would be to get HashLink in Krom, so maybe it isn't worth the effort, but I couldn't resist asking about it.