Hello Skurdt. In first congrat for your works.Skurdt wrote:The loading of the dll (using kernel32's loadlibrary function) is pretty standard, there's no other alternative afaik.
It's possible to load functions using the dllimport attribute, but it will then lock the source code to use specific dll names (as opposed to be able to load, theoretically, any present and future cores).
Doing either shouldn't take anywhere near 2 seconds though.
Now I'm guessing you are running the games from 3DArcade and not the example scene I provided with this wrapper library.
Depending on what kind of prep work is done to transition between a walking around in an arcade state and playing the game on a model, there might be some delay not related to loading the core and/or the rom itself. It's also dependent on what core and what rom is actually requested.
As for optimizations on the wrapper itself and using multithreading, as far as I'm aware, dlls and functions pointers have to be loaded, stored and called from a single thread (and probably the main one, especially in the case of Unity, to be able to have proper communication between the core and the different subsystems like rendering, input, etc...)
Coroutines can't help with load times, they only allow a function to keep running while something else is happening (it's doing a ping-pong kinda think but it's not using extra threads). They are also only available for MonoBehaviours, which I'm not using on the wrapper side at all.
If the loading of dlls and roms is the actual issue, it may have to do with disk performance (mame being multiple megabytes in size, or even in the hundreds, makes it the opposite of a lightweight dll).
Are you using a ssd of some sort or just a plain old hard drive?
For example, the app and cores are stored on a ssd for me, and I can load roms that are stored on a low-end(ish) NAS, with standard 1gb lan, and the games are starting instantly (both in 3DArcade and the wrapper's example scene).
The core and the roms are of course stored on my ssd. but to be more clear, I have no problem launching the example scene. the game works very well in this case without any freeze even with like 20 machines.
On the other hand I wanted to create a room with hundreds of machines that only activate (the GameModelSetup component) when they are in the player's field of vision. and it is during activation that the game (the whole unity scene) freeze for one to two seconds. It is not a problem of quantity of machine, because I have exactly the same freeze with only one machine which is activated during the gameplay.
TO more simpler, i need to find a way to avoid freeze when instancing machine during gameplay.
The time of loading is not a problem (2s is near nothing), but the freeze is not very comfortable during the movement of the player.
I think maybe it is the loading of DLL that causes this freeze