I have managed to embed ProjectABE into a website with normal hex files. How do I do it with FX games?
<iframe src="https://felipemanga.github.io/ProjectABE/?hex=http://www.bloggingadeadhorse.com/ppot/hex/LeWord.hex&data=http://www.bloggingadeadhorse.com/ppot/hex/LeWord.bin" width="480" height="760">
<iframe src="https://felipemanga.github.io/ProjectABE/?hex=http://www.bloggingadeadhorse.com/ppot/hex/LeWord.arduboy" width="480" height="760">
Hmm your embeds don’t seem to be loading quite right here. I can’t find the post but I FX support was added through .arduboy files somehow. You might just be able to add the .bin to the .arduboy file and it magically works?? (?)
Also, can you share how you are doing the deployment? I’d love to get a little portable “package” so people can easily put their games on itch.io
I’m guessing your using gh-pages version then you can use something as:
<your URL>/index.html?url=<hexfile>&data=<bin file>&skin=BareFit
or if your webserver supports it (without index.html):
<your URL>/?url=<hexfile>&data=<bin file>&skin=BareFit
If the data does not load try using a relative path instead.
Here is an Example URL that works for me.
if you want a clean url without the parameters then you can edit the index html file and the following line under the meta line Credits for this trick go to @unwiredben
<script>if (location.search == "") location = location + "?url=<your hexfile>&data=<your fx data bin file>&skin=BareFit"</script>
Needless to say is to replace and including the < and > with the (relative) URL of the relevant file
Oh I think I misunderstood the question. I thought you embedded the PRoject ABE files on your own website rather than using the existing ProjectABE.
The reason your files don’t load is because of the infamous CORS policy.
Sorry, I have put the back ticks in place so you can see my call.
But it has worked where I was using a single hex file:
<iframe src="https://felipemanga.github.io/ProjectABE/?hex=http://www.bloggingadeadhorse.com/ppot/hex/RoadTrip.hex" width="480" height="760">
I can drag and drop the hex/bin or Arduboy file onto the emulator and it works. So I am comfortable that the files are built correctly.
@bateske unfortunately I am just using Felipe’s site.
I have been using hex for single hex files and it works properly.
?url= ..&bin= and
?hex=..&bin=.. them both but neither worked.
I also pushed my arduboy file to a github.io site as I thought it might get around and CORS issues.
I tried all of these without success:
<iframe src="https://felipemanga.github.io/ProjectABE/?url=https://press-play-on-tape.github.io/LeWord.arduboy&skin=BareFit" width="480" height="240">
<iframe src="https://felipemanga.github.io/ProjectABE/?arduboy=https://press-play-on-tape.github.io/LeWord.arduboy&skin=BareFit" width="480" height="240">
<iframe src="https://felipemanga.github.io/ProjectABE/?hex=https://press-play-on-tape.github.io/LeWord.arduboy&skin=BareFit" width="480" height="240">
Yeah I know. when the bin part is added the CORS policy seems to be triggered. From Chrome debug console output:
Access to fetch at ‘https://rx3p41v9qj.execute-api.us-east-1.amazonaws.com/dev/?url=https://rx3p41v9qj.execute-api.us-east-1.amazonaws.com/dev/?url=http://www.bloggingadeadhorse.com/ppot/hex/LeWord.bin’ from origin ‘https://felipemanga.github.io’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.
Basically what you need to do is:
- download gh-pages and unzip it. Files will be extracted to a folder called ProjectABE-gh-pages
- rename the ProjectABE-gh-pages to your project name
- Copy your hex file into the folder and rename it game.hex
- For an FX game, copy fxdata.bin file into the folder too
- edit the index.html file and replace all the content with below text and save it:
<script>if (location.search == "") location = location + "?url=game.hex&data=fxdata.bin&skin=BareFit"</script>
<link rel="stylesheet" href="style.css">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
<title>ProjectABE - Arduboy Emulator</title>
- zip up all the files in the folder and it upload it on itch.io
If you want I can make a zip where only relevant files are included and only the game.hex and fxdata.bin have to be replaced (and it can be uploaded to itch.io as a test draft)
So I think the emulator is using the CORS proxy hosted by @unwiredben it may be he has created a universal proxy for .hex files but only allowed .arduboy files from the community?
You’re not “supposed” to make universal proxies, but for our application we aren’t doing anything security related and it’s all sandboxed in github anyways so it shouldn’t be an issue.
I think that’s what’s going on? Maybe Ben can comment.
The only way get around the CORS (proxy) issue is to put a copy of project abe (gh-pages) on the same domain as the arduboy/hex/fxdata files. I’ve got a stripped down version of about 660KB or 206KB zipped now (that’s including a hex file and fx data file).
@filmote Here’s LeWord running as a test on my website.
Stripped down version: abe-lite.zip (205.4 KB)
I just checked the code, and I should allow proxying of .hex, .arduboy, and .json files. It doesn’t support .bin files, though, and I’m not sure I’d want to support that, as that would allow a lot more things to be pulled through it. Is there another arduboy-specific extension we could use here?
.bin files would be nice too. would be easier to test fx games.
How do you reference the bin file if it’s not contained within the Arduboy file?
@filmote are you getting any errors in your console or http logs?
When I ran:
(which seems to be correct, the “?url=”)
Is there like a maximum size packet or something to be pulled through CORS?
Should try running a small “normal” sized .arduboy file through this method see what we get.
Even normal small sized files are getting this error. This is what I got from ArduyIndy.arduboy
&data=fxdata.bin to the url.
I got to debug this more. I definitely see different data with or without the CORS proxy, so I think it’s tied to content encoding.
Just to throw a crazy idea out there:
What if we made it so that FX data files were also in the Intel Hex format like
.hex files rather than just being raw data?
It would increase file sizes, but it would mean the system would be passing around plaintext instead of binary, so the security risk should be no more than it already is.
The emulator must already have Intel Hex parsing capability anyway to be able to run games from
.hex files, and I’m presuming the Python tools do to in order to read
.hex files and place the data in the cart, so it shouldn’t be too much more effort to leverage that to store other cart data in Intel Hex format.
I really think the .arduboy files are being used as intended here there is just some kind of bug due to file size looks like.
Also the ability to edit them by just converting them to a .zip otherwise you’d need a dedicated utility.
No new formats lol
I made the .arduboy file with only the .hex and .json in it and the error changed, but noticed the warning on top is actually persistent and I think the actual cause:
Hmm, nope that warning comes up even when you play it with a working hex file.
Something is going on when grabbing .arduboy files from other places that are not the community?
ArduIndy.arduboy (27.0 KB)
Confirmed it is .arduboy files hosted anywhere besides the community introduce some kind of error that manifests in the zip decompression stage. It seems like if hosted anywhere besides the community the emulator is only getting some, or maybe just the header of the zip file?
@unwiredben is there any difference to the CORS policy for .arduboy files from the community versus other place? And versus .hex files? It seems uncompressed files work, so it’s whatever that gets retrieved when requesting .arduboy from a non community site gives some kind of return - just incomplete?
If @FManga has a moment to come in and take a look at this?
It seems like .arduboy files are not getting properly decompressed when they are hosted by somewhere different than the community or on the same domain as the emulator.
I can see this just by using curl – it’s definitely a proxy problem, and I think it’s tied to an old version of node request that’s being used. I’m going to play with the code tonight and see if I can get it back on track.
ARGHH! I found the problem. Somewhere in the node code, it’s converting the binary of the request into UTF-8, so any byte above 0x7F gets converted into two bytes. This is maddening, but should be easy to fix. This didn’t affect .hex files, since they’re all low-ASCII, but I’d guess .arduboy files never worked.
But they do, only on the community or on the same domain. Perhaps certain hosts lock the data type… or something?