OpenBOR 6xxx OpenBeta Testphase

[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 ;)

[BiZzAr721]

@cyperghost I noticed at the OpenBOR logs were in dev/shm last night. I updated @darknior 's post with a good size selection of games I tested that work - most of which were unable to play on the 3600 version.

I also was very pleased to see when I saved system.cfg through OpenBOR settings, those settings carried through to new mods that did not already have a config! (also noticed joypad setup on gamelist in your video) ;)

Back to what I mentioned at the end of my last post, 3600 binary you made - is that based off Rofl0r's or completely from an official source? I thought it was just an enhancement to Rofl0r's for until I realized 3600, not 3400.

I definatly think the 3600 should be considered to be installable through retropie setup - maybe not together as I was originally thinking, but there are definitely mods that run better on an older version, if they run at all. (Asterix and Ceasar's challenge crashes during gameplay in 6xxx) I found a bit more but didn't document them yet.

If your new 3600 has in fact no association with Rofl0r's, then I think this should be available as OpenBOR - 3600 and made installable from binary. I also strongly agree Rofl0r's should be removed. Anyone who already has it, nothong changes. Anyone new, will be ushered to the new 3400 & 6xxx - therefor slowy choking Rofl0r's version out of use.

[cyperghost]

@bizzar721 said in OpenBOR 6xxx OpenBeta Testphase:

is that based off Rofl0r's or completely

It is complete based on Rofl0r's branch. Therefore I'm not very pleased to support this. Only the 6xxx is an official branch.

[mahcneto]

Sorry to ask guys but after reading all of this and the other link with the experimental packaged Openbor release I can't understand at all about the installation about Openbor 6xxx version. I'm a Mod maker actually in Chrono Crash, I'm Mr.Q, and I'm working in a SNES Double Dragon based game. Can you give me the steps to get this working so I can test my beta version in my Pi3?

[cyperghost]

There are two ways

1. If you have RetroPie 4.4 then you can install preinstalled binaries. For RetroPie 4.3 I have also a binary precompiled.

Just enter with SSH and type wget "http://raw.githubusercontent.com/crcerror/OpenBOR-63xx-RetroPie-openbeta/master/openbor_openbeta.sh"; bash openbor_openbeta.sh galina; rm openbor_openbeta.sh

The version is installed to /home/pi/openbor_openbeta
PAKs files can be placed to /home/pi/openbor_openbeta/Paks if an older instance of OpenBOR was already installed then the PAK path is likely /home/pi/RetroPie/roms/ports/openbor

A script that just launches OpenBOR graphics menu will be added to PORTS section.

2. Follow instructions from here: Beta scriptmodule then PAK files are placed to /home/pi/RetroPie/roms/ports/openbor and OpenBOR 6xxx is compiled on your own mashine. A script for selection PAK files will be place to PORTS section

Please use @ sign and write name like @mahcneto to tag people, then they will be informed of being mentioned to a post.

Welcome to our forum ;)

[darknior]

@cyperghost said in OpenBOR 6xxx OpenBeta Testphase:

It is complete based on Rofl0r's branch. Therefore I'm not very pleased to support this. Only the 6xxx is an official branch.

I know you don't want to support this release but can you share me your 3600 binary compiled for RetroPie 4.3 please ?
I really want to try it with some games to complète the 3400 and 6315 games :)
More OpenBOR version i have, more games i have a chance to launch on pi :)
Thanks

[cyperghost]

@darknior Sorry for misunderstanding ... it's 3400 with PAK support.
Download here, you can just exchange current RetroPies OpenBOR with this one in location /opt/retropie/ports/openbor

[mahcneto]

@cyperghost Thank you! Just tested my WIP game and it works flawlessly! If someone wants to give it a try, it's here: https://gx-openbor.blogspot.com/2018/08/billy-lees-moveset.html