RnD to GitHub?
Moderators: Flumminator, Zomis
RnD to GitHub?
Considering RnD is already open-source, I believe it would be good if RnD had a git repository on GitHub.
For those of you who does not know git, it is currently the most used version-control-system among programmers. It is easy to create branches, merge, and collaborate on creating the software.
Of course, this decision is basically up to Holger, the man in charge. I personally think that it would only lead to good things if RnD was on GitHub.
For those of you who does not know git, it is currently the most used version-control-system among programmers. It is easy to create branches, merge, and collaborate on creating the software.
Of course, this decision is basically up to Holger, the man in charge. I personally think that it would only lead to good things if RnD was on GitHub.
Re: RnD to GitHub?
Hi Zomis,
yes, a git repository for R'n'D would indeed be fine. The funny thing is that I just started diving into git some days ago, to do exactly that: Start a git repository for R'n'D. I think it will be available very soon, and it may be complemented by automatically created nightly builds, at least for the Windows platform.
I'll keep you updated how things are going in this regard.![Smile :-)](./images/smilies/icon_smile.gif)
yes, a git repository for R'n'D would indeed be fine. The funny thing is that I just started diving into git some days ago, to do exactly that: Start a git repository for R'n'D. I think it will be available very soon, and it may be complemented by automatically created nightly builds, at least for the Windows platform.
I'll keep you updated how things are going in this regard.
![Smile :-)](./images/smilies/icon_smile.gif)
Re: RnD to GitHub?
As announced, the latest and greatest version of the R'n'D source code is now available via Git! ![Smile :-)](./images/smilies/icon_smile.gif)
(I decided to use a repository on my own server instead of GitHub though, although the latter offers some nice features that git.artsoft.org does not have. It's just a plain and simple Git repository now.)
![Smile :-)](./images/smilies/icon_smile.gif)
(I decided to use a repository on my own server instead of GitHub though, although the latter offers some nice features that git.artsoft.org does not have. It's just a plain and simple Git repository now.)
Re: RnD to GitHub?
$ git clone git://git.artsoft.org/
Cloning into 'git.artsoft.org'...
fatal: unable to connect to git.artsoft.org:
git.artsoft.org[0: 5.28.40.12]: errno=Connection refused
Cloning into 'git.artsoft.org'...
fatal: unable to connect to git.artsoft.org:
git.artsoft.org[0: 5.28.40.12]: errno=Connection refused
Re: RnD to GitHub?
Hmmm, helps to rtfm. But would also have helped to have a pointer to fm :)
Re: RnD to GitHub?
That pointer, of course, is viewtopic.php?f=2&t=2145.
My problem was assuming that Holger had set up the git:// protocol when in fact he is using only the HTTP transport mode of git.
As I cannot comment on the announcement thread:
> maybe support for the relatively outdated SDL version 1.2.x will be dropped soon.
FWIW, most of my household systems are running slightly out of date Ubuntu releases like 12.04 LTS. These do not have SDL2 available in their repositories; though I'm pretty sure I could find a PPA (Personal Package Archive) for it, or build it myself. Still, this would make it annoying to bring up RnD on many systems which are not all that obsolete. Even dropping direct X11 support seems a bit bold to me... [I fully support dropping archaic MS-DOS support :) ]
My problem was assuming that Holger had set up the git:// protocol when in fact he is using only the HTTP transport mode of git.
As I cannot comment on the announcement thread:
> maybe support for the relatively outdated SDL version 1.2.x will be dropped soon.
FWIW, most of my household systems are running slightly out of date Ubuntu releases like 12.04 LTS. These do not have SDL2 available in their repositories; though I'm pretty sure I could find a PPA (Personal Package Archive) for it, or build it myself. Still, this would make it annoying to bring up RnD on many systems which are not all that obsolete. Even dropping direct X11 support seems a bit bold to me... [I fully support dropping archaic MS-DOS support :) ]
Re: RnD to GitHub?
Regarding X11/SDL/SDL2 support of R'n'D:
I'm also happily running Ubuntu 12.04 LTS, and I know that it does not offer the SDL2 libraries out of the box without external PPAs. As long as SDL2 isn't widely spread among common Linux distributions, I probably won't drop SDL support. Although I think I could safely do it if I would ship a Linux binary statically linked against SDL2 that would run on most platforms. At least those who build from development sources would most probably prefer to use self-compiled (or installed from a PPA) SDL2 libraries anyway, I think.
About dropping X11 support, I think adding support for SDL2 was just about the right time to drop X11 support. In fact, I did not do it lightheartly, as it was the base of R'n'D being able to build/run virtually everywhere. On the other hand, the X11 target really lacked too many of the features that I think should be available to it: Support for MOD/MP3/MIDI music, fullscreen support, support for non-historic image formats. For example, I wanted to switch to using (or at least supporting) PNG images for a long time now, but this would have required to integrate a PNG loader only for the X11 target. (Of course, it could have been added by some open source code or just using libpng, but it still would have to be done and maintained, and would probably add additional library dependencies to plain libX11, too.) The same is true for things like joystick support -- doing it natively means adding lots of extra code to support the different ways of joystick handling on LInux, FreeBSD etc., while SDL already handles this for a variety of platforms out of the box. Continuing to support the X11 build target would effectively mean to either re-implement large parts of the SDL library, or to keep all the limitations and accept that it also massively affects the SDL/SDL2 targets (like supporting only the PCX format for loading images). Therefore, dropping the native X11 target means a lot less old code to maintain, focussing my limited time to tasks that seem to be much more worthwhile.
I'm also happily running Ubuntu 12.04 LTS, and I know that it does not offer the SDL2 libraries out of the box without external PPAs. As long as SDL2 isn't widely spread among common Linux distributions, I probably won't drop SDL support. Although I think I could safely do it if I would ship a Linux binary statically linked against SDL2 that would run on most platforms. At least those who build from development sources would most probably prefer to use self-compiled (or installed from a PPA) SDL2 libraries anyway, I think.
About dropping X11 support, I think adding support for SDL2 was just about the right time to drop X11 support. In fact, I did not do it lightheartly, as it was the base of R'n'D being able to build/run virtually everywhere. On the other hand, the X11 target really lacked too many of the features that I think should be available to it: Support for MOD/MP3/MIDI music, fullscreen support, support for non-historic image formats. For example, I wanted to switch to using (or at least supporting) PNG images for a long time now, but this would have required to integrate a PNG loader only for the X11 target. (Of course, it could have been added by some open source code or just using libpng, but it still would have to be done and maintained, and would probably add additional library dependencies to plain libX11, too.) The same is true for things like joystick support -- doing it natively means adding lots of extra code to support the different ways of joystick handling on LInux, FreeBSD etc., while SDL already handles this for a variety of platforms out of the box. Continuing to support the X11 build target would effectively mean to either re-implement large parts of the SDL library, or to keep all the limitations and accept that it also massively affects the SDL/SDL2 targets (like supporting only the PCX format for loading images). Therefore, dropping the native X11 target means a lot less old code to maintain, focussing my limited time to tasks that seem to be much more worthwhile.
Re: RnD to GitHub?
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" :)
$ 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" :)
Re: RnD to GitHub?
The above, i.e. viewtopic.php?f=3&t=2128&p=13269#p13268 or a copy stashed somewhere, is a FAQ-answer ("how can you have dropped X11 support?!??") you'll probably want to stash somewhere. :)
Re: RnD to GitHub?
If I was more observant, I would have noticed the "wrong initial state" problem was because it wasn't loading the new level's tape! Easily visible in the tape controls, once you realize...
This fixes it. There's another `level_nr = atoi(level_number_current->identifier);' higher up in HandleChooseTree() -- I couldn't figure out how to get to that code, so I couldn't test if it had the same problem.
This fixes it. There's another `level_nr = atoi(level_number_current->identifier);' higher up in HandleChooseTree() -- I couldn't figure out how to get to that code, so I couldn't test if it had the same problem.
Code: Select all
$ diff --git a/src/screens.c b/src/screens.c
index 61cb710..49daf2e 100644
--- a/src/screens.c
+++ b/src/screens.c
@@ -1629,12 +1629,15 @@ void HandleTitleScreen(int mx, int my, int dx, int dy, int button)
}
}
+// `direction == 0' means jump to absolute level number `step'
void HandleMainMenu_SelectLevel(int step, int direction)
{
int old_level_nr = level_nr;
int new_level_nr;
new_level_nr = old_level_nr + step * direction;
+ if (direction == 0)
+ new_level_nr = step;
if (new_level_nr < leveldir_current->first_level)
new_level_nr = leveldir_current->first_level;
if (new_level_nr > leveldir_current->last_level)
@@ -1643,7 +1646,7 @@ void HandleMainMenu_SelectLevel(int step, int direction)
if (setup.handicap && new_level_nr > leveldir_current->handicap_level)
{
/* skipping levels is only allowed when trying to skip single level */
- if (setup.skip_levels && step == 1 &&
+ if (setup.skip_levels && new_level_nr == old_level_nr + 1 &&
Request("Level still unsolved! Skip despite handicap?", REQ_ASK))
{
leveldir_current->handicap_level++;
@@ -3623,7 +3626,7 @@ static void HandleChooseTree(int mx, int my, int dx, int dy, int button,
else
{
if (game_status == GAME_MODE_LEVELNR)
- level_nr = atoi(level_number_current->identifier);
+ HandleMainMenu_SelectLevel(atoi(level_number_current->identifier), 0);
game_status = GAME_MODE_MAIN;
Re: RnD to GitHub?
Hmmm, trying to repost that with the diff as an attachment (to preserve TABs). No luck -- extension ".dif" not allowed. Ok, how about ".txt"? Nope. Nor ".diff" or ".patch" or even no-extension-at-all. I don't want to lie and claim it's a .png or whatever.
... ok, here is "foo.zip" which is an actual zip file of the 1.4K diff file...
... ok, here is "foo.zip" which is an actual zip file of the 1.4K diff file...
- Attachments
-
- foo.zip
- (773 Bytes) Downloaded 552 times
Re: RnD to GitHub?
I just did a `git pull` for the first time since the above, and noticed that the last bug I mentioned (and supplied a patch for) isn't fixed.
So, just want to make sure you noticed. Bug is that if you click on the level number (between the arrows) and then on a particular level, the tape for that level is not loaded. The previously loaded level's tape remains; therefore if you hit 'play' you act silly and probably die.
So, just want to make sure you noticed. Bug is that if you click on the level number (between the arrows) and then on a particular level, the tape for that level is not loaded. The previously loaded level's tape remains; therefore if you hit 'play' you act silly and probably die.
Re: RnD to GitHub?
Hmmm, I think I should be clearer.
I assume that you probably have 400 other things to do and simply haven't gotten to that patch, especially since the patch isn't quite right and you'll have to do some work to fix it properly.
I just want to make sure that you didn't somehow miss it completely. As a matter of good process, if you had said "I see, I will get to that" -- or any such "ACK" signal -- I wouldn't be here asking about it.
Thanks,
>Bela<
I assume that you probably have 400 other things to do and simply haven't gotten to that patch, especially since the patch isn't quite right and you'll have to do some work to fix it properly.
I just want to make sure that you didn't somehow miss it completely. As a matter of good process, if you had said "I see, I will get to that" -- or any such "ACK" signal -- I wouldn't be here asking about it.
Thanks,
>Bela<
Re: RnD to GitHub?
You're perfectly right to bump this topic again! Yes, I have seen it, haven't missed it or forgot about it, and indeed want to fix that bug a little bit differently (although your patch would technically fix it perfectly), but just missed to write some reply to let you know that it's on my agenda. Sorry for that! :-/
It's really time for an issue tracker now, to track all those bugs (and also feature requests) with a status and possibly progress information etc.. At the moment, I have a browser window with lots of forum tabs open, but that's no solution.![Smile :-)](./images/smilies/icon_smile.gif)
I'm just not sure at the moment if I should use Mantis or Bugzilla for the R'n'D issue tracker. (I had Mantis before, but never really used it -- that should be different this time, as R'n'D really needs a decent way to handle all those issues reported here.)
Both Mantis and Bugzilla would be more than powerful enough for the simple requirements of issue tracking for R'n'D... I tend to prefer Mantis for its simplicity, but it really looks ugly, which puts me off at the moment, thinking about using Bugzilla instead, maybe...
It's really time for an issue tracker now, to track all those bugs (and also feature requests) with a status and possibly progress information etc.. At the moment, I have a browser window with lots of forum tabs open, but that's no solution.
![Smile :-)](./images/smilies/icon_smile.gif)
I'm just not sure at the moment if I should use Mantis or Bugzilla for the R'n'D issue tracker. (I had Mantis before, but never really used it -- that should be different this time, as R'n'D really needs a decent way to handle all those issues reported here.)
Both Mantis and Bugzilla would be more than powerful enough for the simple requirements of issue tracking for R'n'D... I tend to prefer Mantis for its simplicity, but it really looks ugly, which puts me off at the moment, thinking about using Bugzilla instead, maybe...
Re: RnD to GitHub?
FWIW, I have used several different instances of bugzilla at various jobs as well as with open source; AFAIK, have not seen mantis. And I plan to dump something like 20 bugs in, once you create a tracker, so I'm sort of a "big customer" :)
Every bug tracker I've ever seen sucks. Bugzilla does not excel at sucking -- that is, it's pretty good out of a pack of not-great choices.
BTW, forum bug: I have smilies disabled, and this reflects below where it says "[x] Disable smilies"; but not on the right, where it says "Smilies are ON".
Every bug tracker I've ever seen sucks. Bugzilla does not excel at sucking -- that is, it's pretty good out of a pack of not-great choices.
BTW, forum bug: I have smilies disabled, and this reflects below where it says "[x] Disable smilies"; but not on the right, where it says "Smilies are ON".