Saying Hi about pico2tic HOT 5 CLOSED

Hi @bztsrc--

That's fantastic! Very useful resource you've made-- thanks for letting me know about it. (Also, I've been WASM-curious for a while so it's great to look at your repo and see how it should be done.)

I don't know if I could offer any suggestions for improvement, just a question: is there a reason you converted the wrapper library to a C-string instead of just loading it at run-time?

Beyond that, if you've made any improvements to the embedded code, please feel free to submit them as a PR!

Thanks, and best wishes,

Nick

from pico2tic.

Thanks!

Also, I've been WASM-curious for a while so it's great to look at your repo and see how it should be done.

Not sure such a thing exists with wasm. It's a mega giga hack with lots of pitfalls and trial-and-errors, and millions of different ways to do the same thing, one being more efficient or suitable for a certain use case than the others.

is there a reason you converted the wrapper library to a C-string instead of just loading it at run-time?

Not sure what you mean. I haven't converted any lib to string. If you mean the wasm bytecode, then the .js file which wraps and loads it was generated by the compiler, not written by me. If you're interested, in one of my other projects I'm loading the wasm bytecode directly. (And realized that fullscreen doesn't work that way... don't ask why.) Here I was lazy, I've aimed the simplest possible approach, because all I needed from JavaScript was a function call into the wasm binary (the other solution requires setting up a main loop in C, and grabs control from JavaScript). So instead I've used the cwrap function here which makes one call and returns immediately (there are million other ways to export/import functions, I've just found this one the easiest in this case.)

But if you meant the C string (like the cartridge data), yeah, that's truly problematic. Javascript can't access wasm variables, and wasm can't access JavaScript variables either. So the only way to transfer data between these two, is to allocate memory using wasm's allocator (which returns a JS variable containing a memory address pointing inside the wasm memory), and then call Module.HEAPU8.set which copies the data from JS memory to wasm memory. Pure waste of resources? Absolutely yes, but considering cartridge data shouldn't be too big (few kilo tops), I felt no need to use more complicated methods.

Beyond that, if you've made any improvements to the embedded code, please feel free to submit them as a PR!

Not really, it works really fine. Actually all modification I made was shrinking its size, converting Lua directly instead. But I can see now that there's no other way, it just cannot be done without a supporting library like yours. Anyway, despite the fact that I'm not using all of your lib as-is, I'd like to say thanks, and if you want any more attribution for your code than I have now, let me know!

Cheers,
bzt

from pico2tic.

is there a reason you converted the wrapper library to a C-string instead of just loading it at run-time?

Ah, perhaps you meant why have I added your lib to the C source as a string? That's because you can't load files from wasm in run-time (not unless you also compile a memory ramdisk, which is a pure overkill, and plus one file to distribute). I'm getting the Lua code as a string, and output it is as a string, so it made sense to embed the part needed to be added as a string too.

Cheers,
bzt

from pico2tic.

Ah, perhaps you meant why have I added your lib to the C source as a string? That's because you can't load files from wasm in run-time (not unless you also compile a memory ramdisk, which is a pure overkill, and plus one file to distribute). I'm getting the Lua code as a string, and output it is as a string, so it made sense to embed the part needed to be added as a string too.

Yes, that's what I meant. Makes sense, thanks for the explanation!

if you want any more attribution for your code than I have now, let me know!

If it's easy to throw a link to this wrapper library Git repo up on the main page, I'd appreciate it — not because I particularly need any acknowledgement, but it would be good to direct any TIC-80 experts here to contribute improvements to the underlying wrapper library. (I have a feeling that someone more familiar with the current state of TIC could fix the outstanding issues here rather quickly.)

from pico2tic.

Yes, that's what I meant. Makes sense, thanks for the explanation!

You're welcome!

If it's easy to throw a link to this wrapper library Git repo up on the main page, I'd appreciate it

Your repo was already linked in my repo's README, but sure thing, I can add it to the webpage too, consider it done!

I'm going to close this issue now, because there's no point in keeping it open, however if you figure out how to convert pico-8 music assets to tic-80 music, let me know, will you? I already generate the wave patterns, that shouldn't be an issue, but I'm stuck with the rest.

Cheers,
bzt

from pico2tic.