Head over Heels from 2003 - Would it work on Retropie?

George Spiggott

@duglor There was also a remake for the Amiga, Atari ST and Jaguar, the emulator for which recently got a bunch of improvements.

duglor

@George-Spiggott yes and i saw even a remake for msx2. The thing is i think these games are only for sale via cartridge.

George Spiggott

@duglor The Amiga version came out in the early 90s, I had a copy for my real Amiga. I'm sure there will be a WHDLoad for it.

Folly

@duglor said in Head over Heels from 2003 - Would it work on Retropie?:

@duglor
So i don't know if one version is too old for retropie and the other is too new!!!!!

The question- can it be done?

I tried to make a module-script for it.
However I cannot get it to work.
This is due to the code which gives multiple errors when trying to compile.
I had to find the correct old "xerces-c" sourcecode also.
For reference, this is what I already made :

rp_module_id="headoverheels2"
rp_module_desc="Head over heels 2"
rp_module_licence=""
rp_module_section="exp"
rp_module_flags=""


function depends_headoverheels2() {
    getDepends xorg matchbox-window-manager liballegro4-dev libvorbis-dev libxerces-c-dev
}

function sources_headoverheels2() {
    downloadAndExtract "http://www.headoverheels2.com/descargas/headoverheels-1.0.1.tar.bz2" "$md_build"
    #latest(doesn't work)#downloadAndExtract "https://github.com/apache/xerces-c/archive/refs/heads/master.zip" "$md_build"
    downloadAndExtract "http://archive.apache.org/dist/xml/xerces-c/xerces-c-current.tar.gz" "$md_build"
    
    ln -s "$md_build/xerces-c-src_2_7_0/src/xercesc" "$md_build/headoverheels-1.0.1/src/xercesc" 
}

function build_headoverheels2() {
    cd "$md_build/headoverheels-1.0.1"
    ./configure
    make
}

Compilation will break on :.

/xsd/cxx/zc-istream.txx:34:12: error: ‘setg’ was not declared in this scope

I tried to fix this by changing the code in zc-istream.txx from

setg (b, b, e);

to

std::streambuf::setg (b, b, e);

After this change compiling got further but now there are many undefined reference to errors.

I am not a c++ programmer so basically I am stuck now.

The code is probably too old.

Perhaps someone else, with more knowledge, can have a look.

duglor

@Folly Thanks a bunch for trying to compile something. Much appreciated. Yes, I hope someone else chimes in with the ability to complete this little task!!!

mitu

@Folly said in Head over Heels from 2003 - Would it work on Retropie?:

The code is probably too old.

Probably. There's a more modern fork at https://github.com/dougmencken/HeadOverHeels that you can try.

Folly

@mitu

Thanks;-)

I tried the linux-build.sh
I also had to install libtinyxml2-dev to please configure.
Compiling of HOH stops at the end of configurewith the last line saying "syntax error: unexpected end of file" and no makefile found.
So sadly, not working on my pi4 with bullseye yet.

duglor

@Folly Thanks for trying, Folly

Folly

@mitu @duglor

Trying now to compile on my x86-32 debian buster VM.

I have made some progress and found a couple of issues in the configure.ac

configure.ac contains some "else if" functions that should be "elif" (changing it will now make a better configure script which make a proper Makefile and so it can compile)
configure seems to wrongly detect which allegro (4 or 5) to use (this detection takes place in the same "elif" lines)
~~after compiling the gamedata is searched in the wrong directory and needs to be copied to the correct directory~~ ( run the game from the _rootdir directory and everything should be in place
linux-build.sh configures configure to compile without allegro (it probably then tries to use the installed liballegro4-dev or liballegro5-dev that is installed as depandancy)
depending on the different tries on different computers an os'es , headoverheals will give errors when trying to run :
- "segmentation fault" on allegro5 (on my x86-32 buster)
- "Shutting down Allegro due to signal #11" "segmentation fault" (on my x86-32 buster forcing "--with-allegro4")
- same sort of issues on pi4 with raspberry pi os (bullseye)

Edit :
Looks like I am close though sadly no dice.
I will stop trying, for now.

Have added an issue to the repository :
https://github.com/dougmencken/HeadOverHeels/issues/39

Lolonois

Thanks for bringing this gem to my attention.

Just stopping by to note that I overhauled the linux-build.sh script from Doug's repo and destilled a RetroPie scriptmodule of it.

Find it here [1]

Tested on a Rpi4 and Rpi3. Game starts with audio and navigation works in the menu before starting a game. Game can be started. However, when in game the keyboard actions are no longer recognized. (Use for example killall xinit to return to EmulationStation).

In contrast: The same build commands create a fully playable game on a x64 (Debian Bullseye) in X11.

Tested with the bundled allegro lib 4.4.3.1 as well as the 4.4.2.1 from Buster. But result was the same. (Bullseye on Desktop provides 4.4.3.1).
Tested also Allegro 5 (add liballegro5-dev to the dependencies and add --with-allegro5 to the cmake command, FWIW) but with allegro 5 the keyboard is not detected from the beginning.

I assume it is related to either the allegro engine or the game itself that the keyboard presses working before are no longer recognized in the game. But I did not dig into it yet.

Question: Maybe you guys have additional hints for the cause/debugging tips?

[1] https://gist.github.com/Gemba/f2c541f6e027d7278e948f80e311e318

mitu

@Lolonois said in Head over Heels from 2003 - Would it work on Retropie?:

Tested on a Rpi4 and Rpi3. Game starts with audio and navigation works in the menu before starting a game. Game can be started. However, when in game the keyboard actions are no longer recognized. (Use for example killall xinit to return to EmulationStation).

Could be a focus issue due to the lack of a window manager. Configure the port launch command with XINIT: and runcommand will take care of starting X, a window manager and disable any screen blanking. See how steamlink is configured for an example.

Lolonois

@mitu Thanks would have been an quick win but unfortunately it does not solve the issue when I adapt the matchbox-window-manager & line before. I did use the XINIT: keyword already.

Also I should add that when running the game from within Pixel/lxde at a Pi the result is the same: Game starts, menu navigation with keyboard ok, in game no keyboard.

Edit:
Found a reference which may explain the issue: https://www.allegro.cc/manual/4/api/keyboard-routines/install_keyboard

Folly

@Lolonois

Nice to see that it can work somehow.
Just wanted to let you know what I tested, what works and what doesn't, yet.

I tried your module-script and got these results :

Imac-I5_bullseye_x86_64bits+desktop -> compiles and loads, game is playable, quitting the game doesn't work (have to open a new terminal and do "pkill headoverheals" and get back to the desktop, desktop is then in low resolution
pi4_bullseye_32bits+desktop -> compiles and loads, no keyboard anymore after selecting "new game"
VMware_bullseye_x86_64bits+desktop -> doesn't compile

Lolonois

@Folly Thanks for trying out. Some more observations I made so far:

After I was out of options for allegro4 I tried again the allegro5 build: And to my surprise it works. =B-) I most likely was too impatient on the Rpi3 as it is non-performant (the game not the Rpi3), and I assumed I was stuck in the Language selection screen. Plus I had to set the video mode in the Runcommand menu to 640x480.

The contrast between the allegro4 and allegro5 build is stark: When idling in the first room load is approx 4x higher with the allegro5 build. I guess because the allegro5 implementation is still work in progress, respective the lags are not detectable on a desktop system thus were not noticed by Doug, but get apparent on a Rpi4 and Rpi3.

Long story short: It boils down to an optimization issue of the game with allegro5, which is more easily to remediate as the "no keyboard" with the allegro4 build (and dealing with the "dead horse" allegro4 anyway). Will update my Gist soon.

Re: Your observations

I have no stakes on a Mac but usually it is pressing M within the game then Esc should bring you back to the Gui Menu from where you can exit.
See above. Thanks for verifying that it was not only my machine/setup.
Vmware build: Was is the build error?

Folly

@Lolonois said in Head over Heels from 2003 - Would it work on Retropie?:

Re: Your observations

I have no stakes on a Mac but usually it is pressing M within the game then Esc should bring you back to the Gui Menu from where you can exit.

Works for me.
Might be a good idea to change m into esc :

<pause>esc</pause>

Seem to work just fine, what do you think ?

See above. Thanks for verifying that it was not only my machine/setup.

I am indeed curious on how it reacts on different setups so we can learn from it and perhaps improve some things along the way.

Vmware build: Was is the build error?

I have put the log on my github :
https://github.com/FollyMaddy/headoverheals-compilation-stuff/blob/main/rps_2023-03-16_104412.log.gz

Lolonois

@Folly changed the M to Esc. It is more intuitive, thanks. For the vmware build error: I have noticed the output of LT_INIT: command not found. Could you add libtool to the dependencies (depends_hoh()) and retry?

Folly

@Lolonois

Adding libtool did the trick.
You should definitely add it to the depends.

Everything works except the sound has some hick-ups.

duglor

@Folly @Lolonois Does this mean it should be/could be/ will be/might be added to anyone who wants it, their pi? or should we/anyone wait for sound improvement or no it should not be used?

Folly

@duglor

Not to be rude or anything but all the information is in the posts ;-).

Summarised (using debian 11 (or 10)):

headoverheels doesn't work yet on the pi using allegro4 (starts in menu and can be controlled but has an issue not being able to control/play the game) (sound is ok)
headoverheels does work on the a normal x86_64 pc using allegro4 (sound is ok)
headoverheels does work on my virtual x86_64 machine using allegro4 (but has issue with sound that does have some hick-ups)
@Lolonois is busy trying to update the module-script and use allegro5 and test that (hopefully it will solve the problems and using it could make the game run faster)

Lolonois

@Folly Thanks for validating this. As I learned from your other post the audio issue happens on x64 with liballeg4 and not on arm/Raspberry Pi.