Angrylion RDP N64 and general libretro builds about webretro HOT 15 OPEN

So I did not get anywhere with Glupen, but did find a change that actually modified the output and got a bit further.
I was interested if it made a difference in your mupen64 core and surprisingly it did.
If you change ctx=canvas.getContext("webgl" to ctx=canvas.getContext("webgl2" in the mupen64plus_next_libretro.js file a bunch of the texture errors dissapear. IE:

Without:

With webgl2:

Not really an encompassing fix for anything, but maybe could lead to something.

Edit: It seems like the path should be trying to make cores built around GLES3 with webGL 2.0 as it supports many more GL calls.

from webretro.

Sorry it took me so long to get to this issue.

My question is if it is possible to basically go back in time just forget about Glide and use CPU cycles to get something working for N64?

Possibly, but I really wouldn't want to (try to) do this.

Workers are a new concept to me, they seem like they would be useful, I can look into them.

As @ethanaobrien suggested in #6, I am going to try using the GLupeN64 core. It is a little out of date, but I should be able to update it as needed.

‌

As for touch support, thanks for the information, I will play around with it and see how it works. However, I'm a little afraid that the RetroArch touch controls are too lacking, and the screen may be shrunk by the aspect ratio, but that can be fixed (see #7). I was considering making custom controllers in the DOM that would trigger keyboard events to simulate inputs.

‌

I will start work on these as soon as 6.4 is released, which is soon, I promise. I want to start focusing more on getting more cores supported now.

from webretro.

Here is reference code for the cores I built.
https://github.com/linuxserver/libretro-cores
Released as tarball here:
https://github.com/linuxserver/libretrojs
Outside of the data directory change for the wasm file location they should be plug and play.
Source snapshot:
https://github.com/thelamer/retrostash

They have the missing assets stanzas removed. I built using emsdk 1.39.5.
Been working lately to get safari 15 support for iPhones/iPads without luck, the code runs, but nothing renders to canvas.

This all plugs into this: https://github.com/linuxserver/docker-emulatorjs
If you want to try it.

from webretro.

This is as far as I could get with Glupen:
https://ipfs.infura.io/ipfs/QmfWEGQFoBxi4YQ49KCimTAK9jpgdUf1HvxgoqxjXVXMtf?filename=glupen64.zip
It builds and loads, but complains about the functions defined in glsm.c and crashes:

Source: (built with emsdk 1.39.7 for fiber support)
https://github.com/thelamer/GLupeN64

from webretro.

I tried it out, it fixes a few errors, but not all.

I think that switching to GLES3 is a wise idea, that's what m4xw was testing. Once this next update is finished, I'll see what I can do.

from webretro.

@BinBashBanana I agree
Another example:

webgl

webgl 2

This is when only changing that one line of code

from webretro.

So I guess goal achieved, I went back in time and got an angrylion emscripten build. Forked here:
https://github.com/thelamer/parallel-n64/tree/angrylion

Honestly it is not far off on modern systems especially an Xbox Series console despite only having one core to work with and using old code. I have not had any luck forcing Angrylion into a 320x240 low res mode though and I feel like that may be the only path to this being playable.

PreBuilts here:
https://ipfs.infura.io/ipfs/QmczcVnKehE4xfsZJ2KcGH1Q9Jz7Nq4rGa8u5p9e35ecvS?filename=parallel_n64.zip

from webretro.

I got threading to work with the latest emsdk (3.1.0), this allows building against head of https://github.com/libretro/parallel-n64:

It is pretty basic changes to the make section of the core: (also change -Ofast to -O3 and disable -fcommon)

# emscripten
else ifeq ($(platform), emscripten)
   TARGET := $(TARGET_NAME)_libretro_$(platform).bc
   GLES = 0
   HAVE_OPENGL = 0
   WITH_DYNAREC :=
   HAVE_PARALLEL = 0
   CPUFLAGS += -DNOSSE -DEMSCRIPTEN -DNO_ASM -DNO_LIBCO -s USE_ZLIB=1 -s PRECISE_F32=1
   WITH_DYNAREC =
   CC = emcc
   CXX = em++
   HAVE_NEON = 0
   PLATFORM_EXT := unix
   STATIC_LINKING = 1
   SOURCES_C += $(CORE_DIR)/src/r4300/empty_dynarec.c
   HAVE_THR_AL = 1
   CFLAGS += -pthread
   LDFLAGS += -pthread
   CXXFLAGS += -pthread

Then for Retroarch itself: (Makefile.emscripten)

MEMORY ?= 536870912
CFLAGS += -pthread
CXXFLAGS += -pthread
LIBS    := -s USE_ZLIB=1
LDFLAGS := -L. --no-heap-copy -s $(LIBS) -s TOTAL_MEMORY=$(MEMORY) -s NO_EXIT_RUNTIME=0 -s FULL_ES2=1 -s "EXTRA_EXPORTED_RUNTIME_METHODS=['callMain']" \
           -s EXPORTED_FUNCTIONS="['_main', '_malloc', '_cmd_savefiles', '_cmd_save_state', '_cmd_load_state', '_cmd_take_screenshot']" \
           --js-library emscripten/library_rwebaudio.js \
           --js-library emscripten/library_rwebcam.js \
           --js-library emscripten/library_errno_codes.js \
           -pthread -s PTHREAD_POOL_SIZE=4 

This will also produce a parallel_n64_libretro.worker.js that needs to be copied over to your project.

For this to work in chrome you also need to serve the content from a webserver with Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy set. IE to achieve this with an express server:

app.use(function(req, res, next) {
  res.header("Cross-Origin-Embedder-Policy", "require-corp");
  res.header("Cross-Origin-Opener-Policy", "same-origin");
  next();
});

Or from an Nginx webserver:

        add_header 'Cross-Origin-Embedder-Policy' 'require-corp';
        add_header 'Cross-Origin-Opener-Policy' 'same-origin';	

I have kind of a shitty PC (i7-4790) I would expect better on more modern chips.

One thing really stands out playing with thread count, I do not think the current bottleneck is in going past 4-8 threads for angrylion. I can get more CPU usage by going to 16 32 etc, but it actually hurts performance and it looks like the limit is on the main thread (possibly). I suspect cxd4 rsp, but do not have the knowledge to really dig in past this. In general it is not there yet and not "playable", I wonder if any other tweaks could be applied to get it on par with the desktop version.

Pre-Built bins:
https://ipfs.infura.io/ipfs/QmcHKT7PM2tFTyqkaZUsUJ8ATHgojLRL1zav5ibvAmB2wk?filename=multi-angry.zip

from webretro.

Bumped down to 320x240 for the resolution, this is really close to being playable.

from webretro.

Awesome! Sorry I haven't been keeping up with this issue. I'll try implementing ToadKing's emscripten libco fix, just to see if that works better than PTHREAD. (it probably doesn't)

from webretro.

Threads opens up a bunch of options here, check out ds emulation:

https://ipfs.infura.io/ipfs/QmPCcMAR3bSyWzGBgZCJKHo78eXpMh9PFqwteC1vrUBB36?filename=melon.zip

I would bet this makes stuff like Saturn playable as well, though I can't figure out the proper symbol declaration in yabause/src/thr-rthreads.c for slock and sthread stuff when building with HAVE_PTHREADS

from webretro.

As suspected Saturn runs really good with threading: (full speed on an Xbox)

from webretro.

Hi @thelamer, sorry for the long period of inactivity, I have been working hard on v6.5 and it is finally released! It addresses several things in this issue:

1. All of the WebGL draw errors were caused by emscripten issue 4214. Implementing one of the patches fixes the problem completely.
2. Mupen64Plus-Next has been updated to the latest version from GitHub, and is now using GLideN64 GLES3 (WebGL 2). A different bug is still here: see #4.
3. ParaLLEl N64 has been added with GLide64 and glN64 (both GLES2 renderers on WebGL 2, as using WebGL 2 seems to fix a minor color depth problem.) Libco/fiber has been added back as well.
4. melonDS and Yabause have both been added without threads since github.io cannot host with special headers.
5. Beetle PSX HW has been added, I worked on GLES 3.0 support for the HW renderer (see pull #856).

Additionally, these 5 cores have been built with autovectorization which can improve performance slightly (these flags added to the compile flags: -msimd128 -ftree-vectorize)

Threaded Angrylion is not out of the question, I'd like to get this working on the Mupen64Plus-Next core as well. Another thing - what was your solution to getting Yabause to build with threads? I couldn't figure it out.

At some point in the future I also want to port melonDS's OpenGL renderer to GLES 3.0, as well as getting YabaSanshiro (outdated saturn core with GLES 3.0 rendering) or Kronos (more updated saturn core that either requires GLES 3.0 or 3.1, I'm not sure) to run on a single thread.

Threaded OpenGL rendering may also be possible at least for Mupen64Plus-Next, m4xw said that he had had threaded GLideN64 working at some point but not anymore. He also said that he found an old mailing list saying that offscreen framebuffers only worked on emscripten's SDL backend (not on EGL) but it could be outdated.

Speaking of this, it seems I'm restricted to emscripten 2.0.15 as any higher than that prevents any core from loading. I haven't actually tested this recently because it is a pain to test, and I may have already fixed it.

I have also transitioned to a much better system for core patches, see Building from source. I tried my best to be a thorough as possible when making this, so let me know if you run into any problems.

Here's some screenshots of Mupen64Plus-Next:

from webretro.

Holy cow @BinBashBanana this is amazing you are a genius. Correct me if I'm wrong here, but this should add capabilities to anything that doesn't leverage simd right? Shouldn't stuff like duckstation and PS2 be plausible now?

from webretro.

Probably. I don't expect particularly good performance at all, but I can try also using SIMD in cores that use SIMD instructions (emscripten support). I tried compiling GLideN64's NEON stuff in Mupen64Plus-Next, but there were some unimplemented symbols so I gave up. Citra, Dolphin, PCSX2, PPSSPP, and Flycast are the cores that I haven't built yet for this reason. (A few of them also use CMake which could also be annoying.)

from webretro.