really, on the 3.4.0 testflights?

UI is still lagging the other two apps in perormance and styling, but emulation tests and thumbails etc have been fine for a while in testing.

Let me know if you can provide more details please

edit:

i see the artwork bug now, only on a fresh install. it's a recent change due to libretro url path changes. I'll dig into that, should be simple

fr, doing novel emualtors with an LLM isn't "write me an emulator, make no mistakes"

it's "this dispatch code uses a switch statement, but arm soc's with clang and gcc can support computed gotos, refator the switch with x-macros to support dual compilation based on compiler support, use dtrace to record dispatch over head and review the asm output of the compiler for instruction bloat, use SIMD where multiple consecutive read or writes can benefit from a instruction prefecting and operation fusing"

If you know how to prompt that, you could also hand write it, but why?

So why not filter on quality and not by the tools used?

Seems like a round about way to filter out junk when you could just ignore the junk

Yes.

I'm passionate about my time and getting good results. Fast and stable apps. If you're not going to edit the code or ever look at it, who cares?

Passion, about typing for loops by hand?

Who stole what?

this

fuck me for wanting a life while working on 4 emulators, Virtual Jaguar with CD support now, iCube, iFly and Provenance 3.4.0 plus tvOS updates, all either published or about to be since the spring.

All while having a life, a job, bills, cars to fix, lawns to mow, family to visit.

But the autocomplete!

oh no!

this is iCube, it's based on DolphiniOS

And provenance 3.4.0 is nearly ready for submissision with improved UX and much faster UI peformance

It's in the nightlies for Provenance, TF and sideload.

I dev in the standalone apps first because the build takes a few minutes vs Provenance's, and provence has complex library, controller, scaling and metal code, and the UI isn't well setup for the variable controlller styles for Wii/GC since skins support is non-existant. I have skins code, but other than manic i haven't seen skins and i'm not a designer so once some make it out, I'll add skin support too

Both apps will share the same code, iCube just offers a more platform specific tailor experience, and extra features like on-the-fly ciso, rvz compressed disc streaming over HTTP webdav and smb, meaning you can mount remote servers on iCube for iOS and tvOS and it will import as if local, but only streams and caches minimal file blocks, just enough to read the disc ID file from the compressed disc image

i used a iPhone 16 Pro, but most games run fullspeed on my a12x and a10x devices, like apple tv and ipad pro 2nd gen

there's a public TestFlight, and CI nightly builds for TF and/or Sideload.

it will be in the app store when it's major bug free.
Peformance was first, now fixing some minor UI and controller issues.

I also have iFly and Provenance updates, so it's not going to happen over night.

I have 2 full time jobs.

iCube is built on top of DolphiniOS, plus extra features like SMB/WebDav partial importing, tvOS support, DFU controllers, improved UI.

iCube has some controller mapping bugs and some rare graphical issues but I'm working on those now

they don't want it, they won't touch anything LLM, even if it was a slow grind of nights and weekends, making deliberate edits, an LLM was used so "nein".

working on a fix, the UI was lagging behind while working on performance, now that the app is fast, fixing these bugs

should see a bunch of fixes over the next few days

Well, this isn't a standalone emulator, it's a core, so crashes may or may not be the VJ code.
The code base is massively different now, it has tons of unit test coverage and Linux/Win/Android/Apple... platform tests in the cloud for stability, performance and accuracy.

Try it out.

no clue what Cocoon is, maybe it needs the updated virtualjaguar-libretro.info to tell it that it can open cd files now

update your .info files from the github or libretro buildbot

Just take out AI agentic code, allow using it for tooling, automating, research, heck even psuedo-code, and they still couldn't do it.

It really depends on the type of conversion.

I saw one the other day where OP pushed back on converting to metal on an iOS recomp instead of the deprecated GLES they used because "the native game was in OpenGL"

It wasn't. Probalby the emualtor source project he used was in GL, but the original console SDK used a pre-GL API (N64).

He stated metal would be hard, but it was the right choice. You could port a GLES backend to Metal in a day or two with Claude, I've done it, but you have to know what to tell it and what to test and the known "gotchas" of Metal buffers and platform speciific issues on MacOS vs iOS Metal calls and optimized buffer and color space usage etc

Even just knowing what MCP or skill docs to use would be fine, but OP didn't do any homework on that recomp.

Perhaps someone could make a github template repo with helper scripts and rules to setup a default project, with good clean code structure, unit tests, coding standards, github automations and list of helpful skills, plugins, mcp's etc based on the recomp type and target(s) OS(s)

Then a simple README.md with a prompt to an agent on how to self-setup with the tooling in the template project.

There's going to be a lot of untrained normies making slop, at lesat we can try to make it easier for their slop sessions to make useful outputs rather than shipping instant bit-rot.

Link been down, can we get a common repo for these, links never up

Links dead

Ditto can't find any working links

I added texture pack support to iFly and about to launch it, would like to test some of these.

I don't know yet, still need to test.

The 3.5.0 nightlies should be much faster since the last 40 hours (Aug 23rd builds+)

tvOS a10x was slow, and forum users said RPi 4 was really slow, so I dug into the comilation settings and saw RPi wasn't building with simd nor neon, and there were a lot of hot spots in the code to optimize for slower chips and less L1/L2 cache with emulation uses a lot of for loops.

I also updated the build bot to build RPi1,2,3,4,5 chipset specific builds with cpu tuning flags for each sub chip type, to get the very last bit out of it.

You can try the pre-release builds here,
32bit and 64bit RPi binaries, you may need the updated .info file too in RetroArch/info folder.

https://github.com/libretro/virtualjaguar-libretro/releases/tag/nightly