Hey there everyone!
I've been testing the binary exporters today and, first of all, love having this feature, but I have a few questions on how to "polish" the user experience on those exported games.

First, I struggled with not having an exit option on the menu, but figured adding a button with send_message(2, {event="shutdown"}) does de trick.

Now there's a few other things I'd like to know:

• Is there an in-system function to toggle fullscreen/windowed mode other than using the alt+enter shortcut?
• Is there a way to disable the alt+left, alt+right shortcuts, or the topbar in general? I'd like for the player to stay in the game workspace and not access the Picotron system on the exported binary.
• Saving/loading data with store / fetch doesn't seem to be working, at least on windows. Is there a way to enable this, or maybe another way to persist data?

Thanks in advance

	[8x8]

Quick update!

• Store works in binary exports if I save data to the appdata folder!
• Fullscreen/windowed can be toggled by changing the "fullscreen" value in appdata/system/settings.pod

Now all I need is a way to disable changing workspaces <3

hi @Lobo, thanks for the feedback

There's a patch (0.2.0b) coming soon that I think will address these points.

I've added "Exit Cartridge" to exports pause menu; that was a bug -- it's meant to be missing only for web exports / bbs player where there is nothing to exit to.

The 0.2.0b pause menu also has an options menu with fullscreen control, but directly changing the value in settings.pod is also fine for anyone making their own custom menus.

0.2.0b disables changing workspaces (and ctrl-p to bring up the menu) when the exported cartridge opens in fullscreen mode. A few people mentioned they would prefer that there is no way to escape the cart, and I think that is a fair expectation so is now the default. In order to allow it: window{can_escape_fullscreen = true}

Two more changes:

• I forgot to set the host Window title! 0.2.0b sets it to cart_metadata.title
• 0.2.0b can bundle extra file(s) in the zips with: export -e readme.txt foo.bin

One more change I've made for 0.2.0b: the exported cart is mounted as /ram/expcart instead of /cart. It is actually a temporary ram mount (like /system), so mounting inside /ram will hopefully make that clearer.

I don't know if that was causing the data persistence issue you were running into @Lobo, but if storing to /appdata works, then storing anywhere that is not a ram mount should also work.

Thanks for the fast response and the updates @zep!

Thank you very much for your work @zep, first of all.

I've tried the exporters, especially the windows files as that's where I usually work with Picotron.
I was looking forward to test the export of a p64 directory that includes some heavy wav files (23Mb total) that I didn't know if I could export. The thing is that if I work with them from Picotron without exporting I have no problems, but when exporting, it seems that the export is half full, maximum 12 megabytes in the sysrom.dat file. When it should occupy about 25 megabytes in my case.

So I have opted for the solution of copying them afterwards to the appdata directory of my game:

1.- I export without wav files.
2.- I copy those files to the appdata of the export.

But I don't know if this behaviour is normal in the Picotron export, as I thought it didn't have space limitations.

This is my p64 structure:

-- gfx

-- lua

-- map

-- sfx

-- wav

Thanks for your work!

@barbaro00 you cart is larger than picotron itself...raw wav and arbitrary files? you too bothered to convert them sfx or userdata? personally will not store any carts doing this in my kiosk. bad practice and encourages bloat. fine local use. export, carts where raw files take up more space? absolutely not

These are some effects I don't think are possible in SFX, or at least I don't have the skills to do them.
I wasn't planning on exporting them to any kiosk. I switched from Pico-8 to Picotron precisely because it didn't have as many limitations and isn't intended to have as many limitations. For the use I give it, I find it very pleasant to program in. I don't think of a closed system, it's my way of seeing things, the more I can do with Picotron, the better.

@barbaro00
I have to admit I didn't experiment with carts that large yet (I wasn't expecting it to happen so soon!) but it should indeed be supported to bundle wav files of that size. I'll try to get this fixed for 0.2.0b. Later on I'm also curious to see if it will be plausible to do a userland implementation of an mp3 or qoa decoder.

Thanks a lot @zep !!
The use of those wav files was thanks to @luchak (https://www.lexaloffle.com/bbs/?tid=141655). I just modified their functions to create a library in my game that controls the wav sound. It maps them in memory and creates an instrument to play them.
I wish it could use mp3...

Userland implementation of QOA should definitely be lossible! QPA for Pico-8 wasn’t that much of a modification and it runs faster than realtime there. If I had to bet, I’d say MP3 should be doable as well but I’m much less certain there.

@zep, in the HTML exporter, is also happening to me. I don't know if it's possible with that exporter, I suposse not.