Inside

thanks for the detailed answer, I'll try to do something with it. I have already tried in various ways, in particular the ssr approach on react, I returned static with the game, but this module did not start and cursed that it needed some utilities from the Windows environment to run, from which I concluded that what to run you can only build on the server and send the stream with the game through the iframe, but it would be very expensive to implement multiplayer through a web browser, since you need to contain many instances of pages on the server

Yes, I have some understanding of what is happening since I am a web developer, and I managed to run a game on Windows and collect a couple of games from developers on Mugen. But of the problems, I noticed that you need to update the assembly, as the browser specifications change and now, for example, the game does not work in Google Chrome (link below), but it works in the Safari browser. But this problem can be easily solved by simply updating the game assembly, the real problem, as I wrote above, is that the assembly of the module for some reason requires hosting through Windows, I will try to figure out on my own whether I can fix this situation by correcting the bat file

https://barklim.github.io/mugenTest/

By the way, I did not say the most important thing, this is what the purpose of running your dreamcast interpreter in the browser is that if you can statically run the game on the client (browser in this case, obviously), then I could use the webrts technology to to stream a captured home item to another user at a high frame rate, and use that connection as a channel to forward keystroke data. As you can imagine, this would provide a multiplayer option for mugen players that is still popular and launch any game builds, and all sorts of additional things could be done, but even that would be very cool.

I will try to build the game in a different way so that all the packages are in one javascript file, I just had great difficulties in order to make the statics work with a format that is not understandable for the browser (.data) it is likely that this can solve the startup wasm module in browser

if I don't find a solution to this problem, then it's still possible to create a modern spa application that will be deployed on some server with Windows, where various folders of mugen games will lie next to it. Then you can go from the spa application (where you can select some game) to these static pages with games, and on the html pages themselves, just add my custom script, which will take the ID from the browser storage to connect to the room with the game from the server (rooms with games must be created on server), so that you can was to implement a webrts connection for 2 users.

I have already written a whole sheet, but once again, I need to make a spa application and a number of folders with static html files that are mugen games wrapped in your dreamcast interpreter. This is the first option, and the second is to assemble the game into one javascript module without assets. Of course, I can’t fully explain in brief what the problem is with assets on the client, but I already wrote about the unreadable format (.data), there is a problem with the fact that some memoized game.mem.html file should be launched, which can be found in one of the scripts, but this is not perhaps within the spa application, there is also a problem with the paths to the scripts and access to the script files, but this is all a long time to describe