Good morning,
[...]
> > imho, the other heap_ptrs should be renamed as well, since variables with
> > underscores as the first character don't look like a good idea to me.
>
> Hmm, I used to think only symbols starting with two underscores were (by
> convention) reserved for the system (compiler and libc). Considering this
That's what I used to think.
> evidence of a more strict (or less strict, depending on your POV)
> convention, we'll have to review pretty much all of the code to look for
> similar potential problems.
I don't know the spec (somebody should check), but for now, I'd consider
this a bug in the irix libc...
> > I have some more problems: LSL3 bombs to the script debugger
> > almost immediateley (before showing any game graphics):
>
> Do any other games work on your IRIX box? Does this particular version
Yes, LSL2, Iceman, Hoyle all work. Haven't found my copy of SQ3, must be on
5 1/4" floppies that are rotting away somewhere.
> of LSL3 work with any of the 'officially' supported systems (SPARC/Solaris
> etc.)?
It does, I just tried linux/x86.
> Unfortunately, floppy disks are relatively error prone; this wouldn't be
> the first case of a game breaking because the resource files have become
> corrupted on the original game disks.
>
>
> > Calling LSL3::play()
> > Script error in file vm.c, line 582: Relative stack underflow
> > pc=0846 acc=0001 o=2132 fp=83e2 sp=83de
> > prev=0 sbase=83d4 globls=310e &restmod=0
> > Step #1951
> > 0846: [W] not
> > >bt
[...]
> > Next problem is that MIT-SHM doesn't seem to work. I have got it compiled
> > in, but freesci disables it on startup:
> > GFX-XLIB 199: X11: BadAccess (attempt to access private resource denied)
> > GFX-XLIB 199: X11: BadShmSeg (invalid shared segment parameter)
> > GFX-XLIB 523:Shared Memory Pixmaps not supported on this system.
> > Disabling! GFX-XLIB 199: X11: BadPixmap (invalid Pixmap parameter)
> > GFX-XLIB 199: X11: BadShmSeg (invalid shared segment parameter)
>
> This affects Xsun, too, IIRC. I have added a report to the bug tracker
> since I neither know the chants and invocations neccessary to use MIT-SHM
> nor have time to read up on them ATM.
The following patch gets it working (for me):
--- xlib_driver.c.orig Fri Jan 4 15:45:42 2002
+++ xlib_driver.c Thu Mar 7 01:44:26 2002
@@ -507,7 +507,7 @@
ERROR("ARGH! Can't attach shared memory segment\n");
have_shmem = 0;
}
- shmctl(S->shm[i]->shmid, IPC_RMID, 0);
+ /*shmctl(S->shm[i]->shmid, IPC_RMID, 0);*/
}
if (have_shmem && !x11_error) {
I suspect that's a bad idea, since shm segments may not be relased, and,
if I did not misread the spec, the original method of requesting it to
be released after attaching to it looks OK. The shmctl may have to be
called later, when the pixmap is released.
> > Other applications however work.
>
> Do you have the source code of the relevant part of an application that
> uses MIT-SHM there successfully?
I'd suggest x48. Should be available e.g. from any debian mirror.
> > This is an O2, which offers lots of
> > visuals to choose from. FreeSCI's speed, however is _almost_
> > right without MIT-SHM and most of the beautifications turned on.
>
> When auto-choosing (i.e. when -c is not used), FreeSCI first tries 32bpp
> then 24bpp etc. Running with -c16 should work fine on Xsgi; it
> might be faster and shouldn't look too much worse.
Doesn't work. Visuals are depth 8, 12, 15 and 24, with depth==bpp for all
except 15 (bpp=16) and 24 (bpp=24 or 32). I think freesci tries (depth=16),
which, obviously, must fail.
> > Lastly, I have a Roland SC-55mkII connected via the serial port to my
> > box. Shouldn't it work with the unixraw driver connected with the port
> > at 38400 8N1?
>
> Well, theoretically...
> Try adding the line 'midiout.unixraw.device = /dev/ttyS0' (or whatever the
> name of the device is) to the generic section (beginning) of your
> ~/.freesci/config file. If additional initialization is required, you
> can add it to 'midiout_unixraw_open()' in src/sound/midiout_unixraw.c,
> although it'd be best to make it depend on a driver-specific option
> (those are processed by 'midiout_unixraw_set_parameter()' in the same
> file).
I'll try that tomorrow... libmd doesn't seem too difficult, so I may write
a "real" midi driver for Irix. Is there any information out there, what
the parameters to midiout_*_write etc.. are, and what the functions are
supposed to do?
I almost forgot to mention the various quirks I encountered when building
freesci: On my linux/x86 box, I had to manually add "-lXft -lXrender
-lfreetype", and on the Irix box, -lreadline implies -lncurses, causing lots
of warnings if one adds -lncurses. There seems to be a linker bug on Irix
that forced me to edit configure and instead of $ac_link call
${CC-cc} conftest.$ac_ext -o conftest${ac_exeext} $CFLAGS $CPPFLAGS
$LDFLAGS $LIBS in the curses test. The "conftest.$ac_ext" needs to go first,
otherwise the linker fails ;-(
Oh, yes, and there is the fact that char is unsigned (sizeof(char)=1) by
default with my sgi, thus
--- ../../../clean/freesci-0.3.3/src/include/sciresource.h Mon Dec 10
00:26:07 2001
+++ sciresource.h Wed Mar 6 22:10:29 2002
@@ -142,7 +142,7 @@
unsigned int size;
unsigned int file_offset; /* Offset in file */
- char file; /* Number of the resource file this resource is stored in */
+ signed char file; /* Number of the resource file this resource is
stored in */
unsigned char status;
unsigned short lockers; /* Number of places where this resource was
locked */
is needed to make the comparisons to SCI_RES_FILE_NR_PATCH functional.
There may be more like this, but gcc warns about the file==-1.
Rainer
