nice, that i could surprise you
Would be interesting to get more information about this, but i'll be not able to find out. There are a lot of programming-techincs that i don't understand.

For you i've uploaded a pre-beta-version of my program (http://www.art-ganseforth.de/glLive3d/1 ... Live3d.rar) with the file-/folder-system at work and several artefacts, .... but stable on my thinkpad x230 under win10.
Within some weeks i'll hopefully have a non-pre beta-version.

Note that after just pressing the (top-left) play-button,you sould see something happening, but without some more clicks, you'll get no output on the output-frame (currently covered by the control-window after startup) and the main-preview. Look out for module "Screen 1" and for the selection-control above the (large) main-preview-canvas, that is on left side at top. Click the select-contol without text, and select "Renderer3d 1", so see more - but don't click the "( i )"-button next to i. It'll crash...

Note also, that this is a "grown" program where i started to work on without any idea of OpenGL (wxWidgets i know a bit longer). This is the result after (i think) five years of spending much of my free time into it and that i never could have programmed without the help of around five to ten people that supported me via inernet, like you. So, this are my "pre-beta-credits" for you.

The C-sources i can give you on request, but don't complain if you get a headache (or even mor dangerous things) after reading two screenpages.

Unfortunately it crashes immediately for me when i press the "play" button.

I'm not really supprised. As i sometimes find solutions by chance (not really knowing, what i'm doing), some of the "solutions" i found, might result out of - hmmm - errors. In fact i'm happy, that it doesn't crash while starting :/
The point is: Once i i.e. used reactor (a modular software-synthesizer, where i took lots of ideas from, for my application), where i "programmed" several syntesizer-patches for. Some of them used division by zero resulting zero. For some calculations, this was quiet comfortable but in fact, it was a bug in the application itself, that this was working. So, with the next version (officially 100%-backard-comatible), many of my patches crashed.
Maybe, simelar to this, i found "solutions" that only work on my PC. Especially with OpenGL i'm not sure concerning this, but also concerning wxWidgeds there are some points where (mostly you) told me, that they won't work. Waht i mean that - using trial and error - i maybe found a "solution" based on a driver-bug that isn't existing on your system (using different drivers) or someting simelar.

Okay: wxWidgets is mostly a high-level library. So in my eyes there is no real reason that a build works on one PC and crashes the other. But OpenGL is quiet near to the system. Some days ago, someone in OpenGL-forum told me i.e. that it's undefined (which means an error), to render a frame internally to a texture, that is used as texture for this rendering-process (feedback). My program is doing this but this may be a thing that doesn't work on other GPUs or with other drivers.

Anyway: Right sided in the control-window is a debugger-module. In it's first row, you'll find a button ("Realtime") and next to it, a second one ("Frame"). Right of both is a value-select-control (0 at startup). This is the debug-level.

Click on it and select 9 (the highest) and press the "Realtime"-button (then labeld "Log").

Like this, the log-file (log.html) will document where it crashed. Would be itresting for me to know this...

The log-file says, that one shader doesn't compile. Normally this doesn't crash the program, but in especially this case (the shader generates a vertex-array), i have to catch the case that te array is not generated at startup. I had this problem here also if this shader had an error at startup. Once working a error in the shader is no problem because the array then exists.
This is an important point i should not forget. Unfortunately the exact reason for shaders not compiling are not logd. Also this i have to change. Good to know this right now, because i just want to replace my shader-compilation-routine with a more flexible one.

Also good to know, that the program loads and the UI is shown. So the interpreter and it's wxWidgets-interface works so far. This is good because this is the part of my application, that i consider as mostly finished.
The problem is an OpenGL thing where I'm currently working on and that may also have to do with this ugly Intel-OpenGL-driver on my pc. As i in between learned, it is buggy and differs in several points from the OpenGL-specifications. Therefore at least shaders (but also maybe other OpenGL-things) that are programmed on my computer, may have problems on other systems.

All in all this result is quiet satisfieing for me and helps me a lot. Obviously i'm on the right way if i now start to really work out the OpenGL-interface, where i programmed this UI for. As (i hope that) i've prepared this well, within some weeks i shold have someting that really can be used.

doublemax wrote:BTW: Please make the color theme of the GUI editable. The current colors have low contrast and make it hard to read. At least for me, my eyesight is not the best

It is editable already
The global settings are done in config/Kernel-data.txt, but each control can be colored individually also. The class-definitions for the controls are in config/controls.txt. The only thing that is not changable (i was too lazy until now, to implement these ~5 lines), is the font-type and things like italics (bold exists).

I don't have the concetration for programming today, so i'll take time for some more words:

Concerning my interpreter(s): It's always the same. I start something as a fixed program, but after a while it's getting more and more paramererisized (mostly using strings). So it always leads in some kind of interpreter. Therefore, a while ago i learned how to pogram also a math-interpreter doing all standard operations.
This one is not really good like it's i.e. using new and delete controlled by smart-pointers and many strcmp-calls. Last year i wrote another one with it's own memory-management that is near to a runtime-compiler. Therefore, i was thinking about reprogramming my project completly (and i still do).
The point is, that i started with ANSI-C >25years ago and even if i never programmed assambler (thinking about trying it), i'm better in low-level things, than in high-level oop.

If you want to have a closer look:
Look in config/loader.txt to see how the interpreter in constructing the UI.

The interpreter has an uncommon way to use namspaces: Children in nested objects can acces parent's names / variables like own, as long they are not (locally) oveloaded. Like this, i.e. the color-settings work globally, because they are set in the root.

The files in folder "config" are "executed" mostly at startup. The files in "dynamic" are loaded on demand. There is an abstract module in config/system-modules.txt ("DynamicModule"), taking a file-name as parameter, that is doing this. This most important for te concept at all, because these files (in "dynamic") may be edited or even created at runtime. Changes will be applied to afterwats added modules.

In config/Kernal-data.txt is the main-loop.

The interpreter uses GLfloat and char* as only types and it's not typesafe. It's syntax is near to js.

Midi was working once, but is currently out of order. If it works again, the GUI may also be used to control audio-things.

The mouse-wheel should work over all numeric controls; the main-window shall move using the control-bar, but it currently doesn't.

There is an issue with refreshing after modules are moved or resized. That worked fine some days ago and will work again.

Closing the "Basic 3d objects 1" should maybe stop the crashes, but then no rendering is performed anymore. Only the scopes (using wxBitmap) will maybe do someting. (Selecting another "function", that are not initialized correctly on startup, should lead to some "relistic" result on the scopes).