Yes it can, standalone even has a modular build system to do this.
I do not know the technical challenges, I only comment it because it can be beneficial for the Retroch ecosystem.
I don’t think so, just more cores that would need to be maintained, so who will do it ? Not you apparently, and if there is no maintainer then it’s just more outdated cores using more buildbot ressources and confusing more people about which core they should pick (note : currently there are people who think fbalpha2012-neogeo is the core they must use to play neogeo on desktop computers…). FYI, current mame core is not actively maintained and already has quite a lot of issues.
I understand that it is difficult to keep many cores, there are 17 (+ Mame and fbalpha and FBNEO) of SNes.
The idea is not to depend on MAME. Separate it, independent and if possible in the future, add characteristics. Zinc and Modeler are still used (HD-1080p). Obviously it will not be a core per plate, it is hundreds, but it can do for generations or by type. CPSX, Systemx…
It can also be an option for consoles without core. A single emulator for generation 1, a fixed romset, names, screenshots, etc…
After I posed the idea better, so as not to distort the main theme…
This is not the fault of the people, in RetroArch there is a lack of documentation, the one that exists is difficult to access.
I do not know how to do it, If I knew, I would, but it would surely be a… “shit”?
I always think of things before saying them, and Mame I have thought a lot, ease, accessibility, maintenance, organization, projection, etc. Always focusing on the user experience, beyond the technical context I do not know.
Is that I am convinced that. "It’s easier to break than to repair."
I hope the analogy is understood.
This I can’t agree with. It should not be expected that the devs hold the hand of the users. I might be able to count on one hand that the Docs section has not provided me with enough information, and that is where the forums come into play. it would come down to “Work on the core, or work on the documentation to include every nook and cranny of the cores, what ones to use properly in this or that situation”. Doing such I believe would simply wear out a dev to a “done” point.
I am not saying that it is the fault of the developers, nor do they carry the users from hand. But there must be even if it is a minimum of description of what the emulator does, because if not, the effort is lost.
Without going far, there is nothing that explains to you so that the Core fbalpha2012 exists. There is no information in the Core or documents.
The N64DD is a mystery, if they do not explain it here it can not be used. The Widescreen is another hidden secret.
I am a person who looks for a lot on the Internet before asking, not to waste time. If @hunterk does not explain to me for each Core Mame, I do not find out because on the Internet at that moment, there was nothing.
And more things, but yes, the documentation is quite worked, it is getting better, what I said and I was explicit is that “lack or is difficult to access.”
I think we are getting a bit off topic but…
Just because MAME can be dissected doesn’t mean it would be easy to start adding fancy features. If it were, MAME would have accelerated 3D video. “Dissecting” really just means only a single driver is compiled. AFAIK a lot of other stuff, not really needed for the driver, is also compiled so there isn’t even a lot of space saved. Standalone full compile is 432,446,689 bytes and compile with only DEC PDP1 driver is 430,394,386 bytes. (An old version but you get my point. )
The MAME core is just barely a core at all. Only the minimum things to make it work have been done and we are very lucky it is updated at all.
All things considered it works very well.
This is the description which i believe is shown in the online updater for fbalpha2012-neogeo : https://github.com/libretro/libretro-core-info/blob/master/fbalpha2012_neogeo_libretro.info#L20. It sounds pretty clear to me.
If you think the documentation from https://docs.libretro.com/ is lacking, contributions are welcome, yet again i don’t think the documentation is the problem for picking the right core (because very few users read it anyway), only the overwhelming amount of cores (cores like fbalpha2012-neogeo shouldn’t be available on systems without heavy memory limitation, period), and your idea can only make things worse. Also, your reasons for wanting cpsX or systemX split cores are very lacking, because i doubt widescreen is achievable for those systems (aside from the games where it’s already supported), let alone HD…
Actually, I did not want to create a debate, it was just an innocent doubt.
MAME Like Mednafen, they have no intention in adding features. When Zinc was fucked with MAME, they all asked if the accelection by hardware would be maintained, and the answer is obvious.
I suspected that Mame was not going to make it easy to create mini emulators, that’s why I said, dissect, take only what is needed. But I can assume that it is complicated or impossible, then better forgetting.
I love Mame, it’s one of my favorite emulators (I am from the arcade generation) but it’s very disorganized, it seems that his philosophy is torture who wants to collect it.
It is appropriate to get to this.
When you create an interface, you have to in mind whenever the person who is going to use it does not know it. The interface has to be easy to use. And I do not mean it is simple, basic or minimist, it can be extensive and complex but it has to be “organic”, so that the user understands it by logic.
And the problem is this:
-
A user who has never used RetroArch will install an “emulator”, does not get it, you have to go out to the browser to search for information. After a brief investigation he learns that they are cores.
-
Look for cores and do not appear on the list, you have to go back to the Internet to find out that he has to update “Update core files”. Solvented, install the core “falpha2012neogeo” that in the description only shows you the license.
-
Want to get more information from the Core and goes to “Core Information” and there is no Core information. It goes back to the browser and goes to documents, and in documents there is nothing of “faspha2012neogeo”.
After a comprehensive search by chance finds out that pressing “Select” in the Gamepad you can see the information of the CORE. Try pressing the “i” key on the keyboard, which is the closest logic, and does nothing.
In RetroArch there is nothing that tells you that with the gamepad Select button, you can see the core information. The detail in the interface does not even appear. By the way, I searched at Hotkeys does not appear.
This is the problem, and I can give you a “possible” solution.
-
It is placed, Core Downloader (Emulators) And in the description, specify that the cores are emulators, etc. (?) Since we are, say “download and install,” it’s obvious “from the online Update” is over, because you’re there.
-
Eliminate “Update core files”, is a totally unnecessary step. That the information of the cores automatically updates each time “Core Downloader” is accessed. With this eliminated 150 thousand 700 million questions, why do not I see the cores?
-
When you are going to install the kernel, the panel on the right appears, with detailed information.
This option is only for XMB and Ozone, But you can also; A- That the popup is opened with the information before installing and the option and the install option, update, return or. B- About another panel with detailed information and the option Install, update, return.
- When you access “Core Information” have that information, if it is complicated by the design of the subject, place an option that says, “Detailed description (?)” And open the POPUP.
- May it appear in documents.
Keep in mind that a software is not made only with code, this is part of the user experience and may be defined for success (or failure)…
Just, I was happy because the forum ascended me…
The G16 or, G15 + alexb3d
But I am very interested in your opinion. Do you think it does not “contribute” enough?
By “dissecting”, especially since you mentioned various 2D arcade systems, i assume you meant splitting MAME in several smaller cores (which is 100% an awful idea for all the reasons i mentioned above), but obviously you can use MAME code in another project as long as the licenses of both projects are compatible. Meaning beetle-psx/duckstation/pcsx could load psx-arcade games, as long as someone is interested in porting what’s needed (afaik, mostly roms loading/decrypting & sound boards), the same way flycast can load naomi games or kronos can load stv games.
If you already do it, it seems an unnecessary job.
I have generated confusion because I have not been able to explain. The main idea is not to work over. Keep in mind that I do not know the technical part, my point of view is logistics.
This is the current situation, which made me think about this idea:
Mame is complicated to update and maintain, from the developer’s point of view as the player. The emulation of many PCBs that have reached excellence.
This is a simple example of what I had thought:
Separate neogeo (or any other), do it totally independent and freeze it, so as not to update it. Yes, it’s something extremely complicated, but it’s going to be done only once and it’s going to have absolute compatibility with Retroarch. Equal with the romset, create a set, count it and update in retroarch all the information you can offer, playlist, thumbnails, etc. Actually, what I propose is to do the same as FBNeo does. With the other PCBs.
These are innocent assumptions:
When I said several PCBs together, I thought it would be comfortable to have all Capcom together a core for each PCB.
Or, if it is possible to add Widescreen and HD in 3D. Have 2D PCBs and 3D PCBs separated by generation.
Other way of seeing this. Atari has games vectors, sprites and 3d. You can have a single core for everything atari, or separated by types.
Or, have a core of all games in vectors, videodiscs, old with overlay. Even, a core can be separated for 1st, 2nd consoles and rare consoles of the 3rd generation.
Previously I put the example of extract FBNeo CPS2 because it works better: but, If FBNeo works well, no need to touch it.
In this case, it may be convenient to modify the PlayList with a generic name, such as “Arcade VideoGames” and not the name of the emulator. All scanned rom lists will go in that direction, independent of the core.
Advantage?
Fixed and independent cores, without constant updates of MAME. A fixed romset that does not have to be updated. All RetroArch support. The cores are used by most frontend, when they discover, it will be their choice.
This is just a sketch of an idea, I do not have technical knowledge of how complicated it may be. If it is done, I can collaborate on the lists, the part of the graphics, in making the romset perfect, etc.
That’s why the question, if this is very complicated it is better to forget it.
Yet again, you assume not having to update romsets would be a good thing, while it’s actually a very bad thing : the most common reason a romset gets an update is because the old one was corrupt/incomplete, preventing the game from working properly, and the only other reason would be that a newer version of the pcb was found, which is also a good thing.
This is just more unmaintainable and/or broken cores leading users to bad choices. There might be 1 or 2 exceptions where writing a new emulator using MAME code/documentation would be beneficial, namely a model2 emulator, but that’s about all of it.
and, as much as people hate tracking the latest romsets from MAME, they’re at least always available. That is, it’s getting difficult to even find the FBA2012-compatible ROMs, and we chose the MAME snapshots we did (2000, 2003, 2010) because they have pre-existing romsets floating around for other established forks.
Now I understand it much better, thank you.
The great absent in Linux, Model 1 and, 2. Although the 1 is emulated recently by MAME, it does not compare with modeler.
And currently I do not believe that is so easy, “the last bastion” has fallen.
Taking advantage of the dynamic post. I’m going to do some consultations.
-
If you want to add or edit a document, such as Agnes Heyer Twitter changed to @Runarheyer Is a “Pull requests” be opened?
-
Where do I have to go to add or edit a description in the retroarch menu? Like the description for “Aspect Ratio Hint”
-
And for translations to other languages?
-
And the SNAP, where an error is reported?
-
I almost forget it. What Romset uses FBNEO?
Everything else I know them, it is to see if I can share this information in an article.
Afaik, windows’s “model2 emulator” run fine on linux using wine.
I know nothing about that model1 emulator, but the model1 wiki strongly disagrees with you.
To be fair, the main reason those systems aren’t very well emulated nowaday is because there are still things unknown about them. Forking MAME wouldn’t be a magical solution for this, what’s needed are emudevs interested in those systems.
Its own, which is mostly in sync with latest MAME.
docs can be updated with PRs to https://github.com/libretro/docs
The change you have pictured is a core option, so it would need to happen at the core’s repo, in the core options file. There’s a translation file there, as well.
If you mean you’re having a problem with the snap package, you can report it at https://github.com/libretro/retroarch-snap
Isn’t MAME better than modeler these days?
Also stuff like viva nonno as well?
Apparently it does not serve the emulator. It could swear, what a virtual Fighter / Racing. When I installed Windows I’ll try it.
Will I be so confused? (It will be my age )
I imagined them, there are hundreds of sets on the Internet. But, can I use the current MAME without problems?
Yes, model 1 works excellent at MAME.
First time I hear from Viva Nonno, it was not assiduous to the Ridge Race, but also work in MAME.