-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Archjs, Virtjs #13
Comments
I agree with the general principle of integrating Em-DOSBox with something like that. Making the project totally stand-alone makes it harder to integrate into a web site. All sorts of things could be made easier, such as customizing page appearance, managing DOSBox settings and reducing duplication when hosting multiple programs. I know the Archive.org people have their own loader and want to make it easy to host emulators. They've done some impressive things, like allowing emulators hosted at Archive.org to be used directly from tweets. I'm not sure how much they have done in terms of allowing others to easily host emulators on other sites. |
The advantage of Virtjs APIs over anything else is that the same devices can be used accross many different implementations. For example, assuming that you use the screen device API to render the dosbox output, then you can instantly use a WebGL-based rendering, disable the rendering, render into an output buffer, or even apply post-processing on the output. Zero code required. |
That would be nice, but that would require patching emscripten's SDL2 implementation. |
Hi,
I've started the Virtjs project, which aims to provide a modular way to specify how should an opaque core interact with an external webpage (think of it as a generic audio/video/input interface, that can be filled by multiple implementations, called "devices", some of them available straight away). For example, here is the base Screen interface, and here is the WebGL device.
For instance, Archjs is another project of mine that links these interfaces with emscripted libretro emulation cores, so that the emulators are wrote using C/C++, but the communication with the webpage is actually done with raw Javascript (avoiding any extraneous abstraction).
Using this system, there is no really need of a "template" html page: everything can be instancied with only very few lines of code. Bonus, it can also be used to run an emulator with Node (since we only need to provide a different device implementation, compatible with Node APIs).
Would you be interested in using it? I'd happy to exchange with you on this subject.
The text was updated successfully, but these errors were encountered: