• Robert

    When you build a project in Kode Studio it tells you which version of Kha it uses in the first line of output

    posted in Kode read more
  • Robert

    Mostly the same targets but they differ in some small things - but how a window/canvas is handled is one of the things which work differently.

    posted in Kode read more
  • Robert

    If you only need it for the debug-html5 target, we can add that. Create a GitHub issue please so I don't forget about it.

    posted in Kode read more
  • Robert

    No, it isn't and it's not planned. Canvas element resizing depends too much on how it is embedded in a website to put that functionality in Kha directly. Add a bit of JavaScript if you need it. Also the flash backend is purely in maintenance mode - I fix it when it breaks but I don't add new functionality.

    posted in Kode read more
  • Robert

    You're running some very old Kha version then.

    posted in Kode read more
  • Robert

    Try building again please, just realized I hadn't yet merged rblsb's fixes.

    posted in Kode read more
  • Robert

    The matrix is not quite right because the Kha VR support hasn't been updated for recent changes in Kore's VR support. That said, Lubos has demo code hidden somewhere (see http://forums.armory3d.org/t/vr-demo-dino/316) and you can find current Kore based VR things at https://github.com/CatCuddler/BodyTracking

    posted in Kode read more
  • Robert

    GitHub is the right place in this case because I don't think I've implemented instancing support for Metal yet.

    posted in Kode read more
  • Robert

    The list is here: https://github.com/Kode/Kha/wiki/Feature-Matrix
    There have been some updates to the Java backend recently but I haven't looked into it myself for a while. The Java target is mainly intended for embedding simple Kha applications in Java applications without adding any external dependencies. It uses AWT, so don't expect good performance.

    posted in Kode read more
  • Robert

    No need to put it in Kore, you can just use that lib with Kore when you need it.

    posted in Kode read more
  • Robert

    Oh and please don't use the simulator, it's worse than just using Kha's macOS target. Only makes sense for regular ui applications based on my experience.

    posted in Kode read more
  • Robert

    Will tell you after we fixed that bug.

    posted in Kode read more
  • Robert

    Try --debug. that should disable optimizations and therefore speed up the build.

    posted in Kode read more
  • Robert

    Providing some mechanisms for loading dlls isn't too difficult and I can certainly add that - not too fond of any automatic binding generators though, I generally don't think those are worth the effort and that kind of thing is especially troublesome for C++, I'd go for pure C interfaces.
    But... you have false expectations of that - it would more often than not be a bad option to speed things up. There is overhead in communication and calls from JS to native things and vice versa, it's only viable for things that do long, independent computations. Not sure it would speed up or slow down Bullet, probably depends on how exactly it's used. It's certainly not suitable to super-optimize anything, the C++ target remains the most useful for that. Krom is not the one target for every situation (for example console and iOS is not fast because they disallow runtime code generation) but also that was never the intention.

    posted in Kode read more
  • Robert

    Don't think so. Lubos did most of the Compute work so far and he did that in OpenGL, I just added what I needed myself in D3D and Metal. But it's not hard to add those things - all the shader code is correctly translated, just needs some functions to hook things up.

    posted in Kode read more
  • Robert

    Chakra and V8 outperforms even HL/C in most situations in all benchmark summaries I've seen (like https://twitter.com/jdbaudi/status/789231337467174912 and https://twitter.com/jdbaudi/status/789513120611987456 and in benchmarks Lubos did in Armory) - I don't know why that claim is still on the HL website, it seems rather strange. So, no, doesn't make sense. Krom uses a JS runtime because those are by far the fastest runtimes around for Haxe - and they are still getting faster.

    posted in Kode read more
  • Robert

    Both (reading buffer data back and using compute output as vertex input) isn't implemented for Metal yet, please add some GitHub issues (or send pull requests).

    posted in Kode read more
  • Robert

    I'm so bad in marketing Krom's features. I'll start adding code for the sys api. I think file stuff and network stuff is all we need.

    posted in Kode read more

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