Possible to port GridWars 2

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)

spud11

@cyperghost Thanks. I'll try the binary again and have a look and see what warnings I get. I'm sure you'll be right.

cyperghost

@spud11 I made a screenshot of the game. So you see how the intro looks like. The flares are spreading in all colors but are super slowmo. So that is lightyears away being playable like the video I've posted in 2016. We need hardware acceleration for this and I hope @fluffypillow and @toto2000 can make it run. It's a super cool game I've played long in 2007 during my student time.

Gridwars v 0.1 fluffypillow

toto2000

My idea was to recompile the real sources, not the ones patched by @fluffypillow, and use a real hardware accelerated opengl driver... I'll try tomorrow to compile the original sources with gl4es. Adding this lib (that is a wrapper that mimics openGL and make calls to GLES instead) to LD_LIBRARY_PATH at link time was not enough apparently.

cyperghost

@toto2000 ;) Thx for digging deeper. I'm afraid I can't help furthermore.

My experiences with the GL4ES wrapper were that the introvideos, which for example run in some episodes of OpenBOR, ran without any problems with this library. Without linking, the refresh rate (felt) was below 10fps. The user @zanac used the switch lGL for this purpose. Therefore he patched makefile.txt ... I hope this is also possible with GridWars and that the game can benefit from some accelaration.

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

You can provide the GL4ES wrapper with special options, e.g. that only GLES1.1 is used etc.
The github of ptetSeb with the usage link gives hints. I've patched OpenBOR to not take the library from the /lib directory, but the version in the same directory of the binary.

spud11

@cyperghost Very strangely, when I use ldd gridwars-armhf-rel I get the response not a dynamic executable. I'm really not sure what that means as I copied the binary into the same folder as the other files, and made the binary executable.

mitu

@spud11 Can you run file gridwars-armhf-rel and see if it's an executable ?

spud11

@mitu Thanks, mitu.

What I got was:

gridwars-armhf-rel: ELF 32-bit LSB executable, ARM, EAB15 version 1 (SYSV), dynamically linked, interpreter /lib/id-linux-armhf.so.3,  for GNU/Linux 3.2.0, BuildID[sha1]=b7e8dd092b0a3e8b03642021eb0cee8bca9e80a24, stripped

I've copied that from a photo I took on my home. Hopefully, I've transcribed it correctly.

cyperghost

@spud11 Wrong version of ld-linux-armhf.so.3? - I'm still on Jessie-build!

mitu

@spud11 Looks fine - i.e. it seems an executable.

cyperghost

@mitu Do you know why it fails in this case?