• 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

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