Haiku port

Discussion around programming R'n'D, its source code and its tools.

Moderators: Zomis, Flumminator

Post Reply
Begasus
Posts: 5
Joined: Thu Mar 16, 2017 7:58 am

Haiku port

Post by Begasus » Thu Mar 16, 2017 10:58 am

As said in my introduction I am working on getting Rocks'n'Diamonds up to par for Haiku, but having a few issues (no deal breakers though)

RocksnDiamonds: warning: cannot open configuration file '/boot/home/.RocksnDiamonds/setup.conf'
RocksnDiamonds: warning: using default setup values
RocksnDiamonds: warning: configuration file '/boot/home/.RocksnDiamonds/cache/artworkinfo.cache' is empty
RocksnDiamonds: warning: cannot open configuration file '/boot/home/.RocksnDiamonds/editorcascade.conf'
RocksnDiamonds: warning: cannot open configuration file '/boot/home/.RocksnDiamonds/editorsetup.conf'

Any ideas on weather these should be created or not?

Also RW_GAME_DIR=$settingsDir/rocksndiamonds ... can't seem to bypass the config files being created in ~/ (/boot/home)

User avatar
Holger
Site Admin
Posts: 3225
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Haiku port

Post by Holger » Thu Mar 16, 2017 12:11 pm

First of all, practically everything that R'n'D spits out as a "warning" can more or less simply be ignored.
Any ideas on weather these should be created or not?
That is, you do not have to create those files mentioned in the warnings as empty files or something like that.

That said, I already wanted to either remove these (relatively useless, but irritating) warnings, or at least limit printing them to the "--debug" mode.
Also RW_GAME_DIR=$settingsDir/rocksndiamonds ... can't seem to bypass the config files being created in ~/ (/boot/home)
Well, this might indeed be a bit misleading... the directory specified with "RW_GAME_DIR" is in fact only used for non-user-specific (but system-wide) global game data that needs to be written to. The top-level "Makefile" says the following about it:

Code: Select all

# directory for writable game data (like highscore files)
# (if no "scores" directory exists, scores are saved in user data directory)
# default is '.' to be able to run program without installation
# RW_GAME_DIR = .
# use the following setting for Debian / Ubuntu installations:
# RW_GAME_DIR = /var/games/rocksndiamonds
If this is not specified, "." is used, which is then (at run-time) converted to the program's main data path, which is the directory where the game binary lives. (On Mac, it is automatically calculated to be the game data directory within the app package.)

If there is no directory "scores" found at that location (to globally store high scores on multi-user systems), "RW_GAME_DIR" is in fact not used at all.

Everything user specific, like individual setup and cache files, is stored in a sub-directory (like ".rocksndiamonds" or "Rocks'n'Diamonds", depending on the target platform) of the user's home directory, which itself is determined by this piece of code in function "getHomeDir()" in file "src/libgame/setup.c":

Code: Select all

...
    if ((dir = getenv("HOME")) == NULL)
    {
      struct passwd *pwd;

      if ((pwd = getpwuid(getuid())) != NULL)
        dir = getStringCopy(pwd->pw_dir);
      else
        dir = ".";
    }
  }
...
No idea why this results in "/boot/home" instead of "/boot/home/<username>" on Haiku, but maybe this is OK(?).

From your console output dump, using something like "/boot/home/.RocksnDiamonds/setup.conf" for the location of the setup (config) file therefore seems to look fine (again, with the exception that I would expect a real user home dir in that path).

But I'm a bit confused by your last sentence, as "can't seem to bypass the config files being created in ~/ (/boot/home)" sounds like you would expect the user specific (or "personal") config/setup files (this would also affect personal level and tape files etc.) to be created in some other (global) location (which would be the same for all user then, which is probably not what you want here).

Begasus
Posts: 5
Joined: Thu Mar 16, 2017 7:58 am

Re: Haiku port

Post by Begasus » Thu Mar 16, 2017 12:26 pm

Holger wrote:
Thu Mar 16, 2017 12:11 pm
First of all, practically everything that R'n'D spits out as a "warning" can more or less simply be ignored.
Any ideas on weather these should be created or not?
That is, you do not have to create those files mentioned in the warnings as empty files or something like that.

That said, I already wanted to either remove these (relatively useless, but irritating) warnings, or at least limit printing them to the "--debug" mode.
Ok, sounds reasenable enough to me (found some other post in the forum by now also :)
Also RW_GAME_DIR=$settingsDir/rocksndiamonds ... can't seem to bypass the config files being created in ~/ (/boot/home)

Well, this might indeed be a bit misleading... the directory specified with "RW_GAME_DIR" is in fact only used for non-user-specific (but system-wide) global game data that needs to be written to. The top-level "Makefile" says the following about it:

Code: Select all

# directory for writable game data (like highscore files)
# (if no "scores" directory exists, scores are saved in user data directory)
# default is '.' to be able to run program without installation
# RW_GAME_DIR = .
# use the following setting for Debian / Ubuntu installations:
# RW_GAME_DIR = /var/games/rocksndiamonds
If this is not specified, "." is used, which is then (at run-time) converted to the program's main data path, which is the directory where the game binary lives. (On Mac, it is automatically calculated to be the game data directory within the app package.)

If there is no directory "scores" found at that location (to globally store high scores on multi-user systems), "RW_GAME_DIR" is in fact not used at all.

Everything user specific, like individual setup and cache files, is stored in a sub-directory (like ".rocksndiamonds" or "Rocks'n'Diamonds", depending on the target platform) of the user's home directory, which itself is determined by this piece of code in function "getHomeDir()" in file "src/libgame/setup.c":

Code: Select all

...
    if ((dir = getenv("HOME")) == NULL)
    {
      struct passwd *pwd;

      if ((pwd = getpwuid(getuid())) != NULL)
        dir = getStringCopy(pwd->pw_dir);
      else
        dir = ".";
    }
  }
...
No idea why this results in "/boot/home" instead of "/boot/home/<username>" on Haiku, but maybe this is OK(?).
Haiku isn't multiuser (yet) so the location for those is correct as it is now, /boot/home is the same as '.'
From your console output dump, using something like "/boot/home/.RocksnDiamonds/setup.conf" for the location of the setup (config) file therefore seems to look fine (again, with the exception that I would expect a real user home dir in that path).

But I'm a bit confused by your last sentence, as "can't seem to bypass the config files being created in ~/ (/boot/home)" sounds like you would expect the user specific (or "personal") config/setup files (this would also affect personal level and tape files etc.) to be created in some other (global) location (which would be the same for all user then, which is probably not what you want here).
Haiku's apps are installed in a chroot enviroment (read-only), user specific stuff goes into the HOME folder as mentioned in the code, we can use a global writeable location as in $settingsDir (this usually refers to "/boot/home/config/setting" or "/boot/system/settings" depending on where you install the app (the last one is the default in most cases), even if I create a scores forlder in the global folder the scores are still saved in the subfolder in HOME, again not a deal breaker, and I'm not a dev myself so can't really patch things so far that it would go into there.

You could download one of the nighly images from Haiku's webpage and try them out in VirtualBox for instance, I'm running them mainly also in virtual enviroment (host os is Ubuntu here)

Begasus
Posts: 5
Joined: Thu Mar 16, 2017 7:58 am

Re: Haiku port

Post by Begasus » Thu Mar 16, 2017 12:38 pm

PS, thanks for the reply, I'm presuming things will be ok, the config files are created at first run, leveleditor is working and even network play (seems) to be ok :)

Post Reply