• Zicklag

    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.

    I get what you mean about the CPU, now. If it isn't a CPU bound test, then the Javascript changes shouldn't have made a big difference. All of the operations that are really taking any time are on the GPU.

    posted in Kode read more
  • Zicklag

    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.

    posted in Kode read more
  • Zicklag

    Armory3D — Blender integrated 3D game engine:

    • Iron — 3D engine core based on Kha
    • armory — Blender integration and game dev workflow built on Iron

    posted in Kode read more
  • Zicklag

    I have a question about the performance impact of including the entire haxe, kha, iron, and armory libraries 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 khafile.js ) :

    --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 eval and I am using the armory.system.Modding.exposePack('arm') macro to add the @:expose metadata 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 include macros, 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.

    posted in Kode read more
  • Zicklag

    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. 👍

    posted in Kode read more
  • Zicklag

    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 ld when I compile it after making changes, not sure if that is just because of my laptop being slow ).

    posted in Kode read more
  • Zicklag

    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 .dll or a .so library that could be loaded by Krom ( automatically? ) to add extra libraries and Javascript bindings that can be used in your Kha app ( obviously with Haxe externs for said library ). If you could do that, you could use the C++ Bullet library right inside of Krom without having to compile Bullet to Javascript ( which should be better for performance ). Also, if you had any extremely intensive operations that you really needed to write in C++, you could write that code as a Krom extension and use the bindings to interact with it in your Haxe code. That way, if you ever really needed to super optimize a certain portion of your game, you could do it easily.

    I'm not sure exactly what options there might be for automating bindings for C++ libraries. I know some C++ libraries use tools like Swig that are used to automate bindings to Python and other languages, but I don't know what options there are for Javascript. Much of this is outside of my expertise. Even if you had to write the glue code manually, though, just having the ability to bind Javascript to other native libraries in Krom would be an huge advantage.

    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? 😉

    posted in Kode read more
  • Zicklag

    Thanks again for your quick and helpful reply. 🙂

    posted in Kode read more
  • Zicklag

    I was wondering whether or not it would make sense to make HashLink either the VM or an optional VM for Krom. On the HashLink website it says that it has tested to out-perform V8. I know we switched to Chakra recently, but maybe it's worth benchmarking Chakra and HashLink to see if HashLink is faster. HashLink might make the Krom binary and the bytecode smaller than it would be with Javascript, too.

    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. 🙂

    posted in Kode read more
  • Zicklag

    OK, good to know. I might try my hand at implementing it, then, if nothing else gets in the way. I'm going to need to learn some C/C++ anyway. 🙂

    posted in Kode read more

Looks like your connection to Kode Forum was lost, please wait while we try to reconnect.