zakblystone / metacade Goto Github PK

It's really inefficient to render each pixel as an individual rectangle for emulators and such, so I suggest a way to dynamically change the RGBA values of pixels of a texture asset, through either changing a “texture” buffer property of an assets[“texture.tex”] object, or through a method to set the color of a specific pixel.

For most things substantial you can barely use the Lua scripting option due to the fact that it's lacking a fundamental feature: require() . This means Lua scripts are forced to be one ultra long file which ultimately will become unmaintainable for the creator.

A function for an open file dialog that returns file data in an ArrayBuffer would be useful in making Steam workshop based emulators legal. It could allow the end user to upload their own roms to the arcade machine, rather than requiring a hardcoded file within the emulator itself. This could also be sandboxed by preventing from writing files, and limiting the number of dialogs that can be created

The addition of WebGL bindings to allow for the creation of an offscreen WebGL canvas or context. This would allow javascript code to utilize the GPU to render to the canvas in the background, and then either redraw the image in the Arcade window through script, or perhaps use a provided render method to draw the triangles straight in Unreal.

Functions for networking between multiple arcade machines, perhaps using tables?
Maybe support for "rooms" where users can join from a menu and have data networked between the host and clients?
Also perhaps a way to emulate multiple arcade machines on a single computer to make development easier?

A function that will, given a texture and xy coordinates, return the rgba values of that specific pixel within the image

OpenAL support or a functionality to generate sound during runtime would be a useful addition; many libraries use OpenAL and an implementation could improve many JavaScript games.

The metacade tool does not lock the mouse cursor to the center of the window, nor does it hide it. It currently only reads the coordinates of the mouse cursor relative to the window evt.motion.x and evt.motion.y and calculates the movement delta based on previous input states.

It would be beneficial to add mouse-lock on the host application, aswell as modify the exisiting implementation so that instead of calculating the delta based on the previous input state, it would use the SDL provided evt.motion.xrel and evt.motion.yrel which would continue to provide movement values even if the mouse position doesn't change. (For more info, see: SDL_MouseMotionEvent)

(Request added as asked on the pixeltail forums)