Hi, > I have just compiled freesci 0.3.3 with gcc on irix. I had to give _sp in > engine/scriptdebug.c another name, since "_sp" is used internally by > the libc, causing freesci to crash. Sould I submit a patch for that?
That shouldn't be neccessary, but thanks for the offer! > 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 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 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 of LSL3 work with any of the 'officially' supported systems (SPARC/Solaris etc.)? 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 [...] Looks consistant with the error message. This would probably have been caused by an earlier problem. > the disks read 0.000.572, but freesci emulates 0.000.685, does that make any > difference? Those two SCI versions are very similar- while there are two known differences between them, those wouldn't account for this kind of problem. Note that you can specify the game version to use by putting it into your ~/.freesci/config or by using the '-V' command line parameter; auto-detection from the original binary executable is on the TODO list. > 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. > Other applications however work. Do you have the source code of the relevant part of an application that uses MIT-SHM there successfully? > 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. > 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... > I have finally gotten it to talk to the normal MIDI applications > in irix, which makes me think that just dumping out the midi data to the > serial port at the right speed should work. Otherwise, i would have to > write a libmd driver for irix... 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). Thanks for your bug reports! llap, Christoph
