Actually uses spasm in bash about virtual3d HOT 4 CLOSED

Indeed, both the build.bat and the build_model.sh / build_model.bat still use the old spasm. Thanks for pointing it out, I completely looked over it, gonna fix it asap.

There was indeed plan to implement it in C. However, it is not as straightforward as it could be. A lot of memory is reorganized at the engine init (so much that it clobbers C heap), and before I look in detail what C lib linking / using does, I can't guarantee the correct pathing of the linking and function.

For records, the engine init save the whole RAM in a flash image (stored into the swap area), and restore it at exit. Consecutively, it use both $D0 and $D3 RAM page in full along side first quarter of $D1. And of course the whole VRAM.

So in order to create a C wrapper, we need :

• To make sure what memory areas are used by all the C lib of the toolchain
• Libload linking mechanism and make sure we dont break it
• Having a perfectly crafted initialization RAM image for the library (I implemented half of it currently thanks to power of fasmg)
• Create the actual library with correct export value and function wrapper (all function take right now register as argument instead of stack)

It is kinda why I wanted to wait for the RAM area used within the lib to stabilize (which in pursue of performance never really happened).
Anyway, I'll create a project for that, and if you have any question, please ask.
One thing that could be great from this is also the creation of an underlying doc in the same time, since it will force to review every function.

from virtual3d.

Spasm should have been removed entirely in commit 1b0a151
Can you please test the windows build system ? Thanks.

from virtual3d.

the windows build system ?

Windows builds now work flawlessly.

from virtual3d.

Perfect ! Closing the issue. For the C port, a new issue should be created (and there is also now the project page).

from virtual3d.