Possible to port GridWars 2

herb_fargus

@spud11 at least in my experience with it it would start to run and then quickly crash. I wouldn't consider it playable on its current state on the pi

fluffypillow

@spud11 If I remember correctly, you have to clone/download the git repo ("Source code" on the releases page is fine too), as that contains the game assets. Then download the binary, place it into this directory and run. Shouldn't need to compile anything, the binary on that page is already compiled for you. But I can take a look tomorrow if it still fails.

spud11

@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.

mitu

@spud11 Which folder have you copied into ? Looks like an error related to the filesystem mount options, usually you get this when the filesystem is mounted with the noexec option.

spud11

@mitu Seems a bit strange because I haven't used noexec option anywhere. All files appear in the /home/pi/RetroPie/roms/gridwars2 folder that I have created and I'm just trying to start the file from commandline.

mitu

@spud11 Have you made the file executable (chmod +x gridwards-armhf-rel) ? Note that you should run it via ./gridwars-armhf-rel, not with sudo bash ....

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.