BUILDING under Ubuntu 12.04:
$ git clone
http://git.artsoft.org/rocksndiamonds.git
$ cd rocksndiamonds/src
$ make TARGET=sdl RO_GAME_DIR=/usr/share/games/rocksndiamonds RW_GAME_DIR=/var/games/rocksndiamonds
TARGET=sdl because otherwise it assumes sdl2, and Ubuntu 12.04 doesn't have that.
RO_GAME_DIR=/usr/share/games/rocksndiamonds and RW_GAME_DIR=/var/games/rocksndiamonds to match the locations used by the Debian / Ubuntu packaging folks.
It's more convenient for me to put those definitions into Makefile itself; but I don't like to have local (never intended to be submitted) modifications vs. the git master.
==========
> The current version uses the same graphic files as release version 3.3.1.2, but in PNG format instead of PCX format. Therefore, please just convert all PCX files in folder "graphics/gfx_classic" from PCX to PNG.
This worked for me:
$ sudo sh -c '
RO_GAME_DIR=/usr/share/games/rocksndiamonds # same as I build with, same as Debian / Ubuntu packaging
cd $RO_GAME_DIR/graphics/gfx_classic
for image in *.pcx; do
image2=${image%.pcx}.png
[ ! -f $image2 ] && convert $image $image2
done
mv rocks_icon_32x32.png RocksIcon32x32.png # Name changed in source?
'
I actually got on here to complain that this would make it difficult for RnD 3.x and 4.x to coexist on the same system; but of course it does not, because both sets of files may exist in the same directory structure without bothering anything.
OTOH, it seems like it would be better if the source asked for these files without giving an extension. Then a lower level utility function would either sequentially try "asked-for.png", "asked-for.pcx", ...; or use directory search functions to ask "what asked-for.* files exist"; then pick the most desirable extension found in the results.
==========
A few behavior observations:
1. "quick doors" setting is broken. I have it turned on; in 3.3.1.2 this makes menu "door" operations instantaneous. 4.0, whether on or off, opens/closes menu doors at what looks like the same speed as 3.3.1.2 with "quick doors" off.
2. The first time I tried to play back a saved tape from 3.3.1.2, I died. I believe I tried to run the tape twice and died both times. So I moved on to another level, which worked fine; went back to the first level, it worked fine; exited, ran it again, it still worked fine. Weird.
AHA! I got this to reproduce again; but in the process, also reproduced exactly the same behavior on 3.3.1.2! Same level, same tape, same death. So it's a bug but not a regression between 3.3.1.2 and 4.0.0-git-today.
REPRODUCING IT: it seems to have to do with the pick-a-level menu. I'm in a levelset ("levels/Emerald Mine Club/emc_amiga_mine_02") for which I have a partial set of tapes (levels 0..34). Procedure:
A. Start RnD (3.3.1.2 or 4.0)
B. If necessary, change level number to a level for which you have a level-winning save tape, quit, and restart.
C. Play your tape (Play button, Eject button = "Warp Forward"); observe success.
D. Click on the level number (between the up/down arrows) to get the menu of available levels. Click on a different level for which you have a level-winning save tape.
E. Play your tape (Play button, Eject button = "Warp Forward"); possibly observe failure.
F. If success, repeat steps D/E for various other levels.
In my experience so far, if you click back to the level which came up active when you started the game, it will succeed. Other levels are hit and miss, but each time you try the same level during a particular session (where "session" includes just steps A-F above; e.g. no changing between levelsets), that level's success or failure is the same.
AH, further refinement:
Whatever the game is STARTED on a particular level; OR you use the left-right arrows to go up- or down-levels to that level; then initial conditions are set up so that level's tape will work.
Whenever you click the numbers in the middle and choose a level from that menu; then initial conditions are not changed from the level on which the game was started (or the last level that was up/down-arrowed to). Therefore if the level you chose from that menu was the same number as started on or arrowed to, the tape will work; otherwise it probably won't (but sometimes will).
Obviously some initialization step is missed when clicking on the choose-a-level menu vs. up/down-arrowing.
3. I noticed a bunch of ancient (but sensible looking) entries added to ChangeLog. Ok -- but perhaps there should be a modern entry like "Added some old lost items back into ChangeLog" :)