Commander X16

54 minutes ago, MattGrandis said:

I'm adding the new functionality now. I'll have to adapt some code on the server to add dealing with zip files, so until further notice, the Try it now function might break! I'll give notice here when everything's back to normal again.

Sounds good.  And also if you think you the manifest/zip file mechanism for loading is missing something or could be done in a different/better way, please let me know. I am open to make modifications to make it as easy/useful as possible.

We've been mulling over whether it would be a good idea to be able to put the manifest.json OUTSIDE the zip file, but before you do any work in that direction (unless you want to), I'll try rewriting our code so it adds the manifest.json directly to the zip file. One thing though: it looks like the "old" way doesn't work anymore. It's throwing an error: "Unable to read manifest. Check the manifest http parameter".

See here: https://www.commanderx16.com/emulator/x16emu.html?manifest=/emulator/9-chase-vault/

The manifest.json file still exists like before.

15 minutes ago, MattGrandis said:

We've been mulling over whether it would be a good idea to be able to put the manifest.json OUTSIDE the zip file, but before you do any work in that direction (unless you want to), I'll try rewriting our code so it adds the manifest.json directly to the zip file. One thing though: it looks like the "old" way doesn't work anymore. It's throwing an error: "Unable to read manifest. Check the manifest http parameter".



See here: https://www.commanderx16.com/emulator/x16emu.html?manifest=/emulator/9-chase-vault/



The manifest.json file still exists like before.

I am fixing that now... copy&paste bug. I wish I had some unit-tests that could have caught that.

In regards to the manifest.json separate from the zip, i thought about this too. Then inside the manifest we could have a link to the .zip file. also another thought if we do this, do we then really need the resources section or do we just load any file that is inside the zip the manifest is pointing to. That would make it easier to not have to maintain the list of resources to be loaded.

so the manifest could just be

{

...

start_prg: FILE.PRG

resource: https://x16repos.s3.amazonaws.com/chase.zip

}

I don't know, i kind of like that everything could be self-contained in one zip, but on the other hand it would simplify things. the developer would just upload a zip with all his x16 assets and just say what is the start_prg and don't worry about the resources section in the manifest

 

I'm with you. I think a self-contained zip file is best. I'm trying to help devs by creating the manifest.json on the fly and injecting it into the zip file, but if it already exists -- all the better!

Fix for loading 'old' way for manifests.

https://github.com/sebastianvog/x16-emulator/releases/tag/1.0.0-beta.3

e.g.:

https://x16emu.s3.amazonaws.com/x16emu.html?manifest=https://x16repos.s3.amazonaws.com/chasevault/

 

 

I have been looking into the audio code a bit it should sound less 'crunchy' now.

https://x16emu.s3.amazonaws.com/x16emu.html?manifest=https://x16repos.s3.amazonaws.com/chase.zip

(compared to https://www.commanderx16.com/emulator/x16emu.html?manifest=/emulator/9-chase-vault/ )

I tested on a Mac with Chrome and Safari. Please let me know if that improves it for you too.

It's almost perfect on Windows 10 / Chrome. A little stutter here or there, but a lot better and very usable! On Firefox it's still stuttering though, sadly.

Looks good to me on Chrome/Windows, as well! Only the slightest stutter once or twice while I played the whole first level. It's now better than my old laptop running the native emulator!

Chrome on Linux is still struggling. The frame rate is dragging, which also causes the music to break up. Firefox on Linux is better with the frame rate, with less dragging, but the sound is crunchier. So, definitely performance varies between browsers and platforms.

I'm curious to see how it works on a Mac, which I don't have.

I have to try it on Linux yet. Performance really differs between browsers/OS combination it seems.    One thing I Still would like to try is to pass native sample rate from the browser environment to the core emulator and use this rate.  I am not sure if there is significant  extra overhead if the sample rates don’t  match. In the Code we hardcode  Samplerate to 48828. But on the Mac the native sample rate in the chrome Audio context is 44100. Not sure if that matters at all.   After doing many modification to the audio code, I reverted most of them back and only increased the samples_per_buffer constant to 1024. Which got rid of the crunchiness in most cases.