3DFX Emulation in js-dos

[caiiiycuk]

Hi everyone, I'm working on adding perfomant 3dfx support to js-dos. It's based on DOSBox and OpenGL. DOSBox fully emulates the Voodoo graphics card within its own process — it keeps a specific state in memory and translates Glide calls into OpenGL commands. The problem is that js-dos runs inside a Web Worker, and I’d really prefer not to create an offscreen canvas with OpenGL.

I came up with the following architecture: the part of the code that performs OpenGL rendering will be separated from DOSBox and run on the main browser thread, while the emulation will still run inside a Web Worker. The Glide-related emulation code (the part remaining in the worker) will send commands via some protocol to the main thread.

Since both the OpenGL code (main thread) and the emulation code (worker) need to access a shared state, I’m planning to run the emulation (worker) using SharedArrayBuffer.

This means the same memory will be visible in both contexts. But I have a few open questions:

1. Since these are two different WebAssembly modules, can the OpenGL module (main thread) also use the memory of the emulation module without copying? Each module use malloc, so this might break things — is there a way to make this work?

2. I don’t want to compile the emulation module (worker) with -pthread, but I still need shared memory between the two modules. Will I be able to use std::atomic for implementing ring buffers without -pthread?

Once again, I’m trying to run two Wasm modules, but they need to share a small synchronized chunk of memory (the current state of the emulated video card).

If 1) and 2) don’t work out, I could probably just create a SharedArrayBuffer and manually copy the state into each module’s memory — but in practice, this is quite difficult, since I’d have to do it very frequently. Ideally, I just want a shared chunk of memory between the two modules.

[sbc100]

Why don't you want to use -pthread ? That seems like by far the simplest solution.

Also, why don't you want to use the existing solutions for multi-threaded rendering such as offscreen canvas or OpenGL proxying?

Trying to have two different programs running the same shared memory (instead of multiple instances of the same program, i.e. threads, which is well tested and known to work) sounds extremely error prone and fragile. You would likely need to assign each program is own static data and heap data area as well as the shared region. Sounds like a nightmare to me.

[caiiiycuk]

@sbc100 Thank you for the advice! I ended up using transferControlToOffscreen(), and it works just fine. I pre-create the context and use it with preinitializedWebGLContext, so the context is created correctly and rendering works.

However, I encountered another problem. The Voodoo emulation is based on OpenGL 1.5/2, and to emulate it, I used the gl4es library. I was able to compile the Voodoo emulation both natively and for the web (both use gl4es). Natively, it works just fine, as shown in this video:

3dfx-native.mp4

But when I compile it for the web (using FULL_ES=2 as required by gl4es), it produces the same output—with one exception: after calling glDrawArrays, the FBO appears to be completely cleared, and I can't figure out why. There are no intermediate calls to gl.flush() or gl.finish(), just a sequence of glDrawArrays calls. Yet, for some reason, the image seems to be pushed to the canvas after each draw call—or perhaps each draw call is somehow clearing the background to black. I tried debugging it with Spectre.js, but no luck. All I could see was a sequence of valid draw calls, but the output remains strange.

3dfx-web.mp4

Also, I haven’t figured out how to notify the browser that the frame is ready to be displayed. There’s no more commit() on WebGLRenderingContext, but I don’t think that’s the cause of the issue—this behavior is the same in both the worker and non-worker versions of the emulation.

I tried to use preservDrawingBuffer, but it also behave wrongly.

spectr js dump

[caiiiycuk]

Nevermind, i fixed all issues.