OpenBOR finally working fine on RETROPIE with ES

darknior

@cyperghost Thanks a lot, i will try this Monday ... so excited :p
Now we have SDL2 on PI, that cool :)
Have you try it with other emulators like ScummVM or Amiberry ? I know they works better with SDL2.
And i know there is also a version of LR-Desmume (Nintendo DS) that works fine on PI with SDL2 + OpenGL ...
The work you make here can help these other emulators ;)

cyperghost

@darknior No I've done nothing ... just a bit compiling and testing. All credits go to @zanac

I suggest him to use your way of loading PAKs, I think that's a robust way.
I changed counter set of arg to 2, as long there is no further command line options only this makes sense. And the precheck of fileEx provided by OpenBOR code itself.

Passing pathes and files makes our ES frontend.

   dirExists(paksDir, 1);
   dirExists(savesDir, 1);
   dirExists(logsDir, 1);
   dirExists(screenShotsDir, 1);

   // Test command line argument to launch MOD
   int romArg = 0;
   if(argc == 2) {
      loadsettings();
      memcpy(packfile, argv[1], strlen(argv[1]));
      if(fileExists(packfile)) {
         romArg = 1;
      }
   }

   if(!romArg)
Menu();

zanac

Scummvm i made a cool libretro core if you are interested i share binary....

@darknior said in OpenBOR finally working fine on RETROPIE with ES:

@cyperghost Thanks a lot, i will try this Monday ... so excited :p
Now we have SDL2 on PI, that cool :)
Have you try it with other emulators like ScummVM or Amiberry ? I know they works better with SDL2.
And i know there is also a version of LR-Desmume (Nintendo DS) that works fine on PI with SDL2 + OpenGL ...
The work you make here can help these other emulators ;)

oilusionista

@darknior said in OpenBOR finally working fine on RETROPIE with ES:

and to see that the OpenBOR Team did not want to change its code I do not know why, while we try to improve things ... I saw red.

Sorry, I don't get it. Can you elaborate?

zanac

@oilusionista said in OpenBOR finally working fine on RETROPIE with ES:

@darknior said in OpenBOR finally working fine on RETROPIE with ES:

and to see that the OpenBOR Team did not want to change its code I do not know why, while we try to improve things ... I saw red.

Sorry, I don't get it. Can you elaborate?

I think that they talk about the old legacy version, but now that i found the way for make working 6xxx version with just a couple of line change using gl4es libs, i think that make not sence work in that version. Monday i will share code, to make openbor work with gl4es there is just only two line of code to change, i think that this small change you can sponsor it to be included in the official version, right?

BiZzAr721

@cyperghost I tried out the latest OpenBOR! Man, that is sweet! Looks & plays great. He - Man put a load on the pie (3B anyway, not plus) but everything else worked great.

@oilusionista I played your Avengers United Battle Force Frickin awesome. I can't believe how many moves each character has! Looking forward to giving this a proper play through and finding all these other secrets & bonuses I'm sure you tucked away!

With the progress that has been made, don't know if the old sources found at sourceforge could be of any use?

cyperghost

@bizzar721 The older ports can still be used for Dingux

for example. So they are still usefull for older devices. I think we can dismiss the old source for our Pi builds.

darknior

@zanac said in OpenBOR finally working fine on RETROPIE with ES:

Scummvm i made a cool libretro core if you are interested i share binary....

WOAW yes for sure !!!!
I love ScummVM, i had myself one game langage driver on the Scumm git.
Please share it with maybe a git source, to add it to Retropie-Setup :)
And maybe make it official, it is fantastic to have ScummVM on Libretro :p
Have you also implement LR options like Savestate rewind .... ?

I have dream one day OpenBOR too was ported to LR lol
To make it working on all the systems where LR working :D

darknior

@cyperghost said in OpenBOR finally working fine on RETROPIE with ES:

@darknior No I've done nothing ... just a bit compiling and testing. All credits go to @zanac

I suggest him to use your way of loading PAKs, I think that's a robust way.
I changed counter set of arg to 2, as long there is no further command line options only this makes sense. And the precheck of fileEx provided by OpenBOR code itself.

It is really a dream that become true <3 Thanks @cyperghost and @zanac
I have play Street of Rage 2X on my TV with the PI !!! So excellent lol
Now we only miss my loading PAK trick, that i wish will become one day official for all the versions of OpenBOR. It can help other people i think on PC linux and Wii.
And if possible update the video support, i don't know how to write it in english, because if i use filters like scanline the game is very slow :( ... I think PI can do it but some thing is bad configured.

oilusionista

@zanac said in OpenBOR finally working fine on RETROPIE with ES:

@oilusionista said in OpenBOR finally working fine on RETROPIE with ES:

@darknior said in OpenBOR finally working fine on RETROPIE with ES:

and to see that the OpenBOR Team did not want to change its code I do not know why, while we try to improve things ... I saw red.

Sorry, I don't get it. Can you elaborate?

I think that they talk about the old legacy version, but now that i found the way for make working 6xxx version with just a couple of line change using gl4es libs, i think that make not sence work in that version. Monday i will share code, to make openbor work with gl4es there is just only two line of code to change, i think that this small change you can sponsor it to be included in the official version, right?

The only person who can make it official is Damon Caskey, not me. But I doubt he will make it official. And there is a reason for that - lack of human resource.

Each time we add an official port, we need someone to have experience on that system to be able to give support (iow, fix incoming bugs) to that platform. But its not what happens - people adds a port, support it for some time than vanish. And the height remains on the other devs.

This is why DreamCast version (and some others) were removed last year.

oilusionista

@bizzar721 Thanks, I am glad you liked it :) For the next version, I should add 5 new playable characters. One of them is Nightcrawler, and here is a video preview (watch until the end for a cool gran finalle)

At my channel, you will find other previews, like Hercules and Iron Fist (which will be added on the next version) and even a pool, to decide who should be added too - Colossus or Iceman. Follow the link on that video if you want to vote :)

cyperghost

@oilusionista Therefore we will build diff patches. We download from official git and patch our changes in and then start the compiler. But I doubt that support of Raspberry will vanish that fast... so I do not really understand these concerns. I think the changes done to source code are not massive, mostly the makefile arguments imho. We will see what happens ;)

EDIT: Nice game ;)

oilusionista

@cyperghost Thanks!
About the official build, we can point people to here to get the PIE version. I am even promoting this on some youtube channels :)
We just don't want to bite more that can chew.

Plus, you can ask to join the official Dev team if you want to.

cyperghost

@oilusionista Well that is nice offer thank you.
I would stick to the diff-patch way and I think the OpenBOR-dev team can promote the usage of the Pie. I saw the latest changes done by @zanac and this were just a few code lines... So it is clear how to maintain.

About the users.... Well you can't compare the Pie port with a XBOX or PS port. The Pie was developed to be a learning platform in computing. So I say that every person who works with a Pie gots a minimal knowledge of unix systems. You must clearly divide between image bakers and computer enthusiasts and the enthusiasts are more common to the Pie platform. So a solid port with good support/testers is very likely. Sadly OpenBOR was up to now a "niche" for this platform and for RetroPie.

It was @darknior who brought OpenBOR to a wider audience in this forum because he has done a small patch that offers Command line Input like OpenBOR Asterix & Obelix.pakand this is so necessary ... because EmulationStation ... our frontend lists files with a suffix as system and just parses the commands...
Then @BiZzAr721 and @hansolo77 created a list of working mods, this made me aware of OpenBOR and I wrote some scripts to autoconfigurate OpenBOR with different settings and did the call to runcommand which offers LOG support and more opertunites for setup. And now @zanac made newest versions available via GL4ES wrapper with some testing done by various people ... and that's the story of the OpenBOR development... (with some missing details for sure)

darknior

@cyperghost i have try the game "TMNT Rescue Paloosa" the last beta, and this one working fine but when you have more than 1 or 2 ennemies on screen the game is very very slow :( And i don't use video filter ...
This game use many many big script to improve OpenBOR engine :)
I think it is the problem here, maybe the original resolution too ? I don't know if OpenBOR can be optimized for PI proc?

cyperghost

@darknior There is space to optimize. This now runs with SDL but with the right wrapper settings in GL4ES it is maybe possible to select OpenGL.

darknior

@cyperghost Like you i think we must have the two versions of OpenBOR on PI :(
Like they do on PC with many Windows version for each games ...

I must use 3400 for

Asterix & Obelix
Bare Knucles 6 (but it crash some time...)

Function getentityproperty must have a string property name.
Script function 'getentityproperty' returned an exception, check the manual for details.

Bare Knucles Vacum v4.1 (but crash during loading of a script) :(

All the new games working fine with the last version ...
I will try to find time to test each game one by one ...

We will always have this problem with some games, made with a specific OpenBOR version we don't have on PI ... :(
Or maybe we can find some one who can help to fix games for the old or the new version.

cyperghost

@darknior We can compile older sources, too. Maybe 43xx branch. I am sure we can do the same changes here - did not test now.

darknior

@cyperghost Yes, thanks, i think you are right et we must have some other OpenBOR versions like the 43xx too.
It was the problem of OpenBOR from the beginning, it evolve but there is no retro compatibility with games :(
Or the games don't write for what number version they are created ...

zanac

As i promised.... here you are what i done, sorry i have not too much time to write all in a clear way but i'm sure that you will understand reading... if in doubt just ask!

GL4ES, just try my fork:
https://github.com/zanac/gl4es

In CMakeLists.txt added:
set(NOX11 ON)
set(NOEGL ON)
add_definitions(-marm -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard -ffast-math -fomit-frame-pointer)

the NOX11 and NOEGL should be tested, i added these lines last weekend and have just seen that in allwinner board work better ('cause with these i removed some dependencies if you use GL with framebuffer)

In src/gl/init.c
I changed defualt to ES 2.0:
#define DEFAULT_ES 2

After this you should run cmake and compile:

cmake . -DBCMHOST=1
make GL

For use the lib i suggest this minimum environment variable:
export LIBGL_FB=2
export LIBGL_FBOMAKECURRENT=1

OPENBOR, i don't make a fork, but it's rather easy to patch the build_pandora, if you have time just create a new build_rasbperry with these tricks!!!

ifdef BUILD_PANDORA
TARGET = $(VERSION_NAME).elf
TARGET_FINAL = $(VERSION_NAME)
TARGET_PLATFORM = PANDORA
BUILD_OPENGL = 1
BUILD_WEBM = 1
BUILD_LINUX = 1
BUILD_SDL = 1
BUILD_GFX = 1
BUILD_PTHREAD = 1
BUILD_SDL_IO = 1
BUILD_TREMOR = 1
BUILDING = 1
CC = gcc
INCLUDES = $(PNDDEV)/include
$(PNDDEV)/include/SDL
OBJTYPE = elf
LIBRARIES = $(PNDDEV)/lib
ifeq ($(BUILD_PANDORA), 0)
BUILD_DEBUG = 1
endif
endif

I also patched CFLAGS for arm optimization:

CFLAGS += $(addprefix -I", $(addsuffix ", $(INCS))) $(ARCHFLAGS) -D$(TARGET_PLATFORM)
CFLAGS += -g -Wall -Werror -fsigned-char -std=gnu99
CFLAGS += -marm -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard -fomit-frame-pointer -ffast-math -O3

The lib should link GL:

LIBS += -Wl,-rpath,$(LIBRARIES) -lSDL2 -lSDL2_gfx -lGL

The only source that i bad patched now is opengl.c:

in sdl/opengl.c

I made these changes:
// create an OpenGL compatibility context, not a core or ES context
#ifndef WIN // except on Windows, where some Nvidia drivers really don't like us doing this
//zanac, these attributes don't work well in allwinner (rasbperry too?)
//SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_COMPATIBILITY);
#endif

    //zanac, it seems that you should always create a new context without delete the old one, this happen in allwinner (rasbperry too?)
    //if((context = SDL_GL_GetCurrentContext()))
    //      SDL_GL_DeleteContext(context);