A Hello and small report about GIT and compiling

[Mad_Murphy]

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

[Holger]

Hi, and welcome to the R'n'D forum!

Good to know that you got it to work with SDL2 support -- this indeed does not work out-of-the-box everywhere yet ("make sdl" for using SDL 1.2 should work well for those systems).

Regarding broken tapes: There are currently two problems which may result in broken tapes under the following circumstances:

a) playing tapes in R'n'D 3.3.1.0 or later that have been recorded using R'n'D 3.3.0.1 or earlier which has been compiled on a 64-bit system (see viewtopic.php?f=7&t=2134)

b) playing tapes that have been recorded using F1/F2 quick save/load (see viewtopic.php?f=7&t=2051)

Regarding case (b), I've done countless hours of debugging, but wasn't able to track it down so far (because it is really hard to reproduce).

Regarding case (a), this problem was caused by using the C data type "long", which compiles to 32 bit on 32-bit systems and to 64 bit on 64-bit systems, breaking the tape random number handling, therefore causing broken tapes when changing the environment. (The problem does not occur when using the pre-compiled 32-bit executable on a 64-bit sytem, though.)

The problems caused by (a) should not occur anymore -- the main remaining problem here are tapes recorded with a self-compiled version of R'n'D that is not 64-bit aware (3.3.0.1 and earlier) on a 64-bit system, which may break in later versions. So this is more of a "historic" problem, as it can technically be solved by re-recording affected tapes once using a later (64-bit aware) version. But this is annoying, of course, and it would be good to be able to automatically detect and repair such tapes. I am not sure if this is possible, though.

Looking at what you described, I'm really puzzled that this problem apparently also occurs when not leaving the 32-bit environment at all. Are you really sure that those tapes that do not work with the latest development version from the git repository still play fine when replayed with version 3.3.0.1? Or may it be possible that you ran into problem (b)?

A test you could do is replaying all original BD2K3 tapes (from the 1.0.0 version) using different versions of the game:

- R'n'D 3.3.0.1 using the pre-compiled binary should play them without problems
- R'n'D 3.3.0.1 using a self-compiled binary on a 32-bit system should play them without problems
- R'n'D 3.3.0.1 using a self-compiled binary on a 64-bit system should result in some broken tapes
- R'n'D 3.3.1.0 (pre-compiled, 32-bit compiled or 64-bit compiled) should play them without problems

(Versions 3.3.1.2 and the development version from the git repository should also play them without problems.)

One note here: Tape 010 from this level set will always fail for completely different reason (a bugfix of a severe game engine bug shortly after the release of BD2K3 broke this tape; I *still* have to upload a fixed version of this great game with this tape 010 fixed).

If these tapes behave as described above, I would assume that your tapes were in fact affected by problem (b) instead of problem (a).

If you really still encounter problem (a) on a 32-bit system, I have no idea why at the moment. (I would then try to reproduce this problem by myself using a virtual machine with a 32-bit Linux version.)

[khvolk]

It is easy. But it took me an hour to find the libsmpeg2 library sources:

http://www.libsdl.org/projects/smpeg/re ... 0.0.tar.gz

Hier is the link. I work on an Debian Jessie PC and with the library installed it compiles without stop and works fine.

Yours
Karl-Heinz

[filbo]

I was finally moved to try (harder) to build with libsdl2. My RnD machine is running Ubuntu 12.04 "precise". I installed SDL2 from https://launchpad.net/~zoogie/+archive/ ... -snapshots

... then the build couldn't find libsmpeg2. Well, I could get that from where khvolk said, but -- that version was quite old, and Ubuntu already had files "libsmpeg.so" etc. So I think it's just a naming problem. This was sufficient:

$ sudo 'cd /usr/lib/x86_64-linux-gnu; ln -s libsmpeg.so libsmpeg2.so'

Holger, is this library only "libsmpeg2.so" on your system or is it linked to "libsmpeg.so"? Mine's linked to various other names with versions embedded, eventually ending up at "libsmpeg-0.4.so.0.1.4".

So far:

- scaled zoom is nice
- SDL2 binary plays back levels about 20-30% slower than SDL1.2 (at 100% scale)

A couple of regressions:

- mouse cursor no longer disappears during play (regressed some time before 2015-04-01)
- I used to have a stable of binaries with names like ./rocksndiamonds-20150401 -- this no longer works as it looks for ~/.rocksndiamonds-20150616 etc. So now I have them in bin/20150616/rocksndiamonds, but this is annoying (probably comes from rnd-jue integration)

[Holger]

> My RnD machine is running Ubuntu 12.04 "precise".

This is good to know, as I use exactly the same version (64 bit), so bug reports and test results should be more or less comparable without having to consider distribution differences too much. (Although I use (relatively old) self-compiled SDL2 libraries, which might make a difference here and there.)

> Holger, is this library only "libsmpeg2.so" on your system or is it linked to "libsmpeg.so"? Mine's linked to various other names
> with versions embedded, eventually ending up at "libsmpeg-0.4.so.0.1.4".

I have built both "libsmpeg" and "libsmpeg2" (for SDL_mixer and SDL2_mixer) from source code -- they are not identical (or symlinked against each others), but probably prepared to build against SDL_mixer 1.2.x and SDL2_mixer 2.0.x. Here's how things look like in the library directory after the usual configure/make/install procedure:

Code: Select all

lrwxrwxrwx  1 root root        21 Okt 15  2013 libsmpeg-0.4.so.0 -> libsmpeg-0.4.so.0.1.4
-rwxr-xr-x  1 root root    823696 Okt 15  2013 libsmpeg-0.4.so.0.1.4
-rw-r--r--  1 root root   1444134 Okt 15  2013 libsmpeg.a
-rwxr-xr-x  1 root root       995 Okt 15  2013 libsmpeg.la
lrwxrwxrwx  1 root root        21 Okt 15  2013 libsmpeg.so -> libsmpeg-0.4.so.0.1.4
lrwxrwxrwx  1 root root        22 Nov 30  2013 libsmpeg2-2.0.so.0 -> libsmpeg2-2.0.so.0.0.0
-rwxr-xr-x  1 root root    801780 Nov 30  2013 libsmpeg2-2.0.so.0.0.0
-rw-r--r--  1 root root   1430400 Nov 30  2013 libsmpeg2.a
-rwxr-xr-x  1 root root      1008 Nov 30  2013 libsmpeg2.la
lrwxrwxrwx  1 root root        22 Nov 30  2013 libsmpeg2.so -> libsmpeg2-2.0.so.0.0.0

> - scaled zoom is nice

Yeah, one of the main improvements in R'n'D 4.0.0.0.

> - SDL2 binary plays back levels about 20-30% slower than SDL1.2 (at 100% scale)

This is due to a bug that caused a full screen redraw after each (invisible) game frame instead of only every 50 frames (when the time counter changes). Please do a "git pull", rebuild and try again. I've just executed the following two commands (stripped down to the interesting parts, of course):

Code: Select all

$ make clean && make sdl && time ./rocksndiamonds -e "autoplay BD2K3"
real    6m24.372s
$ make clean && make sdl2 && time ./rocksndiamonds -e "autoplay BD2K3"
real    6m16.826s

> - mouse cursor no longer disappears during play (regressed some time before 2015-04-01)

Wasn't able to reproduce this right now (mouse pointer always disappeared after a second when playing), but I remember some changes/fixes regarding mouse pointer visibility -- could you please retry with the latest git checkout and let me know if it still happens?

> - I used to have a stable of binaries with names like ./rocksndiamonds-20150401 -- this no longer works as it looks for
> ~/.rocksndiamonds-20150616 etc. So now I have them in bin/20150616/rocksndiamonds, but this is annoying (probably
> comes from rnd-jue integration)

Hm, that's right. Maybe I should change this to check for a "<command basename>.conf" file first, and if it does not find any, use "rocksndiamonds" as the "command basename". This would require a config file for all renamed binaries that should get their own personal data directory, which seems fair enough.

[filbo]

> I have built both "libsmpeg" and "libsmpeg2" (for SDL_mixer and SDL2_mixer) from source code --
> they are not identical (or symlinked against each others), but probably prepared to build against
> SDL_mixer 1.2.x and SDL2_mixer 2.0.x.

Ok, so I really am using a bastardized mix right now -- SDL builds with SDL1.2 + libsmpeg 0.4, SDL2 builds with SDL2 + still libsmpeg 0.4.

But wait -- `ldd rocksndiamonds` shows no reference. So I linked a different library to the pathname for libsmpeg2.so, rebuilt, and -- RnD linked successfully. Then I did `nm -DC libsmpeg.so` and grepped all of your source for references -- AFAICT RnD doesn't use libsmpeg at all!

So I edited the Makefile, took out references to -lsmpeg{,2}, and the binaries still built and ran.

With or without that surgery, SDL1 binaries play music (without help from libsmpeg); SDL2 binaries do not. Tested entirely by starting the levels I'm currently playing and hearing, or not hearing, the greeting music. Failing (i.e. SDL2) binaries print these messages:

Code: Select all

rocksndiamonds: warning: cannot read music file '/usr/share/games/rocksndiamonds/levels/Emerald Mine Club/mus_classic_em/music/./em_title.mp3'
rocksndiamonds: warning: cannot load artwork file 'em_title.mp3'

On the other hand, both SDL1 and SDL2 binaries play in-game music (e.g. in the Niko Boehm tutorial levels which it is so easy to fall back into). (SDL2's rendition is much louder for some reason, and I wasn't sure if it was distorted or I just wasn't used to hearing it that loudly...)

> > - SDL2 binary plays back levels about 20-30% slower than SDL1.2 (at 100% scale)

I was referring to drawn playback speed ('551' == "FF" in my recent post). Graphical output is slower. (That said: I ran the -e autoplay BD2K tests and SDL2 was still slower, though by a smaller margin. SDL1: 4m50.058s, SDL2: 5m24.331s, about 12% slower.)

I don't have concrete numbers on the graphical slowness since all measurements are manual. A -e flag to autoplay levels with live display (as mentioned on viewtopic.php?f=7&t=2086) would make this much easier... The main way I compare them is to run two RnD binaries at the same time, go to the same (long-playing) level, hit '55' in each window, then '1' in each window (trying to minimize the amount of time that one gets to free-run ahead of the other). No matter which one gets the head start, the SDL1 window wins. Then I pause SDL2, subtract SDL2's time counter from this level-solution's completion time, and it's 20-30% away from the end.

I had done a `git pull` before my last post; doing it again now, I get no new update.

Likewise with the mouse cursor: the problem does occur with the latest git code.

But I noticed a very important detail I'd missed last time. Mouse cursor does disappear in normal play mode. It doesn't disappear in single-step mode.

A few months ago you fixed this, and it worked in all modes. Then, somewhat more recently, I noticed the feature broke / disappeared. But now I realize it's still working, just not in single-step mode.

Further nuance noticed just now: the cursor does disappear in single-step mode, only to reappear immediately (blinks out for maybe 1/4 second). It blinks out when I hit a playing key (not just motion keys like "left arrow", also other keys like "left ctrl" which advance the game clock without moving me). Then, if I'm hitting keys rapidly, it doesn't blink for the next few keys. After about 2 seconds it is "re-sensitized" and again blinks off for 1/4s when I next hit a key. But if I hit keys very slowly, >2s apart, it winks out for each key.

I see it winks on when I hit space to pause. Single-step is a lot like hitting space to pause immediately after every move; probably the same code path. Turning the cursor on when I pause in the middle of live action seems good; turning it on when auto-paused by single-step mode, not so much.

> Hm, that's right. Maybe I should change this to check for a "<command basename>.conf"
> file first, and if it does not find any, use "rocksndiamonds" as the "command basename".
> This would require a config file for all renamed binaries that should get their own
> personal data directory, which seems fair enough.

Seems fair enough, but ... it's very convenient to be able to run 'rocksndiamonds.old' or whatever, but it would also be convenient to run 'rocksndiamonds-jue.old' and have it also do the right thing. So I'm not sure if it is sufficient to just fall back to "rocksndiamonds".

[Holger]

> But wait -- `ldd rocksndiamonds` shows no reference. So I linked a different library to the pathname for libsmpeg2.so,
> rebuilt, and -- RnD linked successfully. Then I did `nm -DC libsmpeg.so` and grepped all of your source for references --
> AFAICT RnD doesn't use libsmpeg at all!

I was never really aware of this, but apparently you're right!

I think that SDL2_mixer dynamically uses the smpeg library, so there is no direct reference in R'n'D. (The same seems to be true for libpng etc., which are also dynamically used by SDL2_image, but not directly linked into R'n'D.)

So I think I should clean up my Makefile...

Regarding problems with MP3 playback when using the SDL2 libs, I have no idea what's wrong (MP3s play fine here), but I have the suspicion that it has something to do with your libsmpeg2 being symlinked to libsmpeg.

> > - SDL2 binary plays back levels about 20-30% slower than SDL1.2 (at 100% scale)
>
> I was referring to drawn playback speed ('551' == "FF" in my recent post). Graphical output is slower. (That said: I ran the
> -e autoplay BD2K tests and SDL2 was still slower, though by a smaller margin. SDL1: 4m50.058s, SDL2: 5m24.331s, about
> 12% slower.)

Sorry, I misunderstood you here. OK.

This should now be easier to test with the new "autoffwd" feature (see different post, or see "--help" with latest version).

I think that graphics output is slower now because of the additional scaling layer (every blit is now sent through a scaling function on the GPU). The speed difference may vary with graphics performance. I for myself have a very poor graphics setup (onboard graphics), so this might slow thing down more than with a "real" GPU. In addition, the new SDL2 drawing code in R'n'D might not be fully optimized yet. (Besides that, it's far from being optimized anyway, as it does all rendering in software and not on the GPU, because it does not redraw each frame from scratch, but works by modifying the last screen frame here and there, which cannot be done on the GPU, as reading from GPU hardware memory is slow. This would require a major rewrite of all graphics and screen drawing operations, which will not happen anytime soon.)

> I had done a `git pull` before my last post; doing it again now, I get no new update.

Sorry again, I thought you might have used a slightly older code base, as I did the last "git push" only a short time before writing the post.

> Likewise with the mouse cursor: the problem does occur with the latest git code.

This should also be fixed now with the latest version.

> Seems fair enough, but ... it's very convenient to be able to run 'rocksndiamonds.old' or whatever, but it would also be
> convenient to run 'rocksndiamonds-jue.old' and have it also do the right thing. So I'm not sure if it is sufficient to just fall
> back to "rocksndiamonds".

You're right here. I'm already thinking about an alternative solution for this problem...

[Holger]

> > Seems fair enough, but ... it's very convenient to be able to run 'rocksndiamonds.old' or whatever, but it would also be
> > convenient to run 'rocksndiamonds-jue.old' and have it also do the right thing. So I'm not sure if it is sufficient to just fall
> > back to "rocksndiamonds".
>
> You're right here. I'm already thinking about an alternative solution for this problem...

The current Git repo contains a fix for this, which cuts off a trailing suffix like ".old" or "-20151026" (separated by either a "." or a "-") and then uses the correct data directory ("~/.rocksndiamonds" for these two examples).

To still be able to use something like "rocksndiamonds-jue", it also looks for a "special edition" config file like "rocksndiamonds-jue.conf". If a file like this is found in the same directory as the binary, it is assumed that "rocksndiamonds-jue" is the correct program basename, and not just "rocksndiamonds". Correctly detecting and handling of your example "rocksndiamonds-jue.old" still does not work, though, so a special edition which uses a different basename than "rocksndiamonds" should make sure not to use a "." or "-" in that basename, meaning that it would have to be "rocksndiamonds_jue" instead of "rocksndiamonds-jue", for example. Then it should all work fine.