• Zicklag

    OK, cool. BTW when I was looking around I found a very cool looking alternative to Verilog: SpinalHDL. Reminds me slightly of Haxe, except for hardware ( compiles to Verilog and allows for custom abstractions ).

    posted in Kode read more
  • Zicklag

    Hey, just out of pure curiosity, what is that KPU repo all about. Are we trying to figure out how to make our own game console! 😃

    But anyway, I was just looking around and the only hint as to what it was, to me, who had no idea what it was, was the Verilator submodule. I looked up verilator, then I looked up verilog, and now I think that the concept of an FPGA is awesome. Now I see that it looks like the KPU is a way to run Kore on an FPGA or something?

    posted in Kode read more
  • Zicklag

    @Robert Do you want to include the webidl library as a submodule of Kha or would you rather just drop the sources in there so that we can make changes without having to get it merged into the official repo. There are some modifications I will need to make, but I can see if I can make the changes generic enough to be able to be merged into the official repo so that we might not need to have our own separate version of it.

    We could also fork it and add a submodule for our fork of it like we do for hxcpp.

    posted in Kode read more
  • Zicklag

    OK here are my WIP diffs:

    • Khamake
    • Kha -- Ignore the doubled WebIDL submodule. I'll get that fixed. We do need to include the webidl library and probably make some slight modifications.

    posted in Kode read more
  • Zicklag

    I'll get my commits up in a branch of my fork as soon as I can. All of the difficult work for the binding is handled by the webidl library so it didn't take much code in Khamake.

    posted in Kode read more
  • Zicklag

    @Robert I've gotten pretty far with a WIP integration, I'd like to hear if you have any thoughts on it. There's a GitHub issue where I'm posting my progress.

    posted in Kode read more
  • Zicklag

    Hi @Robert, I was working on automating the Javascript bindings for bullet to Haxe for armory in the haxebullet repo and the thought occurred to me that integrating something like the haxe webidl binder into Khamake could be useful. If you could use functions inside of your korefile.js to specify the C++ sources to include similar to the generate functions in the webidl package, then it could make it a simple matter to bind any C/C++ libraries compatible with Emscripten into Kha projects with support for Krom.

    If you think that might be a good idea then I'll probably start working on that to see if I can manage it. I'm still figuring out the binder a little bit, but it looks like it shouldn't be too complicated.

    posted in Kode read more
  • 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
  • Zicklag

    @robert I just had an idea, would it be possible to compile the sys package from the Haxe standard library to C++ using the Haxe C++ backend, include this generated C++ code in Krom, and bind it to Javascript. That would allow us to avoid having to re-implement sys from scratch in Krom.

    HashLink can also compile to C so that might be another option for sourcing the sys implementation.

    Do you think this would work or would there be problems. I don't have experience in C/C++, but I'm wanting to get sys support in Krom so I thought that this might be an easy way to get a sys implementation without having to start from nothing.

    posted in Kode read more
  • Zicklag

    @robert Thanks for the explanation! That's great. That's a very nice to know and it sounds like a good strategy. Works without me even having to know that it's there. 🙂

    posted in Kode read more

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