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.
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.
I was curious about Kha and compressed textures and/or bitmap fonts. I noticed that the OpenGL Tutorial I was going through essentially said not to use normal texture formats, but to use a compressed texture format that is native to the GPU. I also noticed that another tutorial used a bitmap image for text instead of using a TTF font. I know that Godot 3 has tooling to convert textures and fonts as well.
I was wondering if there was a reason that Kha uses normal textures formats instead of compressing them. The workflow is already setup because Khamake does convert the images for different platforms. I'm not saying that Kha should, I'm still learning all of this stuff, I was just wondering whether or not it was a performance disadvantage that it doesn't convert them.
Is there a way to list folders and files in Krom? I'm targeting Krom and I need to be able to list the directories in a "Mods" folder and execute the
krom.jsfile in every mod. As far as I can tell, the Kha API allows you to load blobs from a path, but it doesn't allow you to list directories or files within a path. I suppose that makes a certain amount of sense because that wouldn't work on all platforms, such as web, but I do need a way to do it on the Krom platform.
@robert Thanks! That will be perfect. I am only planning on targeting Krom at the moment and I am going to be compiling the shaders ahead of time for it, but what is the difference between using
new FragmentShader(sources:Array<Blob>, Files:Array<String>)to get a
Hi everybody, I am trying to work a modding system into Armory and I'm in need of a way to load shaders dynamically from mods.
The way Kha games normally load shaders, as far as I understand, is:
- The Shaders in the project are located by Khamake.
- Khamake writes out a
files.jsonfile with references to all of the compiled shaders, which are stored in a
kha.internal.ShadersBuilder.build()macro is used to build the
kha.Shadersclass and provide a field in that class for every shader found by Khamake.
This workflow hardcodes the shaders available to the game at build-time, which is fine for most circumstances, but not if I need to dynamically load mods.
I found this function in the
FragmentShaderclass and I was wondering if this would let me load a shader at runtime, but it has a warning about the function not being portable.
- Does anybody know what "not portable" means exactly?
- Would it work if I loaded the Shader data blob at runtime from a file and created a
FragmentShaderinstance with the
- Are there any better ways to do this that I am not aware of?
/** Beware: This function is not portable. **/ public static function fromSource(source: String): FragmentShader;