# SDL & BeOS problems

First, before I start my ranting, I would like to ask all the Linux
developers to NOT hardcode the Paths of the datadirs or the installation
dirs. It makes portability really weak, especially for an OS like BeOS where
a /usr/local/… does not exist. Allow the game to run from ANY directory. I
can’t even ‘configure --prefix’ any app for BeOS, as BeOS is not Unix/Linux.
A user should be able to install it to ANY dir he/she desires.
Also, as long we you don’t use GTK+ or Jpeglib or other things “just for
fun”, your games will be easily ported to BeOS. I slept at 1 AM last night
trying to fix issues like that and right now I am almost sleeping on my desk
at work…

For the SDL maintainers:
I am trying to port a number of SDL games to the BeOS, but the SDL_ttf and
SDL_net do not compile.
The SDL_ttf configure script fails because it tries to compile on the fly a
test program for freetype. BeOS does not support that kind of testing on the
configure script. Another game was trying to test if SDL was installed
(while it was) and it failed finding it because it was trying to run a small
SDL test program on the fly.
I took out all that code and SDL_ttf created the makefile ok. But when I
tried to compile it, I get lots of compiler errors, syntax errors. I wonder
if Sam has tried to build that lib with BeOS R4.5, because BeOS 5 uses a new
version of gcc and it does not compile older code, quite often.

SDL_net also failed to create a makefile, but I managed to fix that. The
problem occured later though when the libtool failed to create a shared lib,
it only created a .a static lib. The reason for that was because
SDL_net_error() (or something like that, can’t remember now, I am at work
now) had an unresolved symbol. BeOS will NOT allow to create shared libs if
there are unresolved symbols lying around.

Sam, please, if you test with BeOS and you find your lib working and you
these BeOS compiled libs, not just the source. I am trying to port about 10
games to BeOS and most of them are failing because of SDL_ttf and SDL_net.

Also, did you have a look at the SDL 1.2 I compiled for you? I am currently
linking my games with this lib, but the rest of the BeOS world do not have
that specific version yet. Please post it on the SDL web site, or transfer
the BeBits account to me, so I can take care of it.

On a more happy note, here it is, Java bindings for SDL, by a fellow BeOS
community member: http://jsdl.sourceforge.net

Thanks,
Eugenia—
Homepage: http://www.eugenia.co.uk
What is BeOS? http://www.BeNews.com/BeOS/

BTW, I do have installed correctly the Freetype library. I downloaded and
installed FreeType 2.01 yesterday.
However, the configure script is trying to find libttf.so, while freetype is
creating a libfreetype.so. I renamed it and it kinda worked. My problem are
the compiler’s syntax errors, nothing to do with the Freetype lib really.
Sam, please have a look and update SDL_ttf if possible… It seems that it
needs updating to all platforms, not just BeOS, as it is using/linking to a
very old version of FreeType /me thinks.

Thanks,
Eugenia—
Homepage: http://www.eugenia.co.uk
What is BeOS? http://www.BeNews.com/beos/

“Eugenia Loli-Queru” writes:

BTW, I do have installed correctly the Freetype library. I downloaded and
installed FreeType 2.01 yesterday.
However, the configure script is trying to find libttf.so, while freetype is
creating a libfreetype.so. I renamed it and it kinda worked. My problem are
the compiler’s syntax errors, nothing to do with the Freetype lib really.
Sam, please have a look and update SDL_ttf if possible… It seems that it
needs updating to all platforms, not just BeOS, as it is using/linking to a
very old version of FreeType /me thinks.

SDL_ttf simply doesn’t work with FreeType 2.–
[ Below is a random fortune, which is unrelated to the above message. ]
This space intentionally left blank.

“Eugenia Loli-Queru” writes:

The SDL_ttf configure script fails because it tries to compile on the fly a
test program for freetype. BeOS does not support that kind of testing on the
configure script. Another game was trying to test if SDL was installed

That statement is just plain incorrect. Running test programs is a
major part of configure and it works just fine on BeOS. If it doesn’t
work, there is a problem with the installation (this include the SDL
test program).

The only time this doesn’t work is when cross-compiling.–
[ Below is a random fortune, which is unrelated to the above message. ]
This space intentionally left blank.

BTW, I do have installed correctly the Freetype library. I downloaded and
installed FreeType 2.01 yesterday.
However, the configure script is trying to find libttf.so, while freetype is
creating a libfreetype.so. I renamed it and it kinda worked. My problem are
the compiler’s syntax errors, nothing to do with the Freetype lib really.
Sam, please have a look and update SDL_ttf if possible… It seems that it
needs updating to all platforms, not just BeOS, as it is using/linking to a
very old version of FreeType /me thinks.

Yes, SDL_ttf links with FreeType 1.3.
Michael Vance started a port of SDL_ttf to FreeType 2.0, but never
completed it, and I haven’t had time to work on it. It’s on my TODO list.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

First, before I start my ranting, I would like to ask all the Linux
developers to NOT hardcode the Paths of the datadirs or the installation
dirs. It makes portability really weak, especially for an OS like BeOS where
a /usr/local/… does not exist. Allow the game to run from ANY directory.

Just for reference, this is really hard to do. You can’t use the current
directory because the user may be running the program from another directory.

I’m attaching public code that we use at Loki to determine the installation
path in our products.

Here is the code in SDL for BeOS:

#include <AppKit.h>
#include <storage/Path.h>
#include <storage/Entry.h>

    /* Check if we started from Terminal or Tracker... */
/* Based on code posted to BeDevTalk by Marco Nelissen */
char *cmd = getenv("_");
if(!(cmd == NULL || strlen(cmd) < 7) &&
(!strcmp(cmd + strlen(cmd) - 7 , "Tracker"))) {

/* Change working to directory to that of executable */
app_info info;
if (B_OK == be_app->GetAppInfo(&info)) {
entry_ref ref = info.ref;
BEntry entry;
if (B_OK == entry.SetTo(&ref)) {
BPath path;
if (B_OK == path.SetTo(&entry)) {
if (B_OK == path.GetParent(&path)) {
chdir(path.Path());
}
}
}
}
} /* else started from Terminal */


can’t even ‘configure --prefix’ any app for BeOS, as BeOS is not Unix/Linux.

Well, you can, but the desktop user isn’t set up to run things that way.

For the SDL maintainers:
I am trying to port a number of SDL games to the BeOS, but the SDL_ttf and
SDL_net do not compile.

By the way, running a program to test for a library in configure does work
if the dependent shared libraries are installed in a system directory.
e.g. libSDL.so -> ~/config/lib/

SDL_net also failed to create a makefile, but I managed to fix that. The
problem occured later though when the libtool failed to create a shared lib,
it only created a .a static lib. The reason for that was because
SDL_net_error() (or something like that, can’t remember now, I am at work
now) had an unresolved symbol. BeOS will NOT allow to create shared libs if
there are unresolved symbols lying around.

Have you tried the latest CVS?
http://www.libsdl.org/cvs/
SDL_image-1.1.1.tar.gz
SDL_image-1.1.1.zip
SDL_net-1.1.2.tar.gz
SDL_ttf-1.2.2.tar.gz

I’m hoping to release updated versions of these as soon as I can get
Windows and BeOS booting again. :-/

Sam, please, if you test with BeOS and you find your lib working and you
these BeOS compiled libs, not just the source.

Will do.

Also, did you have a look at the SDL 1.2 I compiled for you?

I’m going to do that right now.

On a more happy note, here it is, Java bindings for SDL, by a fellow BeOS
community member: http://jsdl.sourceforge.net

Cool! Can I announce that on the SDL website?

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
-------------- next part --------------

# Feb. 17, 2000 - Sam Lantinga, Loki Entertainment Software

FindPath()
{
fullpath="echo $1 | grep / if [ “$fullpath” = “” ]; then
oIFS=”$IFS" IFS=: for path in$PATH
do if [ -x “$path/$1” ]; then
if [ “$path” = “” ]; then path=".“ fi fullpath=”$path/$1" break fi done IFS="$oIFS"
fi
if [ “$fullpath” = “” ]; then fullpath="$1"
fi
# Is the awk/ls magic portable?
if [ -L “$fullpath” ]; then fullpath=ls -l "$fullpath" | awk '{print $11}' fi dirname$fullpath
}
FindPath \$0
-------------- next part --------------
/*
Loki_Update - A tool for updating Loki products over the Internet

This program is free software; you can redistribute it and/or modify
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

info at lokigames.com


*/

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>

#define PATH_MAX 8192

void goto_installpath(char *argv0)
{
char temppath[PATH_MAX];
char datapath[PATH_MAX];
char *home;

home = getenv("HOME");
if ( ! home ) {
home = ".";
}

strcpy(temppath, argv0);    /* If this overflows, it's your own fault :) */
if ( ! strrchr(temppath, '/') ) {
char *path;
char *last;
int found;

found = 0;
path = getenv("PATH");
do {
/* Initialize our filename variable */
temppath[0] = '\0';

/* Get next entry from path variable */
last = strchr(path, ':');
if ( ! last )
last = path+strlen(path);

/* Perform tilde expansion */
if ( *path == '~' ) {
strcpy(temppath, home);
++path;
}

/* Fill in the rest of the filename */
if ( last > (path+1) ) {
strncat(temppath, path, (last-path));
strcat(temppath, "/");
}
strcat(temppath, "./");
strcat(temppath, argv0);

/* See if it exists, and update path */
if ( access(temppath, X_OK) == 0 ) {
++found;
}
path = last+1;

} while ( *last && !found );

} else {
/* Increment argv0 to the basename */
argv0 = strrchr(argv0, '/')+1;
}

/* Now canonicalize it to a full pathname for the data path */
datapath[0] = '\0';
if ( realpath(temppath, datapath) ) {
/* There should always be '/' in the path */
*(strrchr(datapath, '/')) = '\0';
}
if ( ! *datapath || (chdir(datapath) < 0) ) {
fprintf(stderr, "Couldn't change to install directory\n");
exit(1);
}


}

Just for reference, this is really hard to do. You can’t use the
current
directory because the user may be running the program from another
directory.

Why not just use the code (in main() so you have argv):

int i;
char datapath[256];
for (i=strlen(argv[0]) ; argv[0][i]!=’/’ ; i–);
strncpy(datapath, argv[0], i);
chdir(datapath);

It works for me. It allows the user to launch the app while being in any
dir, as
it will always change the pwd to the dir the exe is in. You can then
just use
relative paths to data files.

David.

Just for reference, this is really hard to do. You can’t use the
current
directory because the user may be running the program from another
directory.

Why not just use the code (in main() so you have argv):

Because the app can have “appname” as argv[0] instead of the full path
to the application.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

First, before I start my ranting, I would like to ask all the Linux
developers to NOT hardcode the Paths of the datadirs or the installation
dirs. It makes portability really weak, especially for an OS like BeOS
where

a /usr/local/… does not exist. Allow the game to run from ANY
directory.

Just for reference, this is really hard to do. You can’t use the current
directory because the user may be running the program from another
directory.

Could this be made a platform independant function in SDL? Possibly a full
set of functions for working with paths that would work with
Linux/Win32/MacOS? Or would this be better served as a separate library?

“David Phillips” writes:

Could this be made a platform independant function in SDL? Possibly a full
set of functions for working with paths that would work with
Linux/Win32/MacOS? Or would this be better served as a separate library?

Hmm. This could indeed be a useful extension since it’s a typical
platform dependent issue. It could be used to translate paths from
/foo/bar to \foo\bar on windows as well as foo:bar or what not on
MacOS.

I have had an idea to create a simple datafile library
(semi-related). I.e a set of tools to extract and generate a
collection of files with a library to access it from random program.
I was thinking about using mmap (when available) due to the efficiency
of it.

Perhaps a cross-platform lib with path functionality as well as a
simple archive system would be useful?–
[ Below is a random fortune, which is unrelated to the above message. ]
This space intentionally left blank.

Could this be made a platform independant function in SDL? Possibly a
full

set of functions for working with paths that would work with
Linux/Win32/MacOS? Or would this be better served as a separate
library?
Perhaps a cross-platform lib with path functionality as well as a
simple archive system would be useful?

Although SDL has no such functionality, I wouldn’t say it is a requirement
for it. Just like the math library, this could be an independant library
that would be useful to users of SDL.

A good place to start on such a project, however, might be EXEDAT:

I remember using it for DOS programs. We may not want to stuff the data
inside the executable like they did, but some other functionality they
provide could probably be re-used. I don’t think it is still supported, so
we may want to look into zLib for compression, in case there are bugs.

A quick look at SourceForge reveals the following projects:

## http://sourceforge.net/projects/avf/http://sourceforge.net/projects/zziplib/--

Olivier A. Dagenais - Software Architect and Developer

developers to NOT hardcode the Paths of the datadirs or the installation

Could this be made a platform independant function in SDL? Possibly a full
set of functions for working with paths that would work with
Linux/Win32/MacOS? Or would this be better served as a separate library?

It is fundamental requirement for most software to be able to access
files. IMHO, SDL should have couple of functions for platform independent
filesystem access.

This interface should include at least two things:
- Platform independent file and path naming and accessing
- Platform independent directory scanning (!)

Yes, I am sure there already is library that does these, but I still
believe this would be worth including into the bare SDL as well, as
these are so often needed, and not too much trouble (or LOC) IMHO.

( I have made directory scanning for WIN32 & Linux, if that helps
anyone. They work for me, for sure they are not perfect…
Teddy/src/SysSupport/FileScan.* in glelite.sourceforge.net CVS,
It’s C++ & STL, use like this: FileScan lwos( “*lwo” );
list::iterator f_it = lwos.get_files().begin(); )

For filesystem, there are at least a couple of components:
- Device (mountpoint, assign, alias…) name
- Device->directory delimenter
- Directory name
- Directory->directory delimeter
- Directory->file delimeter
- File name
- Absolute paths
- Relative paths
- Current directory
- Previous directory

There might be others on some obscure systems, but these are the
ones that I am aware of.

– Timo Suoranta – @Timo_K_Suoranta

On a more happy note, here it is, Java bindings for SDL, by a fellow
BeOS

community member: http://jsdl.sourceforge.net

Cool! Can I announce that on the SDL website?

Sure! You can always ask Jerome of course, but I am sure he won’t
disagree…

Thanks,
Eugenia

Hey, I was just wondering if some of these hard to do (yet not so hard to do
once you’ve figured them out) things we’ve been mentionning in the last few
weeks could make their way into the SDL FAQ (or some other central SDL
documentation)?

I speak specifically of this code that Sam just distributed. Also the prallax
scrolling examples from a while ago and even the little IPC multiple window SDL
app example I gave last week could be helpful there as well.On Thu, 29 Mar 2001, you wrote:

First, before I start my ranting, I would like to ask all the Linux
developers to NOT hardcode the Paths of the datadirs or the installation
dirs. It makes portability really weak, especially for an OS like BeOS where
a /usr/local/… does not exist. Allow the game to run from ANY directory.

Just for reference, this is really hard to do. You can’t use the current
directory because the user may be running the program from another directory.

I’m attaching public code that we use at Loki to determine the installation
path in our products.

Here is the code in SDL for BeOS:

Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >

Actually, I was under the impression that some compilers converted path-names

I haven’t had any personal experience with them myself… but when this same
subject came up about a year ago on this list that was one comment that I
remember.On Thu, 29 Mar 2001, you wrote:

“David Phillips” writes:

Could this be made a platform independant function in SDL? Possibly a full
set of functions for working with paths that would work with
Linux/Win32/MacOS? Or would this be better served as a separate library?

Hmm. This could indeed be a useful extension since it’s a typical
platform dependent issue. It could be used to translate paths from
/foo/bar to \foo\bar on windows as well as foo:bar or what not on
MacOS.

Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >

Timo K Suoranta wrote:

( I have made directory scanning for WIN32 & Linux, if that helps
anyone. They work for me, for sure they are not perfect…
Teddy/src/SysSupport/FileScan.* in glelite.sourceforge.net CVS,
It’s C++ & STL, use like this: FileScan lwos( “*lwo” );
list::iterator f_it = lwos.get_files().begin(); )

Any change you make that SDL (thus C w/o STL) compatible anytime?–
| Andreas Schiffler aschiffler at home.com |
| Senior Systems Engineer - Tek21 Inc., Buffalo |
| 4707 Eastwood Cres., Niagara Falls, Ont L2E 1B4, Canada |
| +1-905-371-3652 (private) - +1-905-371-8834 (work/fax) |

Actually, I was under the impression that some compilers converted path-names

The windows compiler understands “/” in directories. I think / == C: but
i’m not sure. It works fine for local paths “./sprites/one.bmp” and
settings in visual studio “…/SDL/include”, etc. But it is still hard to
guarantee the current directory.

I know windows sets the current directory when you launch out of explorer
or set the “Start in” value on a shortcut. I’m not sure what Tracker sets
it to, or unix for that matter.

-ryanOn Fri, 30 Mar 2001, Samuel Hart wrote:

Any change you make that SDL (thus C w/o STL) compatible anytime?

Does SDL have any data structure support? Lists? I guess I could
just create char **files… Sure, no problem. But that would be
sort of quick thing, and still note that the pattern matching
works a little different on different platforms on win32/linux;
the other returns paths, the other does not

Give me a few days and I’ll put C version online somewhere and

– Timo Suoranta – @Timo_K_Suoranta --On Fri, 30 Mar 2001, Andreas Schiffler wrote:

Timo K Suoranta wrote:

> It is fundamental requirement for most software to be able to access > files. IMHO, SDL should have couple of functions for platform independent > filesystem access. > > This interface should include at least two things: > - Platform independent file and path naming and accessing > - Platform independent directory scanning (!) right.

this provides an abstract stream api which and virtual filesystem which
are
accessed with an URL (normal filename defaults to file:///).

socket access is also done by this api.

~-n_____________________________________
Enrico Weigelt
meTUX IT Services

www: www.metux.de
email: @Enrico_Weigelt
phone: +49 36207 51833
cellphone: +49 174 7066481