Possible to port GridWars 2
-
@toto2000 not sure but I think
lGL
switch can be used with gl4es -
@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.
-
@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 usingsudo /bin/bash gridwars-armhf-rel
with the resultgridwars-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)
-
@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.
-
@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.
-
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.
-
@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. -
@cyperghost Very strangely, when I use
ldd gridwars-armhf-rel
I get the responsenot 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. -
@spud11 Can you run
file gridwars-armhf-rel
and see if it's an executable ? -
@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.
-
@spud11 Wrong version of
ld-linux-armhf.so.3
? - I'm still on Jessie-build! -
@spud11 Looks fine - i.e. it seems an executable.
-
@mitu Do you know why it fails in this case?
-
Have no idea - @spud11 are you downloading the file and then transferring to the PI ? Can you try downloading it directly on the PI with
wget
:wget https://github.com/mmatyas/GridWars/releases/download/first-build/gridwars-armhf-rel
-
@mitu @cyperghost I'm still on Jessie. Yes, I did transfer from my PC to the pi so I'll use the wget method. Thanks.
-
@mitu @cyperghost. Alright, so I used wget and sudo moved the file to the relevant roms folder and tried running it with ./gridwars-armhf-rel. I got the permission denied error again. I then used
ldd
and got the same response as last time. Using thefile
command, I got the same information as last time. Very odd. Maybe it is something I've done to my system and that is why it just won't work. Or maybe it is the wrong version ofid-linux-armhf.so.3
. -
@spud11 The error
permission denied
is a user right error. I think it's the filesystem - if you are using FAT32 then it's very likely you receive such a message. Try to upload/unpack the archive in directory/home/pi
. Do not use anysudo
command this will overwrite user permission from pi to root.Then use command
chmod +x binaryfilename
to make the binary executable then run the binary with./binaryfilename
no sudo no bash just like I wrote.As ultimate ratio you can use command
sudo chown -R gridwarsdirectory pi:pi
-
@cyperghost Thanks. I wound up putting the files in a sub-folder of my
/home/pi/
folder because, as you said, myroms
folder is on a USB drive. Unfortunately, I still couldn't get it to work. Effectively, I had the same error messages. It's a bit of a pity, but I wonder whether any progress has been made on the porting of it in the meantime by @toto2000.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.