Good vs. Evil

  • The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
GamerwithnoGame

GamerwithnoGame

Over-Achiever
Jan 29, 2015
2,808
1,507
224
45. Is tireds again :( I want to try and stay up a bit though, I don't get many days where I can actually stay up late. Friday and Saturday, basically
 
lenscas

lenscas

Over-Achiever
Jul 31, 2013
2,015
1,801
248
45 finally had some time to work on arena keeper again. However, I don't have much to show this time. This is because I didn't have much time and I'm restructuring the game to consist of 2 parts (Or 3 depending on how you count)

The biggest problem I'm facing now though is getting this split to work in the browser.
The 2 parts that I am splitting my game into are what I call the "engine" and the main "module". The potential third one is some helper code that is shared between the two to make development easier.

The engine contains the game loop, loads everything that needs to be loaded, and other stuff you expect from an engine.
The module part is a .wasm file that adds actual content to the game. So as an example: the engine will define a basic entity struct and its the job of the module to extend it to create a "merfolk" struct.

The module being a wasm file greatly limits how the two parts are able to communicate, and right now I plan to use the basic scheme provided in this tutorial.
Simply put, in order for the engine to execute a function in the module that requires the passing of "complicated" data the following steps will take place:
  1. Zero out the first 4 bytes of the memory from the module
  2. convert the data into a shared binary format
  3. get the length of this binary data and write it down somewhere in the memory of the module
  4. call the function, passing the location of this data together with the length
  5. The module is able to convert it back and does it magic
  6. Once the module is done, it converts the new data to the binary format
  7. write the binary data somewhere in memory
  8. get the length and store it in the first 4 bytes
  9. return the position of the new data
  10. The engine, reads the first 4 bytes to get the length
  11. It then uses the returned position and the length to read the newly returned data
  12. Convert the data back into something it can use
As you can see, that are quite a few steps and also not exactly the nicest ones. This is where the glue code comes into play. It contains a serialize and deserialize function and a macro for the module side that automatically converts normal functions into ones that use this scheme.

The main problem that I am actually running into however is that the wasm library that I use doesn't itself compile to WASM. As a result, I need to write some javascript that will do the same thing.


And yes, this means that getting WASM to work inside the browser turns out to be more work then to get it to work on native builds.

  1. Every module has its own memory.
  2. Except for exploits like specter/meltdown modules can't read system memory
  3. Modules have no access to file IO except for what the engine provides
  4. Modules also have no access to JS functions
  5. Every language is supported.
  6. Works in the browser with minimal overhead (I don't have to ship an entire VM with my game when it is running in the browser)
  7. WASM is awesome!
 
duckfan77

duckfan77

Popular Member
Mar 18, 2013
80
683
118
45 It did! I might discuss it, if you want to know, since I like and trust you, just not in public.
 
Last edited:
You must log in or register to reply here.
Top Bottom