Skip to main content

News

Topic: Sphere 1.5, 1.6 beta (Read 35101 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere 1.5, 1.6 beta
Reply #45
Yet another reason to hate dependency on SCons and/or cmake and the like :/

Handcrafted makefiles FTW! ;)

Re: Sphere 1.5, 1.6 beta
Reply #46
Yes, you are right, it is LINKFLAGS = ' -lz '.

Did you do a complete rebuild, `scons -c && scons`, after that change? The result of adding those linkflags changes should be that every single binary and library that is a part of Sphere will be linked to zlib (many need it to begin with, though).

Sometimes Scons is poor at knowing to do rebuilds when you change the SConstruct or SConscripts.

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere 1.5, 1.6 beta
Reply #47
Already did that, with the same results. :(

Re: Sphere 1.5, 1.6 beta
Reply #48
You could try adding the append and prepend lines to the SConscript in the common folder. I didn't realize, but with both in the root SConstruct, it just puts two '-lz's before anything else.

You could also try adding env.Append(LIBS= ['z']) and possibly env.Prepend(LIBS = ['z']). That really should have the same results, but in some cases it won't (it isn't for libpthread, for example).

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere 1.5, 1.6 beta
Reply #49
Output now becomes as silly as this:

Code: [Select]
g++ -o source/util/spktest/spktest -lz -lz -lz -lz source/util/spktest/spktest.o -Lsource/common -lz -lcommon -lcorona

with the same subsequent output.

Re: Sphere 1.5, 1.6 beta
Reply #50
Well, sometimes you just haven't told the linker enough times. :)

OK, so LIBS=['z'] is returning the same as LINKFLAGS=' -lz '.

You could just remove the spktest from the build. I don't believe it is an integral part of Sphere, all the utils are standalone programs. That would be done by changing the following line in source/util/SConscript:

Code: (python) [Select]


#'spktest' has been removed.
utils = ['alphamerge', 'chr2rss', 'image2map', 'image2rss', 'rss2image',
         'setrsstrans', 'tst2rts', 'vmap2rmp', 'vsp2rts']
  • Last Edit: January 21, 2014, 04:38:30 am by Flying Jester

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere 1.5, 1.6 beta
Reply #51
Okay, it builds, but upon trying to run it:

Code: [Select]
./engine: error while loading shared libraries: libunix.so: cannot open shared object file: No such file or directory

Whether I copy libunix.so into build/linux or remove it doesn't make a difference.

ldd libunix.so:
Code: [Select]
$ ldd libunix.so 
linux-gate.so.1 =>  (0xb76e3000)
libSDL-1.2.so.0 => /usr/lib/i386-linux-gnu/libSDL-1.2.so.0 (0xb75ff000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7516000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb74f8000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7344000)
libasound.so.2 => /usr/lib/i386-linux-gnu/libasound.so.2 (0xb724e000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb720b000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7206000)
libpulse-simple.so.0 => /usr/lib/i386-linux-gnu/libpulse-simple.so.0 (0xb7200000)
libpulse.so.0 => /usr/lib/i386-linux-gnu/libpulse.so.0 (0xb71b1000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb707c000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb7069000)
libcaca.so.0 => /usr/lib/i386-linux-gnu/libcaca.so.0 (0xb6f9d000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb6f81000)
/lib/ld-linux.so.2 (0xb76e4000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb6f78000)
libpulsecommon-4.0.so => /usr/lib/i386-linux-gnu/pulseaudio/libpulsecommon-4.0.so (0xb6f09000)
libjson-c.so.2 => /lib/i386-linux-gnu/libjson-c.so.2 (0xb6efe000)
libdbus-1.so.3 => /lib/i386-linux-gnu/libdbus-1.so.3 (0xb6eb2000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb6e90000)
libslang.so.2 => /lib/i386-linux-gnu/libslang.so.2 (0xb6d61000)
libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb6d2a000)
libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb6d08000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb6ced000)
libwrap.so.0 => /lib/i386-linux-gnu/libwrap.so.0 (0xb6ce3000)
libsndfile.so.1 => /usr/lib/i386-linux-gnu/libsndfile.so.1 (0xb6c71000)
libasyncns.so.0 => /usr/lib/i386-linux-gnu/libasyncns.so.0 (0xb6c6a000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb6c66000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb6c5e000)
libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0xb6c45000)
libFLAC.so.8 => /usr/lib/i386-linux-gnu/libFLAC.so.8 (0xb6c11000)
libvorbisenc.so.2 => /usr/lib/i386-linux-gnu/libvorbisenc.so.2 (0xb6a99000)
libvorbis.so.0 => /usr/lib/i386-linux-gnu/libvorbis.so.0 (0xb6a6d000)
libogg.so.0 => /usr/lib/i386-linux-gnu/libogg.so.0 (0xb6a63000)
libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb6a4c000)

Re: Sphere 1.5, 1.6 beta
Reply #52
Unless a library is manually opened by the program, putting it in the same directory as the executable doesn't work on Linux. Also, it linked correctly to SDL!

There are a few options for this.

One, you can copy libunix.so into /usr/lib. I wouldn't feel comfortable making that a standard procedure, though. You'd need to remember to remove it manually when you uninstalled Sphere, and theoretically a package could overwrite it if it also had library call libunix.

Two, on some systems, you can put it into /usr/local/lib. This is a better idea, but not all machines are set up to allow this path to work this way. If this works on your machine, it is a good option.

Finally, I could remember how ld conf files work. This is a bit more work, but has the advantages of both the other options, without the drawbacks. Except that you'd still have to manually remove it if you uninstall Sphere. I'll look up how this is done again.
  • Last Edit: January 21, 2014, 05:00:42 am by Flying Jester

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere 1.5, 1.6 beta
Reply #53
That would be awesome. Is there a way to do something akin to make install with Scons? Or would Sphere have to be modified to use proper directories if we want to make it installable (like use a ~/.sphere1.6 folder as the Sphere root)? I suppose there's a bit more work for global installs like that if it's not there yet...

Re: Sphere 1.5, 1.6 beta
Reply #54
All of the components of Sphere, except the video drivers, are compiled as static libraries, which are then compiled directly into the resulting executable. The video drivers are explicitly opened by the engine--the path 'system/video' is hardcoded into the engine.

That means all you need to do is copy the entire Sphere directory, and it will still work on Linux. Since we couldn't get the unix static library in Sphere to link properly to SDL, now libunix is a shared library. It needs to be installed properly somewhere. Normally, it wouldn't matter where Sphere was running from.

Since Audiere and Corona already have proper installation methods on Unix, and (ideally) Sphere doesn't need to be installed in any particular way, the last bit would be the ancient JS library. This should definitely be handled with a ld conf file in the final build or installation method. conf files are how programs get away with using directories in the lib folder on Linux. That's how I handle libconfigmanager, libgraphic, and t5 in TurboSphere (and I recommend it for V8, although Chrom(ium) statically links, and Node is a million years behind in versions, so either it wouldn't matter or it would break everything anyway).

Here's how you do it. You need to be root for every step.

First, check if there is already a file '/etc/ld.so.conf.d/engine.conf', or a folder /usr/lib/sphere. If there isn't, we're good to go. If there is, we need to change the names we will use to avoid a conflict.

Make a directory in /usr/lib. Say, /usr/lib/sphere. Put libjs.so (you don't need to do this since we already installed it, but you could put it there for organizational purposes if you wanted) and libunix.so in it. Then, make a file called '/etc/ld.so.conf.d/engine.conf', which contains in plain text '/usr/lib/sphere'. Then, run 'ldconfig'. If you've never run ldconfig, or haven't run it in a while, this can take a long time.

So (as root):
Code: [Select]

mkdir /usr/lib/sphere
cp ./libunix.so /usr/lib/sphere/libunix.so
echo '/usr/lib/sphere' > /etc/ld.so.conf.d/engine.conf
ldconfig


This makes the path /usr/lib/sphere 'hot', meaning any library there can be used by any executable. To undo that, just delete /etc/ld.so.conf.d/engine.conf, and run ldconfig again. Which you might need to do if some other program installed something called 'libunix.so', and it was getting Sphere's library instead of its own.

Scons can, in fact, do all this. I do these steps in TurboSphere's SConstruct file.
  • Last Edit: January 21, 2014, 07:46:31 am by Flying Jester

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere 1.5, 1.6 beta
Reply #55
I'll try that later. For now, I just noticed Sphere segfaults.

Code: [Select]
/dev/dsp: No such file or directory
Error opening sound device, is it busy perhaps?
Game: "startup"
Parameters: ""
Segmentation fault (core dumped)

I've run config and changing the video driver doesn't make a difference. Audio doesn't really seem to have to do anything with it either - padsp ./engine gets rid of that sound device error and it still segfaults.

Damn, sure takes a lot to get compilation fixed... Kind of reminds me why projects like TurboSphere exist.

Could I test out your precompiled binary to see if that one works?

Re: Sphere 1.5, 1.6 beta
Reply #56
That sound error is Audiere gracefully failing, I get that same error and no sound. But I don't get sound from the engine running in Wine, either, so this is still working better natively than through Wine for me. Just a guess, but I don't think Audiere appreciates modern Alsa or Pulse. It can't seem to detect either, and wants to use oss. Maybe it would work better with Jack?

I've uploaded a working copy form my machine: flyingjesterentertainment.webs.com/sphere-1.6-linux.tar.gz
I've never tried transplanting binaries directly from one Linux machine to another before, particularly between distros. I guess we'll see just how compatible Ubuntu and Arch are!

After becoming more familiar with the source, I believe more than ever that replacing the old engine is important. Not because it is poorly written, or even because of these compilation issues--although those aren't making a good case for the old engine, many new and shiny projects are a nightmare to compile, too. Mostly, it's because I have seen that the engine is built on reasoning that no longer applies to newer hardware. It is written for DirectX and OpenGL that is very old, and is optimized for what is often now the slower way to do things.

It also makes me appreciate the slightly strange assumptions I built the TurboSphere plugin system on. Namely, that the engine binary itself should do pretty nothing except load plugins. It only exposes a handful of functions to script (Require and EvaluateScript, GetTime, Delay, and GarbageCollect). No matter how old the actual engine binary for TurboSphere becomes, plugins could be made to work with modern libraries and used with the old engine proper. Of course, this puts a lot more responsibility on the plugins, but this is far more flexible than the video drivers from Sphere. They have no control over how the engine calls them. This also explains why WindowStyles can be so incredibly slow--the engine assumes it's better to tile images using multiple blit calls, rather than using wrapping and unclamped texture coordinates (although this could also be a side effect spilling over from DirectX of the time).

Speaking of which, I found a bug/undocumented limitation in Sphere. WindowStyles do not obey clipping rectangles. The reason is simple, too--the engine calls SetClippingRectangle to clip the components when drawing, changing the same clipping rectangle that is set from script, rather than only drawing portions. That would require texture coordinate modification or specification from the engine to the video driver, which does not happen.
  • Last Edit: January 21, 2014, 03:45:28 pm by Flying Jester

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere 1.5, 1.6 beta
Reply #57
Re WindowStyle+SetClippingRectangle - on first glance I personally wouldn't expect WindowStyle to be subject to normal blitting behaviors and rules; it is basically a nine-part border+background image, after all, and surrounds the expected rectangle, so unless we implement something equivalent to "box-sizing: border-box;" CSS it feels like it'd be more of a pain than necessary to fit this square into a round peg.

Re: Sphere 1.5, 1.6 beta
Reply #58
I mean that it draws outside the clipping rectangle. I don't mind that it isn't wrapped to the clipping rectangle, I don't expect it to, but the clipping rectangle is a promise--nothing outside it will be touched. And WindowStyles, unlike everything else, do draw outside it. And in a buggy way, too.

What makes me think this is a bug is that some of the components of WindoStyles are clipped. The corners are--makes sense, you never want to tile or draw portions of those, it's always the whole thing. The rest isn't, because it can be tiled or draw in portions, which is done by changing the clipping rectangle. At the end of drawing WindowStyles, the clipping rectangle is reset to what it was beforehand.

It looks like ignoring the clipping rectangle is just an unintended consequence. It wasn't considered what would happen if the clipping rectangle was already set, beyond resetting it when the WindowStyle was done drawing. I did the same thing in TurboSphere for a while, until I decided to use greater-than-1 texture coordinates to do texture tiling.

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere 1.5, 1.6 beta
Reply #59
I imagine them to be pretty binary-compatible as indie game devs have been distributing games like that for a few years without much issue now. But we'll see.
...Damn, your binaries didn't work because they're 64-bit and I'm on a 32-bit OS.