Enhanced Drive API (RFC) about libretro-common HOT 5 OPEN

I figure finishing up the spec is enough and describing the implementation is enough.
I don't see why a new env callback needs to be hooked completely to RA to be approved, wrestling RA is difficult, it took like 3 years for subsystem to have a full implementation on the RA side (and parts of it might be incorrect).

I have no API writing experience, I just know my way around RA and libretro, so I'd say.... let's have a go at it (API / core side) and we'll see what happens.

from libretro-common.

libretro/RetroArch#7876

from libretro-common.

I had a similar idea.
Not sure if better is worse.

In my idea there are no pre-defined classes, it would work more like subsystems (I think that's better/more future proof).

I didn't think the "drive states" would matter, other than empty or filled, pretty much anything in between is just internal behavior and not too relevant to the frontend.

Sadly I don't think there is any traction / anyone driving the API forward so it would have to be either me or you submitting a fully functional PR is we want to get anywhere with this.

from libretro-common.

Hi, thanks for responding. I'm glad its not me to see this area of the API as a having need for improvement.

I'll take a look at your suggestion (sorry I didn't find it myself, but I have your link now) At first glance it's not too dissimilar and probably 'media' might be a better name. I hadn't really considered the memory card management side of things, but that makes a lot of sense to incorporated as part of a new 'drive' or 'media slot' system.

Your point on traction/interest might be a big problem. My concern is taking this (or yours, or any idea like it) from a concept to reality will require some help. I could handle editing cores to conform to it but the need to implement the front-end side of this in RetroArch (plus, full disclosure, my own front-end) and that adds up to too much work for me alone.

from libretro-common.

One way to make progress might be to take advantage of my own eco system around Grid Cartographer (it's map drawing software and a LibRetro front-end in-one) with its own core forks + downloads,

I could implement a new drive/media API as an experimental branch outside of RetroArch as a proof of concept. Update a test core to support it (e.g. my customers would love better Amiga support, so that might be a good candidate). It would be a core without RetroArch compatibility at first, but would provide the back-end needed to help develop and test the RetroArch front-end in future.

Should some alternative mechanism be decided upon and implemented in RetroArch in the mean time I could update my cores to get back in sync. If nothing happens at least my customers get something they can use \/ :) \/

from libretro-common.