Jaguar Core: Virtual Jaguar

[sevdestruct]

Support for Jaguar Core.

https://github.com/libretro/virtualjaguar-libretro https://github.com/mirror/virtualjaguar https://github.com/OpenEmu/VirtualJaguar-Core

Pros: Easy code base to add

Cons: Controller has numeral pad which is difficult to support at this time, though not all games used it.

[JoeMatt]

I was able to pretty quickly get a branch running using two different code bases, the official port (which is quite old anyway), and libretro's version. Their version is basically the same as official, but they change the C++ code to C, which was just basic stuff like changing file extensions and a few minor thing, since the official port uses mostly functional C code everywhere anyway, and they deleted a lot of unused code and fixed some formatting etc. Nothing major for bug fixes as far as I can tell.

The dev of VirtualJaguar seems to have beef with libretro according to some forums where they go at it with each other, so I might decide to use retro's version since they are maintaining it. Despite the VirtualJaguar's beef with libretro, claiming they haven't submitted anything useful, it seems they have, since their version runs without graphics glitches, but the official version I needed to make some buffer copy changes to get the RGB format correct, and it's still buggy in some cases.

The major issue though, it's slow as shit, like really slow. Even when it runs 60 fps at time, the audio glitches like mad, and the rates dip below 60 quite a bit, and the controls sometimes work in some games, and sometimes don't work at all, or on the wrong player. Aparanlty jaguar is a mess of a system and there's not much effort in the emu scene at improving what's out there. (Though there is a Russian made closed source emu that does run quite well but that doesn't really help us).

I can push the branch and make it part of official after I fix up the graphics glitches but it's going to run like shit anyway I think. I'm thinking if I keep it to work with libretro and just wrap their call backs, then I can submodule their repo and whenever they update, we update, and if one day they fix or improve the code then we'll get them too painlessly.

I was thinking of just making a generic version of PVEmulatorCore that wraps any emualator that uses libretro.c, like stella, genesis etc, since they have all the methods we need for all the things a core needs, a generic subclass would handle everything and would simplify those cores to a single code base, and then we could just use the libretro repos as submodules directly. It's an idea that needs some testing.

[pabloarista]

I was playing around with the code in the develop branch. I had to move the video buffer initialization code from loadFileAtPath to init. I thought my iphone 6+ was the problem since it's so old, but my ipad pro 1st gen also lags. So I tried many things, but finally when I set PARALLEL_GFX_AUDIO_CALLS to 0, then the game still has some audio issues, but it runs somewhat smoother now. It's not perfect, but enough to play around with. I'm of course just playing aliens vs predator lol, so I'm not sure how other games run. I can't remember (or find) what other games I used to have. I might tinker with it some more next weekend to see if I get any other progress. Just wanted to write here in case someone wants to play with it.

[JoeMatt]

Depends on the rom and depends on if you're using the internal bios emulation or downloaded bios ROM - also there's a BIOS memory jump issue on certain roms. And then different flags work better for different roms, such as hacks or the GFX blitter, parallel rendering etc.

Jaguar is very much a test bed, work in progress. It will possibly be rewritten one day in pure swift with SIMD intrinsics when I want to learn those in 2020 or 2021.

[pabloarista]

Okay that makes sense. A few days ago I tried it on my iPad Pro and that game runs smooth. Very cool. I was reading in Wikipedia about the Jaguar about the problems that developers had back then. What a mess, but still interesting to fiddle with

[JoeMatt]

Yeah they had some weird beef. The blitter is the slowest part. I made a fork and used some of my knowledge in C to make ARM specific optimizations that helped. It's not really code you'd want to push up to the main project yet though. It's full of commented out code, hacks, and things that will probably break on other platforms that need to be wrapped in #ifdefs for the specific arm64 CPU targets.

I think a bit of a rewrite with ARM64 SIMD intrinsics in the C code would help a lot.

https://github.com/p12tic/libsimdpp

[JoeMatt]

The PARALLEL_GFX_AUDIO_CALLS was a hack to get around the blitter being slow.

The Jaguar had 2 cpu's, or clocks or something I can't remember. But basically the over I saw was the code does the GFX, then the audio, but we have threads now, so the idea is to render them seperately since they sued different code compeltely anyway and don't effect each other, and that way you don't stall the audio and get stutters and shit if the graphics engine is too slow and you need to drop a frame or two.

I used dispatch queues around the original C code though, so there might be race and threading isses for code that wasn't meant to be parallel but proably can be with a little testing and tweaking.

[pabloarista]

I see what I did wrong, my setup code was wrong. so actually your code works really good. Of course still isn't 100% perfect, but on my iPhone 6+ it improves dramatically and on my iPad Pro it's very smooth. Some games don't work though. I tried Wolf3d and Doom. Doom just gets stuck on the splash screen and Doom is just a black screen. There are some games that aren't so CPU/GPU intensive that run even smoother. Where is the fork you spoke of? I was searching on your page, but couldn't find it.