Save
Saving
• timodriaan

That worked. I noticed that vscode asked for private network access after opening the project folder (Visual Studio asked too) but I don't know anymore if Kode Studio did that (It's a long time since I installed it).

Now I'm stuck with a bunch of Js::JavascriptException exceptions (I can't find a way to get to the adress of those exceptions) and a Out of stack space error that's Armory3D-related. Probably should switch to pure Kha for debugging.

Edit: Running the other, non-VS Krom configuration from within vscode doesn't work either. It compiles without an error and after that the "debug navigation bar" (where you can stop the execution for example) just vanishes and I can start the execution again.

Edit 2: Ok I get the same errors in a pure Kha project. Found way to also break on those JS exceptions but I cant find their cause. startKrom() does not work, it calls JsRun() from chakra which then calls CompileRun() and I understand nothing after that.

Stack trace:

 	KernelBase.dll!00007ffacb53a839()	Unbekannt
[Externer Code]
Krom.exe!Js::JavascriptExceptionOperators::DoThrow(Js::JavascriptExceptionObject * exceptionObject, Js::ScriptContext * scriptContext) Zeile 1361	C++
Krom.exe!Js::JavascriptExceptionOperators::ThrowExceptionObjectInternal(Js::JavascriptExceptionObject * exceptionObject, Js::ScriptContext * scriptContext, bool fillExceptionContext, bool considerPassingToDebugger, void * returnAddress, bool resetStack) Zeile 1353	C++
Krom.exe!Js::JavascriptExceptionOperators::ThrowExceptionObject(Js::JavascriptExceptionObject * exceptionObject, Js::ScriptContext * scriptContext, bool considerPassingToDebugger, void * returnAddress, bool resetStack) Zeile 1389	C++
Krom.exe!Js::JavascriptExceptionOperators::Throw(void * object, Js::ScriptContext * scriptContext) Zeile 1088	C++
Krom.exe!Js::JavascriptError::ThrowReferenceError(Js::ScriptContext * scriptContext, int hCode, const wchar_t * varName) Zeile 293	C++
Krom.exe!Js::JavascriptOperators::OP_GetRootProperty(void * instance, int propertyId, Js::PropertyValueInfo * info, Js::ScriptContext * scriptContext) Zeile 2206	C++
Krom.exe!Js::JavascriptOperators::PatchGetRootValueNoFastPath(Js::FunctionBody * const functionBody, Js::InlineCache * const inlineCache, const unsigned int inlineCacheIndex, Js::DynamicObject * object, int propertyId) Zeile 8207	C++
Krom.exe!Js::JavascriptOperators::PatchGetRootValueNoFastPath_Var(Js::FunctionBody * const functionBody, Js::InlineCache * const inlineCache, const unsigned int inlineCacheIndex, void * instance, int propertyId) Zeile 8196	C++
Krom.exe!Js::ProfilingHelpers::ProfiledLdFld<1,0,0>(void * const instance, const int propertyId, Js::InlineCache * const inlineCache, const unsigned int inlineCacheIndex, Js::FunctionBody * const functionBody, void * const thisInstance) Zeile 995	C++
Krom.exe!Js::ProfilingHelpers::ProfiledLdFldForTypeOf<1,0,0>(void * const instance, const int propertyId, Js::InlineCache * const inlineCache, const unsigned int inlineCacheIndex, Js::FunctionBody * const functionBody) Zeile 1068	C++
Krom.exe!Js::InterpreterStackFrame::OP_ProfiledGetRootPropertyForTypeOf<Js::OpLayoutT_ElementRootCP<Js::LayoutSizePolicy<1>> const>(const Js::OpLayoutT_ElementRootCP<Js::LayoutSizePolicy<1>> * playout) Zeile 4221	C++
Krom.exe!Js::InterpreterStackFrame::ProcessWithDebuggingExtendedMediumLayoutPrefix(const unsigned char * ip) Zeile 180	C++
Krom.exe!Js::InterpreterStackFrame::ProcessWithDebugging() Zeile 358	C++
Krom.exe!Js::InterpreterStackFrame::DebugProcess() Zeile 2530	C++
Krom.exe!Js::InterpreterStackFrame::InterpreterThunk(Js::JavascriptCallStackLayout * layout) Zeile 1846	C++
[Externer Code]
Krom.exe!amd64_CallFunction() Zeile 208	Unbekannt
Krom.exe!Js::JavascriptFunction::CallFunction<1>(Js::RecyclableObject * function, void *(*)(Js::RecyclableObject *, Js::CallInfo) entryPoint, Js::Arguments args, bool useLargeArgCount) Zeile 1366	C++
Krom.exe!Js::ScriptContext::DebugProfileProbeThunk::__l63::<Lambdafunktion>() Zeile 4704	C++
Krom.exe!ThreadContext::SafeReentrantCall<void * <Lambdafunktion>(void)>(Js::ScriptContext::DebugProfileProbeThunk::__l63::void * <Lambdafunktion>(void) fn) Zeile 1870	C++
Krom.exe!Js::ScriptContext::DebugProfileProbeThunk(Js::RecyclableObject * callable, Js::CallInfo callInfo, ...) Zeile 4700	C++
Krom.exe!amd64_CallFunction() Zeile 208	Unbekannt
Krom.exe!Js::JavascriptFunction::CallFunction<1>(Js::RecyclableObject * function, void *(*)(Js::RecyclableObject *, Js::CallInfo) entryPoint, Js::Arguments args, bool useLargeArgCount) Zeile 1366	C++
Krom.exe!Js::JavascriptFunction::CallRootFunctionInternal(Js::RecyclableObject * obj, Js::Arguments args, Js::ScriptContext * scriptContext, bool inScript) Zeile 772	C++
Krom.exe!Js::JavascriptFunction::CallRootFunction(Js::RecyclableObject * obj, Js::Arguments args, Js::ScriptContext * scriptContext, bool inScript) Zeile 732	C++
Krom.exe!Js::JavascriptFunction::CallRootFunction(Js::Arguments args, Js::ScriptContext * scriptContext, bool inScript) Zeile 833	C++
Krom.exe!RunScriptCore::__l2::<Lambdafunktion>(Js::ScriptContext * scriptContext, TTD::TTDJsRTActionResultAutoRecorder & _actionEntryPopper) Zeile 3705	C++
Krom.exe!ContextAPIWrapper::__l2::<Lambdafunktion>(Js::ScriptContext * scriptContext) Zeile 238	C++
Krom.exe!ContextAPIWrapper_Core<0,_JsErrorCode <Lambdafunktion>(Js::ScriptContext *)>(ContextAPIWrapper::__l2::_JsErrorCode <Lambdafunktion>(Js::ScriptContext *) fn) Zeile 192	C++
Krom.exe!ContextAPIWrapper<0,_JsErrorCode <Lambdafunktion>(Js::ScriptContext *, TTD::TTDJsRTActionResultAutoRecorder &)>(RunScriptCore::__l2::_JsErrorCode <Lambdafunktion>(Js::ScriptContext *, TTD::TTDJsRTActionResultAutoRecorder &) fn) Zeile 235	C++
>	Krom.exe!RunScriptCore(void * scriptSource, const unsigned char * script, unsigned __int64 cb, LoadScriptFlag loadScriptFlag, unsigned __int64 sourceContext, const wchar_t * sourceUrl, bool parseOnly, _JsParseScriptAttributes parseAttributes, bool isSourceModule, void * * result) Zeile 3656	C++
Krom.exe!CompileRun(void * scriptVal, unsigned __int64 sourceContext, void * sourceUrl, _JsParseScriptAttributes parseAttributes, void * * result, bool parseOnly) Zeile 5021	C++
Krom.exe!JsRun(void * scriptVal, unsigned __int64 sourceContext, void * sourceUrl, _JsParseScriptAttributes parseAttributes, void * * result) Zeile 5043	C++
Krom.exe!anonymous namespace'::startKrom(char * scriptfile) Zeile 2658	C++
Krom.exe!kickstart(int argc, char * * argv) Zeile 3667	C++
Krom.exe!WinMain(HINSTANCE__ * __formal, HINSTANCE__ * __formal, char * lpCmdLine, int __formal) Zeile 1073	C++
[Externer Code]


But it seems that these errors are rather irrelevant.
I get another exception after that, using the most basic Kha project thats possible (just calling kha.System.start({title: "Test", width: 600, height: 400, initialized) and initialized is an empty method:

Not enough memory on image.c Buffer.
outofmem
D3D11 ERROR: ID3D11Device::CreateTexture2D: The Dimensions are invalid. For feature level D3D_FEATURE_LEVEL_11_0, the Width (value = -858993460) must be between 1 and 16384, inclusively. The Height (value = -858993460) must be between 1 and 16384, inclusively. And, the ArraySize (value = 1) must be between 1 and 2048, inclusively. [ STATE_CREATION ERROR #101: CREATETEXTURE2D_INVALIDDIMENSIONS]
Ausnahme ausgelöst bei 0x00007FFAC384A839 in Krom.exe: Microsoft C++-Ausnahme: _com_error bei Speicherort 0x000000556AD6D070.
D3D11 ERROR: ID3D11Device::CreateTexture2D: Returning E_INVALIDARG, meaning invalid parameters were passed. [ STATE_CREATION ERROR #104: CREATETEXTURE2D_INVALIDARG_RETURN]
Krom.exe hat einen Haltepunkt ausgelöst.


Edit 3: The error metioned in Edit 2 is gone, I don't now why. Suddenly it worked after a lot of retrying. The project doesn't seem to update sometimes, it seems like I first have to add a syntax error intentionally so that it does a clean rebuild.

• timodriaan

Hi,

I think I've found a bug with copy/pasting in Krom and in order to get more into C++, I want to try to find the root of the problem before opening an issue (or a PR in the best case).

So I followed the build steps from the Kode/Krom readme, and everything works fine until I try to start Krom from within Kode Studio. The status bar at the bottom gets orange (so I think Krom is running in the background), but no window opens.

This is my configuration:

• Microsoft Visual Studio 2019:
Solution Explorer > Krom > Properties > Debugging > Command Line Arguments (translated from German, might differ):
someAbsoluteProjectPath\build\krom\ --debug 9988

Then I click on "Local Windows Debugger" and the output window prints Server started. So that part seems to work.

• Kode Studio (version 18.11.0)
Settings:

• Kha Path: someAbsolutePath\Forks\Kha (my local Git repository)
• Krom Path: someAbsolutePath\Forks\Krom (my local Git repository, \Forks\Krom\build\x64\Debug does not work too)
• launch.json:
   {
"configurations": [
{
"type": "krom",
"request": "attach",
"name": "Krom-Test",
"port": 9988,
},
{
"type": "electron",
"request": "launch",
"name": "Kha: HTML5",
"appDir": "\${workspaceFolder}/build/debug-html5",
"sourceMaps": true,
"preLaunchTask": "Kha: Build for Debug HTML5"
},
{
"type": "krom",
"request": "launch",
"name": "Kha: Krom",
}
],
"compounds": []
}


When I run the "Krom-Test" configuration (Krom is already running from VS as described in the readme), the project compiles but there is no window. I get no error message at all but there is a strange warning:

The debug type is not recognized. Make sure that you have a corresponding debug extension installed and that it is enabled.

It refers to the "type": "krom" line in the "Krom-Test" configuration at the top. If I change "attach" to "launch", the warning is gone. Running the other krom configuration also doesn't open a window, but the status bar remains blue.

I hope it's not just a Kode Studio bug, otherwise I wasted the last two hours searching for the issue^^

Thank you

• timodriaan

Ok, thank very much!

• timodriaan

All right, thank you very much.

I think I will first try to use a custom cursor for everything, maybe that works without being too noticable. If that doesn't help, yes, looking up the Windows API might be a solution but currently I have not enough knowledge to use it from Haxe (probably needs native code for every supported target?) and how to write good C++ code. And then there is still the question how it behaves on maxOS and Linux.

Sad to hear that this will not be implemented in Kha but I totally understand that this is not on your priority list.

Edit: Oh, and there is no way to read the current mouse position without relying on the event listener so that the drawing code itself uses the most-current position at the end of the frame?

• timodriaan

Yes I was comparing a custom drawn cursor to the OS cursor.

That's very unfortunate. In my project, the custom cursor is not always drawn but only if the mouse hovers over certain objects, so there is a noticable difference when the cursor changes. If there is no other solution to this issue, I will just draw the custom cursor all the time (with different cursor images) and completely disable the OS cursor so that the behaviour is at least consistent.

I made a screencast of my screen with both the custom and the os cursor enabled and compared it frame by frame and it actually looks like the custom cursor is even two frames behind. It is drawn at the end of the drawing loop and draws directly to the Graphics2 object of the first given framebuffer from the notifyOnFrames() callback (actually I use Armory3D's notifyOnRender2D() callback but that is basically what it does). Do you have any idea why this could be? Maybe one frame behind is not that noticable as two frames.

Or is there any possiblity to change the hardware sprite? Kha does not support it or does it? I know almost nothing about this topic but it looks like it is possible to change the sprite, I've found some C++ libraries that claim they can do this.

Thanks again

• timodriaan

Hi,

is there a way in Kha to get the current mouse position without relying on mouse.notify(..., ..., onMove, ...)?

I want to implement custom mouse cursors but the problem is that they are lagging a bit behind. I think this is due to the fact that the mouse position changes faster than the drawing rate (or this might have to do with swapping the frontbuffer and the backbuffer), so if there was a way to get the mouse position during drawing that would probably solve the problem (or make it less obvious at least).

I don't think this possibility exists, or does it? Is there perhaps another way around this issue?

Thank you very much

• timodriaan

Thank you very much, that works!

• timodriaan

Hi,

is it possible to somehow access assets or files from the project directory in macros?

When using kha.Assets.loadBlob() in a macro I get the following error:

Path\to\Kha\Backends\Krom/kha/arrays/Float32Array.hx:5: characters 23-42 : You cannot access the js package while in a macro (for js.lib.Float32Array)


So I thought about using the Sys API instead, it is available during compile time. But the issue here is that I can't find out how to get the project path. Sys.getCwd() works (it returns the build/debug` directory), but it is a very ugly solution and i'm not sure if it returns the same relative path on all targets and for all situations.

Thank you very much

• timodriaan

We're probably still talking past each other - but nevermind. Its not that important. I just thought about a (maybe possible) way to ensure that Mac users still can use right click (exactly like Mac users are used to use it, as you said) without "special functionality". Everything would work like before. Command key shortcuts would still work as command key shortcuts, but under the hood they would be treated differently. However (as mentioned before), it would only work under the condition that there currently is no KeyCode for the command key - which I don't know, I can't find it and can't test it mysef.

But forget about it, I opened a PR to remove the ctrl+right click code. Thank you very much

• timodriaan

Yes thats true, maybe it's just my bad english thats misleading here, so I try to explain it again.

Lets say (and this only works if there is no keycode assigned for the command key on macs in Kha! I can't find one or is it the meta key?) we reroute all button presses on the command key to the control key.

So, every time a mac user holds down the command key, the control key event is fired instead. This way, mac users would be able to still use ctrl + click to simulate a left click (with the native mac os implementation, not the soon-to-be-removed html5 implementation we're talking about) but would also be able to use ctrl + [someKey] commands through using the command key as a replacement for the control key and the control key has no further functions. For Windows & Linux users, nothing would change as the control key still remains the control key.

I hope this is a better explanation. But as I mentioned before, this is possibly very naive. And again, if the command key has a keycode assigned in Kha, this isn't working as programs could implement both cmd and ctrl shortcuts. If the keycode for cmd exists, just forget about this idea.

Anyway, maybe it's just the best to let program owners decide about how they wan't to implement shortcuts for mac and windows. It is probably not a good style to take away decisions from programmers on how to design their software.