Possible to port GridWars 2

spud11

@mitu said in Possible to port GridWars 2:

./gridwars-armhf-rel

Hi mitu. Happy New Year! Yes, I have given it the correct permissions and for good measure used the command you gave. I have also tried ./gridwars-armhf-rel, but get permission denied.

fluffypillow

Just tried the binary on an up-to-date RetroPie, and it launches fine for me, without sudo or anything. Your errors seem to show filesystem issues as @mitu said; are you trying to run the game from USB or Samba share perhaps? Have you tried a different SD card?

As for the game, due to the GLES lib name changes on Stretch, it hangs on startup with an initialization error, then eventually crashes (patching the binary is not enough). Likely a bug in the engine itself.

mitu

@spud11 I got the same behavior as @fluffypillow - the program starts, but it's not fully compatible and crashes. But it's not the same error as yours, for sure.

cyperghost

If someone is interested for Windows version.
This link seems to be the only woking one

You will find download link directly under first picture ;)

toto2000

Up ! Can someone sum up where we are?
Which version did you use ?
I can certainly help going forward with this quest (having GW run on the pi), I'm a CS engineer...

fluffypillow

@toto2000 great! So at the moment on Debian Stretch the game doesn't start up properly, however it used to work (as in, launched) on Jessie (Wheezy?). There are quite a few issues with the engine causing crashes, you may want to run through the code with the debugger to catch them all.

You can get the code and my patches here, and also some build instructions. A prebuilt binary is here, the one that used to launch originally.

spud11

@toto2000 That would be great. I was unable to get the pre-built binary to work on Jessie (which I'm still on).

toto2000

@fluffypillow Ok, I already managed to recompile completely the compiler itself and maxIDE on my Mac + compile GridWars using the command line + MaxIDE. Next -> recompile all these things in the Pi. I followed your instructions + get your controls.bmx patched file (original did not compile due to a Joycon not found error)

Do you have an idea of what was going wrong? Problems with the OpenGL version?

toto2000

@fluffypillow Which version of the compiler did you use? This one : https://github.com/bmx-ng/bmx-ng/releases/tag/v0.81.3.16.rpi or a more recent one that you recompiled for the pi? On the Mac I used https://github.com/bmx-ng/bmx-ng/releases/tag/v0.99.3.31.macos and was wondering if I could recompile the up to date sources on the Pi, like I did on the Mac... Maybe this would maximize the chances of building a runnable GridWars..?

toto2000

@fluffypillow You have been talking about Opengles, but the REAL OpenGl should be supported on Pi (see

) with the Mesa lib... I saw that you added some ? if nopt Opengles in some of the bmx files so that it compiles. Do you think that might be the problem when the game was badly running? Do you think it was slow because it did not use OpenGL hardware acceleration two years ago?

Look at the YT video I linked. Apparently, OpenGL hardware acceleration is still experimental in 2018 and should be turned on from raspi-config... Ok, I'm investigating, and will let you know if I find something interesting...

mitu

@toto2000 Turning on the OpenGL driver will probably break the other RetroPie emulators, so be aware of that when testing.

toto2000

@mitu Ok. I'll see what's happening then....

toto2000

@mitu The problem is that Gridwars uses the OpenGL driver that requires OpenGL 1.1 minimum. (See this line in gridwars.bmx :

Framework BRL.GLMax2D

If I change this to :

Framework Pub.OpenGLES

That is the framework supported by default by the Pi, then, many things will not compile (such as TImage not recognized etc.)

So, we have to stick with the openGL driver. And if it's not hardware accelerated, then the Mesa OpenGL software implementation is certainly the one being used, that for sure will make the game unplayable.
My goal is to 1) recompile blitzmax tools (not use the old precompiled binary) 2) compile GridWars 3) try with the experimental hardware accelerated driver.

I'll keep you informed...

fluffypillow

@toto2000

Which version of the compiler did you use? This one : https://github.com/bmx-ng/bmx-ng/releases/tag/v0.81.3.16.rpi or a more recent one that you recompiled for the pi?

Yes, I've used that for the on-the-Pi builds. It used to be "just a few days old" back when I've compiled the game first; a newer version would certainly have more chance for success.

Problems with the OpenGL version?
Do you think it was slow because it did not use OpenGL hardware acceleration two years ago?

Yes, there are several places where desktop OpenGL calls are used for effects. As a workaround I've disabled them, but that didn't help with the rest of the crashes unfortunately. If I remember correctly there wasn't proper Mesa support back then, so trying it out now would be an interesting experiment.

cyperghost

@toto2000
Maybe this can help
https://github.com/ptitSeb/gl4es
This made OpenBOR 6xxx branch run on Raspberry.

toto2000

Thanks, I will give it a try... I'll certainly have time tomorrow....

toto2000

Ok, here is where I am:

I compiled the last blitzmax-ng Linux distrib, bcc and bmx built fine, but it crashed during the compilation of makedocs.bmx with a -m32 error. However all useful commands for compiling were built ok.
I tried to compile the original sources of GridWars, but it failed due to some errors in images.bmx (type timage not found) and utils.bmx (plot not found)
I then compiled https://github.com/ptitSeb/gl4es, added <gl4es_dir>/lib/libGL.so.1 to my LD_LIBRARY_PATH, tried to recompile without success (this lib is for linking normally)
Then I went back to compiling the patched version from @fluffypillow that I think was modified to use SDL instead of OpenGL and I followed his instructions for compiling. It worked (I did not have to add -LEGL at the end, maybe I should have done this?)
I tried to run this version -> it displays "GL2 (with shaders) Active", then it does a Segmentation fault

I will try again to compile the original version. If you have suggestions, you're welcome :-)

cyperghost

@toto2000 not sure but I think lGL switch can be used with gl4es

fluffypillow

@toto2000 yes, one of my commits disabled the OpenGL calls and made the game to use an SDL-based graphics implementation that used EGL instead of desktop OpenGL. That used to work, I wonder if there's anything newer since then.

You'd only need to add flags if the compiler misses some symbols, but I guess that won't come up if you link to gl4es instead of EGL.

cyperghost

@spud11 said in Possible to port GridWars 2:

@fluffypillow @herb_fargus Thanks for your replies, guys. Must admit I haven't even been able to get it to run at all. I've copied the gridwars-armhf-rel file into a folder together with all of the source files. The binary is executable. I've run the binary straight from commandline using sudo /bin/bash gridwars-armhf-rel with the result gridwars-armhf-rel: gridwars-armhf-rel: cannot execute binary file.

Just for info
I downloaded the archive from @fluffypillow and put the binary in.
It ran out of the box ....... very slowly. Stuttering sounds and ultra slow graphics.
Missmatch in screen resolution... but I was able to get it run.

I think you are missing a library. After I start the binary I got terminal output

GL2 (with shaders) Active
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: cHRM chunk does not match sRGB
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile

ldd command on gridwars binary reveals

 linux-vdso.so.1 (0x7eb28000)
        /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f68000)
        libGLESv2.so => /opt/vc/lib/libGLESv2.so (0x76f34000)
        libvcos.so => /opt/vc/lib/libvcos.so (0x76f1a000)
        libvchiq_arm.so => /opt/vc/lib/libvchiq_arm.so (0x76f04000)
        libbcm_host.so => /opt/vc/lib/libbcm_host.so (0x76edd000)
        libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76eca000)
        libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76ded000)
        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76d72000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76d45000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76d1d000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76bdc000)
        /lib/ld-linux-armhf.so.3 (0x54b3d000)
        libEGL.so => /opt/vc/lib/libEGL.so (0x76ba2000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76b8b000)