A Hello and small report about GIT and compiling
Posted: Thu Nov 20, 2014 2:29 pm
Hello all,
this is a first post, so the usual things first.
I'm playing regulary with RND since the 90's, i enjoy the game, its definitely my favourite. (Insert many thanks and good wishes and everything related here)
I just want to report a few things more:
Earlier, i used the pre-build binaries but since years i'm compiling from source which mostly works well. I'm on plain Debian Jessie 32 Bit.
When the Git repo became accesseable to the public i tried to use it, to see the forthcoming of developement. First try then gave me some problems with SDL2. SDL1.2 worked well. The Debian package sources didn't had all the requiered stuff. This has changed now, so a few days ago i managed to compile the game.
One thing was missed, the compilation process stopped. complaining about smeg which i couldnt find in the official Debian packages. i got the sources for smpeg-2-2.0.0, compiled them first, did a ldconfig and was able to compile the game as it should be.
In short: SDL2, original from Debian packages and smpeg from source worked for me to compile the Git Game-Version.
I'm now playing with that version and what i see so far works great. Especially the small-tile display looks impressive. Currently i can't report problems there, it just works.
But one last thing, which is somewhat related to this topic: viewtopic.php?f=7&t=2134 : (Tapes created in 3.3.0.1 (AMD64) misfire in 3.3.1.2). I had similar problems, mostly with Supaplex tapes. The exception is that i'm on a 32-Bit Debian (not 64-Bit). When playing this tapes in above mentioned but 32-Bit versions of the game, Murphy goes mad after a few or a few more seconds of replay. He just starts to move irregular which obvisiously leads to broken records immeadeatly. No fun.
That tapes keep their behaviour on the latest Git compiled game-version here. Maybe there are other tapes from other levelsets which are broken too, but i didnt tested so far.
That leads to my conclusion for the other above mentioned threat, that there are not only 32-64-Bit related problems, but maybe others in different code parts which lead to broken tapes.
Andy
this is a first post, so the usual things first.
I'm playing regulary with RND since the 90's, i enjoy the game, its definitely my favourite. (Insert many thanks and good wishes and everything related here)
I just want to report a few things more:
Earlier, i used the pre-build binaries but since years i'm compiling from source which mostly works well. I'm on plain Debian Jessie 32 Bit.
When the Git repo became accesseable to the public i tried to use it, to see the forthcoming of developement. First try then gave me some problems with SDL2. SDL1.2 worked well. The Debian package sources didn't had all the requiered stuff. This has changed now, so a few days ago i managed to compile the game.
One thing was missed, the compilation process stopped. complaining about smeg which i couldnt find in the official Debian packages. i got the sources for smpeg-2-2.0.0, compiled them first, did a ldconfig and was able to compile the game as it should be.
In short: SDL2, original from Debian packages and smpeg from source worked for me to compile the Git Game-Version.
I'm now playing with that version and what i see so far works great. Especially the small-tile display looks impressive. Currently i can't report problems there, it just works.
But one last thing, which is somewhat related to this topic: viewtopic.php?f=7&t=2134 : (Tapes created in 3.3.0.1 (AMD64) misfire in 3.3.1.2). I had similar problems, mostly with Supaplex tapes. The exception is that i'm on a 32-Bit Debian (not 64-Bit). When playing this tapes in above mentioned but 32-Bit versions of the game, Murphy goes mad after a few or a few more seconds of replay. He just starts to move irregular which obvisiously leads to broken records immeadeatly. No fun.
That tapes keep their behaviour on the latest Git compiled game-version here. Maybe there are other tapes from other levelsets which are broken too, but i didnt tested so far.
That leads to my conclusion for the other above mentioned threat, that there are not only 32-64-Bit related problems, but maybe others in different code parts which lead to broken tapes.
Andy