3 ms·
I thought that too, but remember this has to all be done at runtime, so depending on LLVM would require an Emscripten-ized version of LLVM (does such a thing ex
by ris 13y ago
I thought that too, but remember this has to all be done at runtime, so depending on LLVM would require an Emscripten-ized version of LLVM (does such a thing exist?) to be distributed with the generated js and similarly depending on Emscripten would require a copy of Emscripten to be distributed with the generated js. And from what I hear the runtime performance of Emscripten itself ain't that great.
- derefr 13y agoWhy does this have to be done at runtime, exactly? How many mods (or rather, QVM files) were there? And are people still making them? If the answer is "less than 100K" and "no, of course not," then you can probably get away with: 1. compiling all the QVM files to their Javascript equivalents ahead-of-time; 2. stuffing them all on a CDN (with each JS blob named after the md5 of the relevant QVM source); and then 3. having a "compiler" in your client that just hashes the source it's about to "compile", and requests the blob with that hash from your CDN. Of course, if the amount of generated JS is small enough, you could even just serve it all with the client. I'm doubting that one, though; it's probably at least 50MB of code. (Though it might be heavily redundant code... it could compress very well!)
- ris 13y ago> Why does this have to be done at runtime, exactly? Because that's how quake3 works. What you're describing would be incompatible with all other quake3 clients. And part of the point of implementing the QVM in the first place is compatibility.