noclip.website

This even has a way to make flyover animations: https://github.com/magcius/noclip.website/wiki/Studio

Doesn't seem to work in Mobile Safari - anyone know the intended status of mobile support? I found one relevant ticket but it was closed in 2020: https://github.com/magcius/noclip.website/issues/10

It's open source: https://github.com/magcius/noclip.website I wouldn't say it emulates so much as implements a renderer for each game. It's totally nuts.

It is open source, but it looks like most of it was done by the main developer: https://github.com/magcius/noclip.website/graphs/contributor...

They do not share a file format. If you look at the GitHub repo for this site (https://github.com/magcius/noclip.website) you will find parsers, etc. for every single game.

The author basically reimplemented the Source renderer from scratch: https://github.com/magcius/noclip.website/tree/master/src/So... Same goes for every other game.

How in the... the Super Mario Galaxy level had enemies that respond to the camera location! Edit: Apparently every dynamic enemy on the map has a hand coded state machine https://github.com/magcius/noclip.website/blob/19f83f77c3e77...

> In my measurements, the only case where UBOs actually improved performance across all platforms was in a multi-draw scenario, with UBOs being split by frequency of update, containing data for 100+ draws and being uploaded at most once per frame. That's interesting -- back when I was working on mobile platforms, I found that UBOs were a win from call overhead alone -- replacing N different glUniform* calls with one UBO upload per object was a win on both the Adreno and Mali drivers, though we did have to work around some driver bugs (as is Android tradition). I haven't done the measurements as well, but I suspect it's also a win on WebGL 2 over the old strategy, because calling the WebGL functions is just more expensive than it should be (I've been told this is getting fixed in the browsers eventually, but I was also told that nearly 3 y

I still write XMLHttpRequest and see no reason to switch. I depend on things like progress notifications and cancelations which fetch has iffy support for. https://github.com/magcius/noclip.website/blob/master/src/Da...

I have absolutely written a diffing algorithm like this faster much than it would take to find an appropriate version on npm. Every so often I try to reach for an npm library, only to find out that it's suboptimal, doesn't handle my edge cases, or just plain worse than the code I would have written. The last time I tried to do this, I wanted a hash map with custom equality functions on the keys, since JS doesn't have one built-in by default. I searched for about 2 hours and didn't find a single one that actually worked (several claimed to be, but actually didn't work...) So I wrote my own in about 100 lines. [0] Data structures and algorithms tend to be really awful on npm. [0] https://github.com/magcius/noclip.website/blob/master/src/Ha...

I took a very different approach for porting my WebGPU shaders over: I have far too many shaders to port (sometimes pretty massive ones! [0]), so I used Naga [1] at to runtime-translate my GLSL shaders to WGSL. I had to get involved a bit upstream to fix quite a few different bugs in the implementation, but once I got it working I was really happy with the result. It's quite fast, it compiles to a pretty light-weight WebAssembly module, and it works surprisingly well. [0] https://github.com/magcius/noclip.website/blob/e15f8045cf262... [1] https://github.com/gfx-rs/naga/

This is really cool! I wonder how the author was able to load everything in a uniform interface and populate the levels with enemies. From my experience, dumped levels from retro video games can be in varying nonstandard formats that are largely incompatible with one another. These results are beautiful. edit: The README and repo [1] seem to show that this was a large effort. [1] https://github.com/magcius/noclip.website

I don't know why you keep saying "it's not possible" when I literally wrote code that does it: https://github.com/magcius/noclip.website/blob/cc98112d7b105...

I've experienced a 2x speedup when porting tight loops from JS to WASM. In my case, my tasks are decompression and texture decoding. I initially ported to C, and then ported to AssemblyScript, being careful to manually manage the memory along the way. The old code was also very "tight-loop" code that's just math, and no GC allocation, so it's not applicable to many people here yet, and it's possible that JS interpreters have improved since when I ported (GC behavior has gotten quite noticeably better in V8 in the last two years), but I'll take the speedups I can get. For comparison: Old TypeScript: https://github.com/magcius/noclip.website/blob/master/src/Co... New AssemblyScript: https://github.com/magcius/noclip.website/blob/master/src/as... Wrapper for WebAssembly execution: https://github.com/magcius/noclip.website/blob/master/src/Co.