OpenBOR 6xxx OpenBeta Testphase

cyperghost

ScriptModule for RetroPie newest versions!

Just for testing purposes!

cyperghost

Added Scriptmodule!

BiZzAr721

Trying it out now. I removed openbor from experimental packages, deleted openbor_beta folder as well as removed emulator.cfg.

It was option 357 OpenBOR - Beat 'em Up Game Engine v6512

Launching mod failed. It showed it compiled. Script loads, but when I execute game I get error OpenBOR - Beat 'em Up Game Engine.sh line 20: opt/retropie/supplementary/runcommand/runcommand.sh: no such file or directory

line 20

"opt/retropie/supplementary/runcommand/runcommand.sh" 0 _PORT_ "openbor" "$choices"

right below joy2keyStop ........my kryptonite!

EDIT
The compiled OpenBOR does run using conventional methods

cyperghost

@bizzar721 Arghh... missed the slash in the path. Thanks!
You can edit nano $HOME/RetroPie/roms/ports/OpenBOR - Beats of Rage Engine.sh and last line add / to path so it looks like "/opt/retropie/supplementary/runcommand/runcommand.sh" 0 _PORT_ "openbor" "$choices"

Thanks for catching this one :D

@darknior
I tried TMNT Shell Shocked Rev 5853 it's running smooth by using the scriptmodule, too. Even if there are 6 enemies in screen it does not stuck. My filters are: Hardware: Bilinear, Software: Simple 16bit ... so it makes sense to load the GL drivers.

@mitu Do you see things to improve? How can I get rid of the wget command?

darknior

@cyperghost said in OpenBOR 6xxx OpenBeta Testphase:

I tried TMNT Shell Shocked Rev 5853 it's running smooth by using the scriptmodule, too. Even if there are 6 enemies in screen it does not stuck. My filters are: Hardware: Bilinear, Software: Simple 16bit ... so it makes sense to load the GL drivers.

Thanks if it works fine for you too, it's that i have a problem but i don't understand what ?
I use your binary file, you write to load GL drivers ... i don't understand what i miss ?

I will try your install script this evening ... but you only installing the last version 6315. And i have some old games that only works with the 3400 version. Can you update it to have the two binary in the same folder and let the user choice like we can do with emulators. It's what i do on my pi. Thanks

cyperghost

@darknior Uff... this is my first scriptmodule I've written. So I don't know all commands how to add new ports. Let's wait for feedback I think at least some more people will tinker in. I hope that someone makes a better script for this.

About TMNT maybe you see slowdown I don't catch. This game brings the Pie to the edge of computing power. htop says 95%+ of CPU usage, it's a pitty OpenBOR uses just one core :( I see slowdowns of TMNT in snow level for example....

mitu

@cyperghost said in OpenBOR 6xxx OpenBeta Testphase:

@mitu Do you see things to improve? How can I get rid of the wget command?

There are a few things you could change on the technical side

The libGL part (for gl2es) should be installed from source also. There is already something similar in @zerojay's RetroPie-Extra repository - see for instance how fofix is installed. I would also separate it in a function on its own.
Patches can be handled by the RetroPie setup script on its own - create a folder similar to the module name and use the applyPatch function. A good example is how RetroArch is built from source - https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/emulators/retroarch.sh.
Your module is excluded when the platform has the x11 flag, but in the build phase you still test if the compilation is done on such platform to add the PANDORA flag.

Now these observations are done by just skimming the source, I haven't had a chance to actually test the module.

I do also have some not-really-technical observations about the scriptmodule as a whole

if you intend to submit it to the RetroPie-Setup repository, then IMHO you should
- rename the module to something else, may I suggest openbor-current or openbor-dev. This will prevent conflicts with the existing module.
- fork the RetroPie repository and create your own branch, then develop there. It would be much easier to create PRs and for testing (i.e. people could add your branch in their RP setup folder and just use the module directly).
create a script launcher to wrap the OpenBor binary and optionally add the GL stuff (parameter for gl4es s, loading the GL library), instead of putting every command in the port command definition, i.e. instead of

addPort "$md_id" "openbor" "OpenBOR - Beats of Rage Engine" "pushd $md_inst; $md_inst/OpenBOR %ROM%; popd"

create a openbor-launch.sh script and use

addPort "$md_id" "openbor" "OpenBOR - Beats of Rage Engine" "openbor-launch.sh"

Ideally you could have 2 scripts - one using gl4es and one without it, but I'm not sure this would work for Ports (though it would be ideal IMHO if it would be a standalone system).

cyperghost

@mitu said in OpenBOR 6xxx OpenBeta Testphase:

Ideally you could have 2 scripts - one using gl4es and one without it, but I'm not sure this would work for Ports (though it would be ideal IMHO if it would be a standalone system).

Yes therefore I patched Makefile to make additional lib path next to binary. I think in this case every GL-wrapper should be build for it's special needs.

I really appreciate your solid feedback. I think it's a good way to recompile GL4ES like @zerojay has done with some additional patches by using applyPatch.

I do not know if there are documentations ready for these patch modules, I just used some functions and commands that I could interpret from scriptmodules already in use.

In the meantime I would appreciate if you could make some tests with OpenBOR 6xxx branch - the galina patch is most optimzed. My knowledge about C code is just on basic level. So I'm on a dead end in optimizing the engine itself. I hope @zanac can help... He had done all the code working. I just collected his outfindings and made it useable by scripts.

cyperghost

@mitu I tried to disable gl4es ... it is painfully slow without the wrapper. It is needed in any case. But simple16bit is the only software filter that can be used (it is the default one), hardware filters can be changed, too and there you get better outcome with GL4ES

About a dev-branch.... well to be true it can be used as main. Because this version outbeats the old version in every case.

uses newest modules
The graphics is better
working load/save support
reconnects input devices properly
PAK file support
...

Only disadvantage... it will likely not run on PI0/1

mitu

@cyperghost said in OpenBOR 6xxx OpenBeta Testphase:

Only disadvantage... it will likely not run on PI0/1

1/10 - downvoted.

mitu

@cyperghost said in OpenBOR 6xxx OpenBeta Testphase:

@mitu I tried to disable gl4es ... it is painfully slow without the wrapper. It is needed in any case. But simple16bit is the only software filter that can be used (it is the default one), hardware filters can be changed, too and there you get better outcome with GL4ES

If it runs better with gl4es then sure, it should be the default. Just remember that if you'll want this version to run also on a x86 (i.e. Ubuntu on PC), it should be optional - both during installation and runtime.

About a dev-branch.... well to be true it can be used as main. Because this version outbeats the old version in every case.

uses newest modules

The graphics is better

working load/save support

reconnects input devices properly

PAK file support

...

My advice to use another name is just a precaution to not break existing users' setup. From what I've seen in the topics discussing this new version, there might be cases where this new version is not backwards compatible. If someone has already installed the current version in RP and one of the games installed does not work - or works badly because of broken compatibility - with the new version, then it's not good. Just my 2c.

BiZzAr721

@mitu @cyperghost I fully understand why you would want to name it different, and I definatly think both versions should be available. My suggestion, if it is possible, is to setup both binaries during setup, keeping the 3400 build named the same, and adding OpenBOR 6xxx as an alternate emulator in emulator.cfg.

Since the 3400 build is the same, except with enhancements, it would not break anything, only enhance the experience with save states, better performance & command line interface. If the user is not set up to use CLI, it will still function as normal, but with the added performance enhancements, video filters, and most importantly, working save states.

Essentially, it would be a worthwhile upgrade for anyone using the current OpenBOR, with the added bonus of having the latest as well.

cyperghost

@mitu
Just as follow up and why we act like this.

A programmer named rofl0r aka anallyst had created a first port for ARM devices. Somehow it came to discrepancies within the OpenBOR development team (only the developers know more details) and he was dismissed from the project. At that time rofl0r was working on his own OpenBOR fork which was extremely tuned for efficiency. This version is still installable from RetroPie. This seems to be one of the reasons why today's developers have never really used Raspberry as their development platform (in my humble opinion!). All branches under 4xxx officially no longer exist as source code, all support of the old SVN forks will be discontinued. This is the rule followed by the ChronoChrash team (this is the development team behind OpenBOR).

@bizzar721
Now you come into play. The version currently used in RetroPie does not support PAK files. Each module must be unpacked separately to start a mod. This is extremely inconvenient and now comes the important point... this prevents a coexistence of new OpenBOR (6xxx branch) with the old one. Of course you can have two module versions, but personally I would never give up the comfortplus of the PAK files.

I still hope that ChronoCrash will also support Raspberry as a platform. I think with Raspberry 4 the graphics processor will also improve and maybe support OpenGL natively. This would make the support much easier.

@mitu
There is just an old version with PAK support. As a hidden download here. Just read the README and you will understand why you should not support this version out of respect. I also compiled from this one a runable binary. You can get it here. It is the openbor_3400_pak binary.

@darknior
As I have written in many postings, he had the ingenious idea to patch the source code so that single modules can be loaded by command line. I also did this in all subsequent versions (with a slight modification).

@zanac
Had the idea to implement the latest version on an Allwinner board. He introduced the GL4ES wrapper and with his help we were able to reach the current state of development.

@cyperghost
My final words are that OpenBOR is a very interesting project. The modules are lovingly crafted and fortunately the Raspberry 3 has enough power to run many modules at good speed. Unfortunately all software filters are not usable.

The official way, in my opinion, would be to officially submit the support for version 6xxx to our development team (I still need help with the script module) and try to improve the performance of the 6xxx RPi branch.

This version can be compiled on an RPI1, but without the corresponding wrappers. This means that maybe only very old and simple game modules will run on these systems. So you might be able to keep the script module of the 3xxx branches (unofficially) just for these systems. Unpacking the files speed up the whole process.

@mitu
Are you more enlightened now? ;)

mitu

@cyperghost said in OpenBOR 6xxx OpenBeta Testphase:

Are you more enlightened now? ;)

More or less.
As I said, I followed the topics you already have opened and I pretty much know this information.

cyperghost

@mitu Then please excuse my ignorance ;)

BiZzAr721

@cyperghost said in OpenBOR 6xxx OpenBeta Testphase:

Now you come into play. The version currently used in RetroPie does not support PAK files. Each module must be unpacked separately to start a mod. This is extremely inconvenient and now comes the important point... this prevents a coexistence of new OpenBOR (6xxx branch) with the old one. Of course you can have two module versions, but personally I would never give up the comfortplus of the PAK files.

I could use a little enlightenment....
You have a compiled 3400 version that not only runs well, but loads from .pak. Why wouldn't you use that one which will not progress any further but can run many older games which newer OpenBOR cannot. I am running both versions side by side, loading from .pak and it works great. I know we will not support rofl0r, but will not abandon his version until we get a viable replacement otherwise much compatability will be lost.

I have been working on a script to pack .bor folders to .pak but I cannot get it to execute from windows except for within the rom directory. I have gotten it to copy neccessary pack scripts/.exe to each .bor folder and create an edited makepack.bat to create a properly named .pak but I could not get it to execute unless I went directly into the .bor folder and executed it.

I'm sure with a little work we could get that to happen from linux, and then all that would need to be done is run it against your paks folder, converting .bor folders to .pak.
Then both versions can be enjoyed with minimum setup

cyperghost

@bizzar721 said in OpenBOR 6xxx OpenBeta Testphase:

Why wouldn't you use that one which will not progress any further but can run many older games which newer OpenBOR cannot. I am running both versions side by side, loading from .pak and it works great.

I use that exact configuration on my Pie setup.
The big advantage the 3600 has, it takes 10-20% less CPU usage on a Pie3, so it is suitable for Pie1/0, too.

I know we will not support rofl0r, but will not abandon his version until we get a viable replacement otherwise much compatability will be lost.

I think that's a decision that must be taken by our dev-team. I'm not sure how our Global-Moderators are aware of our development. So I ~~tagged them~~ know mitu is aware of this ~~and they should read this thread to see progress and answer our questions ;)~~
EDIT: Just saw that @mitu is a member of the moderator team! Congrats my friend ;)

My deep hope is, that the ChronoCrash-team will take on development for RetroPie branch and I believe that the progress that is done to 6315-version of OpenBOR to Raspberry is a kind of breakthrough. Therefore we should be careful how we use the old branch.If we ignore their "code of conduct" they ignore us. Simple rule!

They know about our work and I think if more and more people get aware of of using OpenBOR through RetroPie we are on a good state ;)

I know we will not support rofl0r, but will not abandon his version until we get a viable replacement otherwise much compatability will be lost.

Well I think 3600 version is needed for Raspberry 1/0 only! The CPU is weak on this platform so I think 6315 will be pure overkill.
Most modules run fine on 6315 branch out of my 14 installed modules only 1 failed (Streets of Rage Z).

So I think OpenBOR 3600 may be used on Raspberry 0/1/2/3
OpenBOR 6xxx should be used on Raspberry 2/3 ;)

All in all our devs decide what to do ;)

BiZzAr721

Unless I'm misunderstanding, the 6xxx OpenBOR script should be renamed to not conflict with rofl0r's OpenBOR which will stay. If that is true, and it's for sole purpose of keeping them unassociated, then maybe OpenBOR 6xxx could be named in a way that it would not conflict with the depreciated version, and can be run along side as we do.

I absolutely respect openbor team's requests of not continuing Rofl0r's work, but since that version of OpenBOR is no longer available, and Rofl0r's version is the only option, I actually think it detrimental to the creators of older, completed mods that do not work on newer versions of OpenBOR. We all already agreed we would much prefer an official source, but it's just not available.

That said, if OpenBOR 6xxx is to be a seperate script and Rofl0r's depreciated version is to remain, then I see no reason not to update it to a more functional version that you created where .paks can be used, and most importantly save states.

I found good handfull of games not working on 6xxx that worked on 3600. (Also, didn't play any enough to know if there will now be new bugs)

Also, just so I'm not mistaken, I just realized you have 3600, not 3400. Your enhanced 3600 is based off Rofl0r's build, right? And if source is found it can be compiled from original?

Thanks for your time reading all this!

cyperghost

@bizzar721

Unless I'm misunderstanding, the 6xxx OpenBOR script should be renamed to not conflict with rofl0r's OpenBOR which will stay.

Yes, the script will be renamed to openbor-6xxx just to show branch development.
The resulting binary will be named openbor-6xxxx just to avoid confusion
The emualtor call will be named ob6xxx

But binary and gl4es wrapper will be setted to old location /opt/retropie/ports/openbor

The only thing I will change to old script is the location of LOG-files....
I will link to /dev/shm/ as votaile memory. This is because some modules run mad and give endless error outputs. I want avoid sd-card corruption.

The old version with unpacked files can be left untouched. Some people here know how to transform the old binary to a working one with pak-support. So I think it's a way to go.

You should go to chronocrash forum, say have realy nice game developers here and some mod developers help to give weaker devices a good gaming experience.

darknior

@bizzar721 said in OpenBOR 6xxx OpenBeta Testphase:

rofl0r's OpenBOR

I really don't understand why do you want to take in Retropie this old version of rofl0r's OpenBOR, with or without my hack ...
It's deprecated and must be remove from Retropie-Setup, i think...

On Retropie-Setup we should have OpenBOR alone, with normal name, because it is the officiel OpenBOR today and compiled for PI.
And almost all the games are working fine with it.
We should only have also the 3400 version, compiled for PI with save and pak support for some old games that works only with it and we can't update for 6xxx version ourselves ...

You can make two binary installation, and two source installation for each engine compatible with all Retropie versions.
The user can install the one or two versions if he want, and when he launch his game use the runcommand menu to choose the good engine for the game.
I think it is the easier solution for everyone ;)