Jim Dunne's video: ALTTP multiplayer demo part 1

This is a work-in-progress demo where two players (using my modified fork of the bsnes emulator) can connect to each other over a network and see the other player's Link avatar in their game as he moves around the Hyrule world. In this video, two modified SNES emulators are running side by side on the same machine (MacOS Mojave 10.14.6), both playing the SNES title "The Legend of Zelda: A Link To The Past [U] v1.2" and connected via a loopback network over UDP/IP listening on 127.0.0.1 (left) and 127.0.0.2 (right). DISCLAIMER: At this point this is just a technical demo and is not made to be user-friendly yet. No other game state is synced between emulators. There is no GUI to guide a setup process yet. There is no readily available package for download yet. However, if one is determined, all the source code is available (see below) and one can build a copy of the emulator and run the demo. HOW IT WORKS: On every frame, before rendering starts at scanline 0, the script reads the OAM sprite table and finds OAM sprites that are used to render the local Link avatar on the screen. It then reads from VRAM the 4bpp graphics data for each relevant OAM sprite and also makes a copy of the 8x 16-color sprite palettes used. The script reads local Link's absolute X, Y, and Z coordinates as well as which general screen he is on (light/dark world, overworld/dungeon, room number) which we'll call location. All this data is serialized into a variable-sized UDP packet and sent to the other player. The script then attempts to receive UDP packets from the other player, deserializes them, and uses the other player's world location and X,Y,Z coordinates within that screen to determine if he is on the local player's screen and where to render him. The typical upload bandwidth usage for standing/walking Link is 42KiB/sec. The rate will slightly increase when more OAM sprites are used to render Link such as when slashing a sword or other effects. The rendering of the other player's Link avatar is tightly integrated into the emulation of the PPU so that the other avatar visually interacts with and gets occluded by parts of the background layers, i.e. Link will appear to behind trees and other occluders as he normally does. In other words, the other player's Link sprite isn't simply "slapped onto" the PPU frame buffer. It's done with a deeper integration with the PPU and works similar to how hardware OAM sprites work. WHERE TO FIND IT: This is all accomplished using my own fork of byuu's fantastic bsnes emulator. You can find my fork at https://github.com/JamesDunne/bsnes-angelscript . My bsnes fork integrates a scripting language called AngelScript ( https://www.angelcode.com/angelscript/ ) with the emulator and exposes some very basic functions and properties for scripts to access memory and state with. Scripts also define well-known functions pre_frame and post_frame which are called before a frame is rendered and after a frame is rendered, respectively. This demo video was rendered using the code from this specific git commit https://github.com/JamesDunne/bsnes-angelscript/commit/a18b1088fc1ddb2a78a992f6f2b6e69329c1aa62 HOW TO RUN IT: Run `sudo ifconfig lo0 alias 127.0.0.2 up` to create a loopback alias for 127.0.0.2. Run `./test.sh` script in a Terminal tab to open instance 1 Run `./test.sh` script in a new Terminal tab to open instance 2 In instance 2, use the Tools menu - Load Script... dialog to load the "alttp-link-oam-2.as" script file. The IP addresses are hard-coded in the two scripts at the top and that is all they differ by. In the future a GUI will be added to specify the IP addresses to listen on and send to.