GemRB support?

Stuffu

@chilvence Do you have an idea what changes in 0.8.7 that prevents it from running? If I recall correctly, something was going to be implemented in 0.8.7, like widescreen support or something similar?

Stuffu

@mitu I reached out to gemrb and they don’t see anything wrong on their side in the log. OpenGL drivers and shaders are untouched in this release. So likely something in retropie. Still no rush, but wanted to share that to rule out other factors.

BuZz

There is an incompatibility with some shader code. I'll have a look.

mitu

@Stuffu Can you post a complete log on pastebin.com ?

Stuffu

@mitu said in GemRB support?:

@Stuffu Can you post a complete log on pastebin.com ?

Here it is but I don't think it provides any additional info...

https://pastebin.com/eC6ph1im

mitu

I think the error in 0.8.7 is caused by this commit, which forces OpenGLES for the SDL2 plugin when a Raspberry Pi is detected.
Before the commit, OpenGL was not detected or compiled in. It looks like when using OpenGLES, the GLSL shaders included with gemrb are not working with the MESA GLES driver. I don't have any experience with GLSL, so I can't say right now why they fail, but the issue is not a RetroPie installation problem.

The RPI related commit is a bit wrong, it assumes that all PI's use the (legacy) Broadcom GLES drivers/headers - which is not true for a Pi4. The resulting compilation doesn't seem to include those libraries though on the PI4 and - at runtime - it looks like the Mesa GLES driver is used anyway (but this is probably because SDL2 does the right thing and dynamically loads the correct GLES library).

Stuffu

@mitu thanks for checking it out! I’ll reach out to the gemrb project to see if there is something do do about it...

Stuffu

@mitu it would be good if someone from gemrb could reply here, but I try to be a relay...

Is the proposed solution below a way forward?

cool; is the pi4 good enough to just use the lightly accelerated sdl2?

http://sprunge.us/0A2Gos?diff <-- try applying this and rebuilding

mitu

@Stuffu said in GemRB support?:

cool; is the pi4 good enough to just use the lightly accelerated sdl2?

Probably yes.

http://sprunge.us/0A2Gos?diff <-- try applying this and rebuilding

No, that won't work. I'll try to experiment a bit and see if I find the error, then I'll open an issue for gemrb.

chilvence

@Stuffu Sorry, I was just catching up on the happenings at discord and didn't realise you'd tried to ping me. I saw this change go in a few weeks ago but I hadn't tested it out myself.

I do know that there is a huge upending in progress with the backend rendering system, all of which is way over my head, but I hadn't realised the support for the pi4 had been broken. It was actually compiling and running nicely last time I tried, but that was then...

@mitu it sounds like you have already sensed the root of the problem somewhat, if you can shed any light on it by opening an bugtracker issue, I'm not one of the gemrb developers but I am a regular tester and I am armed with a pi4, so hopefully I will be able to help solve this.

mitu

OK, I've opened an issue on the Github project page. It specifically addresses the shader initialization issue reported by @Stuffu, but not the build issues introduced by the commit I mentioned before.

@chilvence if you have a Pi4, you can test the patch I linked and see if it works for you, either with 0.8.7 or the latest master.

Stuffu

@mitu i read the Github issue you submitted. You are so awesome! :)

Stuffu

@mitu It seems there is a commit with the suggested changes and I tried installing from source, removing the "v0.8.7" but it still builds from stable release, without the commits.

This is how gemrb.sh looks, is it maybe related to BUILD_TYPE?

function sources_gemrb() {
    gitPullOrClone "$md_build" https://github.com/gemrb/gemrb
}

function build_gemrb() {
    mkdir -p build
    cd build
    make clean
    cmake .. -DCMAKE_INSTALL_PREFIX="$md_inst" -DCMAKE_BUILD_TYPE=Release -DFREETYPE_INCLUDE_DIRS=/usr/include/freetype2/ -DSDL_BACKEND=SDL2 -DUSE_SDLMIXER=OFF
    make
    md_ret_require="$md_build/build/gemrb/gemrb"

Thanks! :)

mitu

@Stuffu said in GemRB support?:

This is how gemrb.sh looks, is it maybe related to BUILD_TYPE?

No, that's not related to the source version. Without a branch name, it should pull from the master branch - make sure you clean up the downloaded sources before attempting to build from master.

Stuffu

@mitu Progressing on to a new error... O_o

"Could not successfully build gemrb - gemrb - open-source implementation of Infinity Engine
(/home/pi/RetroPie-Setup/tmp/build/gemrb/build/gemrb/gemrb not found).

md_ret_require="$md_build/build/gemrb/gemrb"

The source files are indeed in the /tmp/build/gemrb/ ...

edit, log here: https://pastebin.com/jzUzaKB0

mitu

Oh, yes - master (and v.0.8.7) does not build without -DWERROR_DISABLE=1 (?) added to the cmake line.

Stuffu

@mitu And it worked! Cmake didn't like -DWERROR_DISABLE=1but with -DDISABLE_WERROR=1it built as it should and I can actually play the games and it looks good, finally!

I was about to insert a link to Neverending Story with Limahl, then I read the lyrics and changed my mind :)

Thanks again!

ecto

@stuffu Hi stuffu, you seem to be very committed to GemRB. I just dived into it some days ago, and already had some moderate to huge success. I installed the five games on my Windows computer, updated them to the last official version, applied some WeiDU community fixes and transferred the files over to my Retropie. So far so good: The games run without any complaint (though I had to adjust the GemRB.cfg for the fact, that I put all files from the different disks into the one datafolder).

Now comes the tricky part: I wanted to apply some widescreen resolution and GUI patches:

After some lengthy experiments I managed to install biggs widescreen patch (set to 1280x720) and Ghostdog's UI patch for PS:T. It really looks gorgeous on my TV set!
Fo BG1 I had no such luck. While I can install the widescreen resolution patch, no GUI patch seems to work properly. I tried and tried and gave up eventually. I have the feeling that something with the font handling isn't working, because as soon as I installed the 1280x720 BG1 UI patch by ikonomov I get some error "Assertion 'TextFont' failed".

I also wasn't able to install some ttf font for the higher resolution for any game. That's why I hope to get it to run on a newer GemRB version.

As the v0.8.6 branch is now outdated but the scriptmodule isn't updated yet, I want to try and just make those changes mentioned above manually. Would you suggest to rather use the master branch insead of v0.8.7? Have you tried and successfully installed any widescreen patches?

chilvence

@ecto I have not tried any BG1 widescreen patch for a long time (even though it's pretty much mandatory) but for what it's worth, the future 0.8.8 GemRB release will have resolution independence built in to the UI - it does not actually patch the UI graphics like these mods do, but it places the different panels at the edges of the screen sensibly (so it looks sort of NWN/PoE style)

It's a bit of an awkward issue to solve, since the game originally required a full set of UI 'config' files for every single resolution. These are called CHU files and they should end up in your override folder after running the widescreen patch. You might have more luck if you just use those files and nothing else from the patch - there should (hopefully) be nothing they can do that will cause GemRB to error like that.

ecto

@chilvence Wow! Thanks for your quick reply! I guess that waiting for 0.8.8 is the way to go! In the meantime playing in 4:3 hasn't hurt us in past, right? ;-)

One thing I noticed with the 1280x720 widescreen GUI mod is, that there is a normalN.bam file installed into the override folder. I thought that this might me the font file and tried to delete or replace it, but the error persisted. :(

If I have the time, I will look into the CHU files. Thanks for the hint!