What if OpenBOR was included as a libretro/RetroArch core?

[CommunityPoster55]

Now just hear me out...

It's only an idea/suggestion, but it could also increase the cross-platform capabilities of the Engine itself, not to mention hardware testing/optimisation.

Along with a comprehensive easy-to-understand tutorial in the Libretro Docs on how to add mods, and assets:

Home - Libretro Docs

This is the official RetroArch documentation for users and developers. Information from sources outside of this website may be dated or incorrect.

docs.libretro.com

Maybe it can also benefit developers who want to test out their assets more quickly with a more "direct" approach...
Maybe it even gets to a point where all you have to do is open a ZIP file to play the game...

But I'm just running wild at this point. Maybe there's a reason why this can't happen.
If so, I'm curious to hear it.

 

[ABK]

What do you want to hear, im up for it even tho we have so many builds that confuse people, i think devs are worried that bugs report will be flooded and fall back on their head so thats a bit scary, its nice for players to have multiplatforms but from dev standpoints its a big mess to support sometimes.
It would be nice if openbor was available on more platforms than doom.

 

[DCurrent]

Now just hear me out...

It's only an idea/suggestion, but it could also increase the cross-platform capabilities of the Engine itself, not to mention hardware testing/optimisation.

Along with a comprehensive easy-to-understand tutorial in the Libretro Docs on how to add mods, and assets:

Home - Libretro Docs

This is the official RetroArch documentation for users and developers. Information from sources outside of this website may be dated or incorrect.

docs.libretro.com

Maybe it can also benefit developers who want to test out their assets more quickly with a more "direct" approach...
Maybe it even gets to a point where all you have to do is open a ZIP file to play the game...

But I'm just running wild at this point. Maybe there's a reason why this can't happen.
If so, I'm curious to hear it.

@bWWd spelled it out perfectly.

Unless there's a huge uptick in manpower, you can file this under "not going to happen". By that I mean people actually joining the development team on a consistent basis, and having an overall interest in the engine beyond their favorite pet rock port. Right now it's mostly just @Kratus and myself, and we're overwhelmed as it is trying to get the next release out after over three years.

In fact, when the new release does come out, we're reducing the port count (dropping official support of the PSP).

I don't mean to be harsh about it, it's just I've played this game before and even if we did possess the manpower I'd have zero interest in it.

DC

 

[CommunityPoster55]

@bWWd spelled it out perfectly.

Unless there's a huge uptick in manpower, you can file this under "not going to happen". By that I mean people actually joining the development team on a consistent basis, and having an overall interest in the engine beyond their favorite pet rock port. Right now it's mostly just @Kratus and myself, and we're overwhelmed as it is trying to get the next release out after over three years.

In fact, when the new release does come out, we're reducing the port count (dropping official support of the PSP).

I don't mean to be harsh about it, it's just I've played this game before and even if we did possess the manpower I'd have zero interest in it.

DC

Fair enough...

It was just a suggestion anyway, and at least I got my answer.

Give it another spin just in case. Who knows what might've changed in the past couple of years.

Best of luck with the newest version (and the future). I might help out with some assets if ever needed (whatever they could be).

 

[Kratus]

Fair enough...

It was just a suggestion anyway, and at least I got my answer.

Give it another spin just in case. Who knows what might've changed in the past couple of years.

Best of luck with the newest version (and the future). I might help out with some assets if ever needed (whatever they could be).

As an emulator's enthusiast and intensive Retroarch user, if one day @DCurrent decides to give a try, I certainly want to collaborate with this idea.
However, it breaks my heart, but I think it's not a good idea to have an OpenBOR core today.

The first point is, there's many changes to come. As DC said, we are working to have a solid and consistent basis, making improvements and fixing old known bugs for the engine overall.

My second point is, although OpenBOR seems to be some kind of "emulator" for many people, in fact this is a game engine. Every game is developed for a build selected by the author since the project began.

It means that Retroarch will need to have a lot of different OpenBOR core versions due to every game particularity, similar to multiple MAME cores. If a problem is found in any game, it can be a pain to discover what is a "core bug" and what is a " OpenBOR build incompatibility".

In other words, every OpenBOR game is an independent project and every author has their own way to code. In addition, there may be problems if people try to play a game that is under development or constantly updated, because the author can consider adapting your game to a different OpenBOR build without previous warning.

A last point is about OpenBOR unofficial forks. Some projects are using custom engine versions modified by your authors and may not work properly with official builds.

Of course, it's not an impossible task. Luckily some games were developed in the same OpenBOR builds and will work fine.
The authors (or the community) can adapt or update every game to work with different OpenBOR builds, but it will depend on heavy community efforts and sometimes the originality of the projects can be lost during the process.

In the case of "roms", they have a similar structure related to the system for which it was officially developed. Once you discover how to emulate it, you will only need to improve the performance and compatibility.
No changes are required in the "roms" to make it run properly, except for MAME I think.

 

[NickyP]

I do think it would be a good idea in the long run. With the recent proliferation of DIY "emulation boxes" via retropie, launchbox, emuelec, etc, I think it's an opportunity to expand our user base--players and makers. Buggy, unofficial ports are being made anyways, so it would help to kinda "regain control" of the engine too.

... That said, I'm not an engine developer, and I wouldn't be the one coding the Libretro core. So don't take this as me port begging.

 

[oldyz]

Just throwing this idea.....

would there be away to make a version of Openbor that could "adjust" to the modules trought some kind of .txt file that tells it to "become" or behave like an earlier version?

if this is possible , all that needs to be done is to edit the modules with this information.

I think Mugen has something like that for stages, some stages have information that indicates that they are for an earlier mugen, but i don't know if the engine adjusts itself...

 

[Leonardo Carneiro]

Do it, please

 

[Thatspiceguy]

Speaking as someone who dont know jack about openbor but enjoys the games, it would be awesome to have a core. it would bring many more eyes to the project. but can totally understand why its not possible.

 

[sharkytowers]

I do think it would be a good idea in the long run. With the recent proliferation of DIY "emulation boxes" via retropie, launchbox, emuelec, etc, I think it's an opportunity to expand our user base--players and makers. Buggy, unofficial ports are being made anyways, so it would help to kinda "regain control" of the engine too.

... That said, I'm not an engine developer, and I wouldn't be the one coding the Libretro core. So don't take this as me port begging.

Indeed. I too am just a lowly enthusiast, but the best way to get exposure to these wonderful games is to have a core. I speak only as someone who is pretty new to whole RetroArch thing, but for exactly the reasons stated above from my perspective it would be great. But I don't have to program anything...

 

[arthurix8b]

I have found that there is already a OpenBOR libretro core for RetroArch

github -> retrodiv -> AnyBOR-libretro

It uses internally many OpenBOR engines, so maximum compatibility with most of the games through the different versions

 

[O Ilusionista]

It uses internally many OpenBOR engines, so maximum compatibility with most of the games through the different versions

I took a look at it and I found this:

combining engine builds 3400 (2011-08-31), 3842 (2013-02-23), 4086 (2014-11-02), 4432 (2017-01-25), 6412 (2018-08-29) and 8020 (2026-08-24) in one library

Why the chose some unofficial ports like 6412 and 8020?

This does more harm than good

 

[arthurix8b]

Why the chose some unofficial ports like 6412 and 8020?

No idea, but I guess it will be because, since it aims to open properly as many pak as possible, there will be some games needing these builds. For example, this one requires a quite recent build: fgames9000.itch.io -> streets-of-rage-x

 

[O Ilusionista]

No idea, but I guess it will be because, since it aims to open properly as many pak as possible, there will be some games needing these builds. For example, this one requires a quite recent build: fgames9000.itch.io -> streets-of-rage-x

But using non official builds (well, this core is already non official) is a recipe for disaster.
The last official V3 build was 6391. 4432 was an official one (I've used it myself) and 3400 was official too (very old, back from SourceForge days).
3842 was mentioned only here on the forum, but since it was released by uTunnels, I assume it was official too.

SORX doesn't use a non official build - Kratus is one of the engine developers and his game works as a testing ground for the upcoming releases.
So it's more like a testing build.

The big problem here is that if a "bug" occurs (and I use quotes because sometimes the user is simply running the wrong engine version for a specific game—which isn't a bug, but user error), the vast majority of people will assume the issue lies with the engine itself, when it actually doesn't.
That is exactly what happens with most unofficial ports; we’ve seen it happen time and again.

 

[arthurix8b]

I have been testing extensively with a set of >800 .pak and except 8, all of then loaded and work like a charm. I have not fully played from beginning to end all of them to say if in stage 2.3 there is a glitch in a lamp or something like this, but with the same set of games in Recalbox, for example, 30% of them didn't load at all. So I think this core achieves what it promises: you just launch a .pak and forget (in most of the cases).

Regarding 6391 vs 6412, in all the set I have, the only reference I have been able to find is archive.org -> download -> openbor-pak-collection -> Justice League United [Ver. 219][v.3.0 Build 6412].pak. And no one has any single indication saying it has been built in 6391, so...

And, at least from my side, if I see that a "bug" occurs, I will report in AnyBOR tracker, not in OpenBOR one... Same if I find a bug in dosbox-pure (to say something), that I won't report it in DOSBox but in DOSBox-pure

 

[DCurrent]

The other issue to add here, is treating the engine like some kind of game console or emulator. As in trying maintain one executable and a bunch of game packs. It is not. The worst mistake we ever made IMO was supporting a pack selection menu - which FYI, the latest engine does not have.

The required distribution is now the same as any other engine. One game packaged together with its executable. That is enforced now, but it was always recommended. I highly suggest you follow this model, and move game selection to an outside app. That alone would solve a lot of problems.

DC

 

[O Ilusionista]

Regarding 6391 vs 6412, in all the set I have, the only reference I have been able to find is archive.org -> download -> openbor-pak-collection -> Justice League United [Ver. 219][v.3.0 Build 6412].pak. And no one has any single indication saying it has been built in 6391, so...

I am aware of that.
If I recall correctly, Zvitor used this experimental version because of a control issue in a previous version, and he included both versions (6391 and 6412) in the download. At least, that’s how I remember it.
It would be a good habit for every creator to state the version used to develop the game (I do, for example).

And if people who find a bug in an unofficial version report it to the person who made that version—rather than to the official community—it would be paradise on Earth