Spherical forums

Sphere Development => Engine Development => Topic started by: N E O on July 16, 2013, 07:47:44 pm

Title: Sphere 1.5, 1.6 beta
Post by: N E O on July 16, 2013, 07:47:44 pm
GitHub repo: https://github.com/sphere-group/sphere (https://github.com/sphere-group/sphere) (engine should eventually be split into https://github.com/sphere-group/sphere-engine (https://github.com/sphere-group/sphere-engine))

SourceForge: http://sourceforge.net/projects/sphere/ (http://sourceforge.net/projects/sphere/)
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on September 11, 2013, 06:18:00 am
Hey, so here's a question.

I saw in the 1.6 source the following (https://github.com/sphere-group/sphere/blob/master/sphere/source/engine/ss_functions.table#L117 (https://github.com/sphere-group/sphere/blob/master/sphere/source/engine/ss_functions.table#L117)):

  SS_FUNCTION(DeflateByteArray, 1)
  SS_FUNCTION(InflateByteArray, 2)
  SS_FUNCTION(DeflateFile, 2)
  SS_FUNCTION(InflateFile, 2)

These functions are exposed to script. Does anyone know how they work or if they work, and why they are not a part of the documentation?
Title: Re: Sphere 1.5, 1.6 beta
Post by: Radnen on September 11, 2013, 06:21:22 am
FBN added that, and AFAIK it works completely. There was a test suite that released with the 1.6 binaries that showed off all the new neat additions from an sfxr inspired wave editor to particle effects.
Title: Re: Sphere 1.5, 1.6 beta
Post by: N E O on September 11, 2013, 07:20:04 pm
What Radnen said.

The *flate API was to finally expose zlib functionality to Sphere coders instead of limiting it to SPK processing or as a supporting library for PNG et al. 1.6 was supposed to finalize all of kyuu's additions (the built-in particle system, etc), FBN's additions (the aforementioned SFXR, zlib, etc), and various cleanups by tung et al in preparation for not only alpha123's 1.7 work but also kyuu's proposed migration to an API closer how JavaScript already works (what was supposed to become Sphere 2.0 and instead became his squirrel prototype).

I highly recommend we work any remaining bugs out of vanilla 1.6 so that it can go gold. Most of the bugs seem to be concentrated on the map engine (surprise surprise) and a bit in the new stuff; I also wanted some vetting of the particle system since even though kyuu documented it thoroughly it's still a bit confusing to work with out-of-the-box, as well as field testing for myself the SoundEffect API.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on September 12, 2013, 05:22:59 am
I believe it would also be useful to fix Corona so that it at least compiles on a modern(ish) system. The only thing stopping it from compiling for me is the PNG component, and it just seems to be because of differences with the newer versions of libpng.

I suggest that the overwriting of sgm files be removed, as well (if it isn't already from 1.6).

I have read through the Sphere source on github a bit. I don't know why the SDL driver doesn't use doublebuffering mode--I don't think there's any reason not to, ever.

I've also found that the 1.6 editor defaults to saving scripts as PHP when no extension is given. But I don't really expect bugs in the old editor (or small inconveniences in this case) to be fixed.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on September 12, 2013, 07:25:49 am
Wait, zlib functionality was exposed in 1.6? Man, this needs to go on the wiki somewhere.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on September 12, 2013, 08:11:43 am
I know. I wanted to do this in TurboSphere, and I'm glad that the API already exists for it.

I have patched Corona (http://github.com/FlyingJester/corona) to work with libpng 1.5, the newest version distributed with Fedora 19. It works (at least somewhat) on my computer, but it would be nice for someone with Windows to try it out. It's going to take more for it to fully work, specifically saving PNGs doesn't seem to work anymore. But it's better than it was.

EDIT: I take that back. It seems to work perfectly.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Fat Cerberus on September 12, 2013, 10:02:00 am

I suggest that the overwriting of sgm files be removed, as well (if it isn't already from 1.6).


Whoever thought this was a good idea, anyway?  From an engine standpoint there's no reason to modify the .sgm file at all.  This still baffles me.
Title: Re: Sphere 1.5, 1.6 beta
Post by: N E O on September 12, 2013, 02:06:18 pm
If we can find the exact location in the vanilla source SGM handling takes place on game start/end, I will fully support changing its behavior.

We will need a check against unsupported modification of it and we need to define what actually happens if/when the currently running SGM file is modified in script by ANY file edit function (eg, changing window size/resolution in a config menu and calling RestartGame() like so many older scripts do).
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 10, 2014, 10:54:38 pm
I updated Audiere (https://github.com/FlyingJester/audiere) to compile using GCC 4. Most of what needed to be done was to add some header includes. If it doesn't yet compile with MSVC, this had to be done to make that happen anyway.

EDIT: After a lot of work, I got the latest Sphere sources from github to compile on Linux. I've put my changes on GitHub (https://github.com/FlyingJester/sphere).
Most of the work was adding #includes to cstring, memory, and cstdlib. I also found a couple places with mismatched #defines removing a definition but not a use of some variables in Unix, and an issue with the scons file.

I still don't quite understand that last bit, except that I think the old, binary-incompatible version of zlib seems to be referenced somewhere in Audiere or Corona, so you need to prepend a zlib reference to the environment's LIBS flags for the engine.

I do feel a bit of sincere gratitude to the developers who worked on Sphere in the old days. There were several comments mentioning some of the changes I had to make! Mainly, showing what needed to be done, commented out, mostly if Audiere was never updated fully for Unix--I guess it never was. Sphere has one of the cleanest and best written code bases I have ever seen for a project of its age.

I still need to test this build a lot more, but it looks like (except for the ancient libjs/spidermonkey), I've got Sphere compiled on Linux using the newest stable versions of all the libraries it uses (same with Audiere and Corona), and with the latest version of GCC. I'm pretty happy with that.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 11, 2014, 10:09:23 am
Thanks for the work! It will be very nice if we can get something that will compile properly in Linux for the coming time. (And we can get deb packages out of it, of course!) Will definitely be using this. :)

Speaking of adding Linux compatibility, maybe it'd be a good idea to associate sgm and spk files with Sphere during sudo make install. If it doesn't do that already. Makes it a one-click solution to run Sphere games after Sphere is installed.

(edit - fixed apk to spk ~neo)
Title: Re: Sphere 1.5, 1.6 beta
Post by: N E O on January 11, 2014, 01:10:52 pm
Jester, can you do a pull request on the original repo diff'ing your changes so one of us can merge them in, or can you do it yourself since you already have push+pull privileges on it?
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 11, 2014, 05:19:23 pm
No one wants to test it out before it gets puled?

Well, all my changes are guarded so that they don't affect Windows compilation, and it already didn't work on Linux, so I'll go ahead and pull it to the original repo myself.

I can build Arch packages and RPMs, but I don't have any idea about debs (or a machine for testing them on properly). It would be awesome if the final release of 1.6 had rpm and deb packages!
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 11, 2014, 05:22:55 pm
FJ: going to compile it now, will let you know if it works without issues. (32-bit Xubuntu 13.10)

Edit: building fails. Lots of wx errors; do I need a specific version? Never mind, I was missing libwxgtk.
It fails on audiere now, though - didn't realize that was a separate thing in a separate Git. Doing that now. We really need a nice automated build script for these things...

Edit: audiere fails to build. http://pastebin.com/v29kRQ1i
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 11, 2014, 06:59:08 pm
Are you using my version of Audiere?

You need to use the versions of Audiere and and Corona I modified to compile on Linux. The wxPlayer example program in Audiere always fails. You can still run and install without it.

Audiere (https://github.com/FlyingJester/audiere) and Corona (https://github.com/FlyingJester/corona)

You'll also need some ancient JS. Link here (http://ftp.mozilla.org/pub/mozilla.org/js/older-packages/), and choose 1.5. The build instructions tell you use to gmake, but just using make will work. You have to call make on the specific file mentioned in their instructions.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 12, 2014, 05:38:17 am

Are you using my version of Audiere?

Quote from: DaVince
didn't realize that was a separate thing in a separate Git.

= Yeah, I'm using your version of Audiere. Trying to compile that first, but it fails with the above. I'm not seeing any .so files or anything afterwards, either. (And if I don't need to compile Audiere itself, how can I at least let Sphere's build script know where it is? It doesn't seem to catch it when I clone that Git straight in sphere/audiere...)
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 12, 2014, 08:34:50 am
I found that `make install` still threw the wxPlayer errors, but installed Audiere all the same. I did have to rename the installed audiere.so to audiere-1.9.4.so in usr/lib, though.

Strangely, I never could find Audiere's library without doing `make install`.

You can do a quick check (if you have scons, which you will need to build Sphere) to see if Audiere has been properly installed by putting this in a file called Sconstruct:
Code: (python) [Select]

import os
import sys
env = Environment(ENV=os.environ)
conf = Configure(env)
conf.CheckLib('audiere')

And running scons on it.

You'd still need to find the actual library and make a copy called 'audiere-1.9.4.so', but that would quickly tell you if `make install` worked on Audiere.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 12, 2014, 01:51:26 pm
You're right; Audiere seems to have built. Perhaps it would be best to remove all instances of those wx files from your version of Corona.
Final step (I think): JS has compiled, but how do I make install or at least make Sphere aware where the js source is?
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 12, 2014, 06:57:11 pm
This is a little ugly, but it's the only easy way, it seems.

Copy all the header files from JS into /usr/local/include, and libjs.so directly into /usr/local/lib.

Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 16, 2014, 05:12:46 pm
Getting closer...

Code: [Select]
scons: Reading SConscript files ...
os.name: posix
Using compiler: linux
Found sdl-config: /usr/bin/sdl-config
Using subsystem: unix
Found sdl-config: /usr/bin/sdl-config
Found wx-config: /usr/bin/wx-config
Found sdl-config: /usr/bin/sdl-config
Found sdl-config: /usr/bin/sdl-config
scons: done reading SConscript files.
scons: Building targets ...
g++ -o source/common/AnimationFactory.o -c -DNO_WRITE_MNG -DUNIX source/common/AnimationFactory.cpp
g++ -o source/common/DefaultFile.o -c -DNO_WRITE_MNG -DUNIX source/common/DefaultFile.cpp
g++ -o source/common/DefaultFileSystem.o -c -DNO_WRITE_MNG -DUNIX source/common/DefaultFileSystem.cpp
g++ -o source/common/Entities.o -c -DNO_WRITE_MNG -DUNIX source/common/Entities.cpp
g++ -o source/common/FLICAnimation.o -c -DNO_WRITE_MNG -DUNIX source/common/FLICAnimation.cpp
g++ -o source/common/Filters.o -c -DNO_WRITE_MNG -DUNIX source/common/Filters.cpp
g++ -o source/common/Font.o -c -DNO_WRITE_MNG -DUNIX source/common/Font.cpp
g++ -o source/common/Image32.o -c -DNO_WRITE_MNG -DUNIX source/common/Image32.cpp
g++ -o source/common/Layer.o -c -DNO_WRITE_MNG -DUNIX source/common/Layer.cpp
source/common/Layer.cpp: In copy constructor 'sLayer::sLayer(const sLayer&)':
source/common/Layer.cpp:59:72: error: 'memcpy' was not declared in this scope
         memcpy(m_Tiles, layer.m_Tiles, m_Width * m_Height * sizeof(int));
                                                                        ^
source/common/Layer.cpp: In member function 'const sLayer& sLayer::operator=(const sLayer&)':
source/common/Layer.cpp:99:76: error: 'memcpy' was not declared in this scope
             memcpy(m_Tiles, layer.m_Tiles, m_Width * m_Height * sizeof(int));
                                                                            ^
source/common/Layer.cpp: In member function 'void sLayer::Translate(int, int, int*, int, int)':
source/common/Layer.cpp:187:58: error: 'memcpy' was not declared in this scope
     memcpy(old_tiles, tiles, width * height * sizeof(int));
                                                          ^
scons: *** [source/common/Layer.o] Error 1
scons: building terminated because of errors.


While we're at it, what are the exact dependencies that Sphere needs in order to compile? Like the stuff that I need from Ubuntu's repositories, I mean?
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 16, 2014, 09:50:19 pm
You will need zlib, SDL (1.2, not 1.3 or 2.0), Corona and Audiere. I don't recall needing anything else, except for g++, scons, and python of course.

To fix that error (I'll push this change to the git repo), add to the top of Layer.hpp:

Code: (c++) [Select]

#include <cstring>


This is one of the examples of Sphere not being compiled by GCC in a while. In MSVC, it seems most of cstring is exposed by default.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 17, 2014, 06:19:53 am
PackageFileSystem.hpp needed the same treatment.
Playlist.hpp needs #include <memory> and #include <stdio.h>.
configfile.hpp needs #include <memory>, #include <stdio.h>, #include <cstring>

Now it's stumbling over SDL, though... I seem to have all SDL1.2 dependencies, but... Google tells me this has something to do with the compile script, so dunno how to fix that.
Code: [Select]
scons: Reading SConscript files ...
os.name: posix
Using compiler: linux
Found sdl-config: /usr/bin/sdl-config
Using subsystem: unix
Found sdl-config: /usr/bin/sdl-config
Found wx-config: /usr/bin/wx-config
Found sdl-config: /usr/bin/sdl-config
Found sdl-config: /usr/bin/sdl-config
scons: done reading SConscript files.
scons: Building targets ...
g++ -o source/engine/engine source/engine/SpritesetServer.o source/engine/benchmark.o source/engine/engine.o source/engine/log.o source/engine/map_engine.o source/engine/render.o source/engine/rendersort.o source/engine/parameters.o source/engine/script.o source/engine/sfont.o source/engine/sfxr.o source/engine/simage.o source/engine/smap.o source/engine/sphere.o source/engine/ssfxr.o source/engine/sspriteset.o source/engine/swindowstyle.o source/engine/PlayerConfig.o -Lsource/common -Lsource/particle_engine -L/usr/lib/i386-linux-gnu -Lsource/engine/unix -lcommon -laudiere -lcorona -lmng -ljpeg -lz -lparticle_engine -lSDL -lunix -ldl -ljs
Install file: "system/scripts/colors.js" as "build/linux/system/scripts/colors.js"
Install file: "system/scripts/colorspace.js" as "build/linux/system/scripts/colorspace.js"
Install file: "system/scripts/convert.js" as "build/linux/system/scripts/convert.js"
Install file: "system/scripts/fademessage.js" as "build/linux/system/scripts/fademessage.js"
Install file: "system/scripts/graphics.js" as "build/linux/system/scripts/graphics.js"
Install file: "system/scripts/input.js" as "build/linux/system/scripts/input.js"
Install file: "system/scripts/intro.js" as "build/linux/system/scripts/intro.js"
Install file: "system/scripts/joysticks.js" as "build/linux/system/scripts/joysticks.js"
Install file: "system/scripts/layers.js" as "build/linux/system/scripts/layers.js"
Install file: "system/scripts/map_animation.js" as "build/linux/system/scripts/map_animation.js"
Install file: "system/scripts/math.js" as "build/linux/system/scripts/math.js"
Install file: "system/scripts/menu.js" as "build/linux/system/scripts/menu.js"
Install file: "system/scripts/named_parameters.js" as "build/linux/system/scripts/named_parameters.js"
Install file: "system/scripts/old_spriteset.js" as "build/linux/system/scripts/old_spriteset.js"
Install file: "system/scripts/oldsphere.js" as "build/linux/system/scripts/oldsphere.js"
Install file: "system/scripts/playlist.js" as "build/linux/system/scripts/playlist.js"
Install file: "system/scripts/screen.js" as "build/linux/system/scripts/screen.js"
Install file: "system/scripts/time.js" as "build/linux/system/scripts/time.js"
Install file: "system/scripts/timed_animation.js" as "build/linux/system/scripts/timed_animation.js"
Install file: "system/scripts/timer.js" as "build/linux/system/scripts/timer.js"
Install file: "system/scripts/wintro.js" as "build/linux/system/scripts/wintro.js"
Install file: "system/system.ini" as "build/linux/system/system.ini"
Install file: "system/system.rfn" as "build/linux/system/system.rfn"
Install file: "system/system.rws" as "build/linux/system/system.rws"
Install file: "system/up_arrow.png" as "build/linux/system/up_arrow.png"
g++ -o source/video_unix/sdl32/sdl32.os -c -DNO_WRITE_MNG -DUNIX -fPIC source/video_unix/sdl32/sdl32.cpp
g++ -o source/video_unix/sdl32/configfile.os -c -DNO_WRITE_MNG -DUNIX -D_GNU_SOURCE=1 -D_REENTRANT -fPIC -I/usr/include/SDL source/common/configfile.cpp
g++ -o source/video_unix/sdl32/defaultfile.os -c -DNO_WRITE_MNG -DUNIX -D_GNU_SOURCE=1 -D_REENTRANT -fPIC -I/usr/include/SDL source/common/DefaultFile.cpp
g++ -o source/video_unix/sdl32/defaultfilesystem.os -c -DNO_WRITE_MNG -DUNIX -D_GNU_SOURCE=1 -D_REENTRANT -fPIC -I/usr/include/SDL source/common/DefaultFileSystem.cpp
g++ -o source/video_unix/sdl_gl/sdl_gl.os -c -DNO_WRITE_MNG -DUNIX -fPIC source/video_unix/sdl_gl/sdl_gl.cpp
g++ -o source/video_unix/sdl_gl/configfile.os -c -DNO_WRITE_MNG -DUNIX -D_GNU_SOURCE=1 -D_REENTRANT -fPIC -I/usr/include/SDL source/common/configfile.cpp
g++ -o source/video_unix/sdl_gl/defaultfile.os -c -DNO_WRITE_MNG -DUNIX -D_GNU_SOURCE=1 -D_REENTRANT -fPIC -I/usr/include/SDL source/common/DefaultFile.cpp
g++ -o source/video_unix/sdl_gl/defaultfilesystem.os -c -DNO_WRITE_MNG -DUNIX -D_GNU_SOURCE=1 -D_REENTRANT -fPIC -I/usr/include/SDL source/common/DefaultFileSystem.cpp
g++ -o source/util/alphamerge/alphamerge.o -c -DNO_WRITE_MNG -DUNIX -Isource/common source/util/alphamerge/alphamerge.cpp
g++ -o source/util/chr2rss/chr2rss.o -c -DNO_WRITE_MNG -DUNIX -Isource/common source/util/chr2rss/chr2rss.cpp
source/engine/unix/libunix.a(unix_input.o): In function `UpdateSystem()':
unix_input.cpp:(.text+0x115b): undefined reference to `SDL_PollEvent'
source/engine/unix/libunix.a(unix_input.o): In function `SetMousePosition(int, int)':
unix_input.cpp:(.text+0x1409): undefined reference to `SDL_WarpMouse'
source/engine/unix/libunix.a(unix_input.o): In function `GetNumJoysticks()':
unix_input.cpp:(.text+0x1473): undefined reference to `SDL_NumJoysticks'
source/engine/unix/libunix.a(unix_input.o): In function `GetNumJoystickAxes(int)':
unix_input.cpp:(.text+0x1486): undefined reference to `SDL_NumJoysticks'
unix_input.cpp:(.text+0x14ad): undefined reference to `SDL_JoystickOpen'
unix_input.cpp:(.text+0x14c8): undefined reference to `SDL_JoystickNumAxes'
source/engine/unix/libunix.a(unix_input.o): In function `GetJoystickAxis(int, int)':
unix_input.cpp:(.text+0x14db): undefined reference to `SDL_NumJoysticks'
unix_input.cpp:(.text+0x150e): undefined reference to `SDL_JoystickOpen'
unix_input.cpp:(.text+0x1530): undefined reference to `SDL_JoystickGetAxis'
source/engine/unix/libunix.a(unix_input.o): In function `GetNumJoystickButtons(int)':
unix_input.cpp:(.text+0x155e): undefined reference to `SDL_NumJoysticks'
unix_input.cpp:(.text+0x1585): undefined reference to `SDL_JoystickOpen'
unix_input.cpp:(.text+0x15a0): undefined reference to `SDL_JoystickNumButtons'
source/engine/unix/libunix.a(unix_input.o): In function `IsJoystickButtonPressed(int, int)':
unix_input.cpp:(.text+0x15b3): undefined reference to `SDL_NumJoysticks'
unix_input.cpp:(.text+0x15da): undefined reference to `SDL_JoystickOpen'
unix_input.cpp:(.text+0x15fb): undefined reference to `SDL_JoystickNumButtons'
unix_input.cpp:(.text+0x1629): undefined reference to `SDL_JoystickGetButton'
source/engine/unix/libunix.a(unix_time.o): In function `GetTime()':
unix_time.cpp:(.text+0x7): undefined reference to `SDL_GetTicks'
collect2: error: ld returned 1 exit status
g++ -o source/util/image2map/image2map.o -c -DNO_WRITE_MNG -DUNIX -Isource/common source/util/image2map/image2map.cpp
scons: *** [source/engine/engine] Error 1
source/video_unix/sdl_gl/sdl_gl.cpp: In function 'bool InitVideo(int, int, std::string)':
source/video_unix/sdl_gl/sdl_gl.cpp:181:38: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
     SDL_putenv("SDL_VIDEO_CENTERED=1");
                                      ^
scons: building terminated because of errors.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 17, 2014, 08:15:15 am
I hate to say it, but are you sure you have the SDL development package, and not just the runtime?
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 17, 2014, 08:46:18 am
I do, that's why I'm surprised! Installed SDL-related packages:
libalien-sdl-perl
libsdl-gfx1.2-4:i386
libsdl-gfx1.2-dev:i386
libsdl-image1.2:i386
libsdl-image1.2-dev:i386
libsdl-mixer1.2:i386
libsdl-net1.2:i386
libsdl-net1.2-dev:i386
libsdl-pango1:i386
libsdl-perl
libsdl-sound1.2:i386
libsdl-sound1.2-dev:i386
libsdl-ttf2.0-0:i386
libsdl-ttf2.0-dev:i386
libsdl1.2-dev
libsdl1.2debian:i386
libsdl2-2.0-0:i386
libsdl2-dev
mupen64plus-audio-sdl:i386
mupen64plus-input-sdl:i386
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 17, 2014, 02:48:00 pm
Strange, it worked as-is on my machine.

You could try adding
Code: (c++) [Select]

#include <SDL/sdl.h>


to the top of input.cpp, and possibly try changing the Sconscript file in source/engine/unix to:

Code: (python) [Select]

Import('base_env COMPILER')

env = base_env.Clone()
COMPILER.SetupSDL(env)

#This is new.
env.Append(LIBS = ['sdl'])

env.Library('unix', Split("""
    unix_audio.cpp
    unix_filesystem.cpp
    unix_input.cpp
    unix_network.cpp
    unix_screenshot.cpp
    unix_system.cpp
    unix_sphere_config.cpp
    unix_time.cpp
    unix_video.cpp
    unix_main.cpp
    """))

Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 17, 2014, 03:03:03 pm
I couldn't find an input.cpp, just an input.hpp which seems to rely on unix_input.cpp. Either way I just get this:

Code: [Select]

source/engine/unix/unix_input.cpp:1:21: fatal error: SDL/sdl.h: No such file or directory
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 17, 2014, 04:39:59 pm
Right, that should actually be SDL/SDL.h, sorry.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 17, 2014, 06:58:16 pm
Okay, there's a few less errors now, but those SDL-related ones are still there.

Code: [Select]

scons: Reading SConscript files ...
os.name: posix
Using compiler: linux
Found sdl-config: /usr/bin/sdl-config
Using subsystem: unix
Found sdl-config: /usr/bin/sdl-config
Found wx-config: /usr/bin/wx-config
Found sdl-config: /usr/bin/sdl-config
Found sdl-config: /usr/bin/sdl-config
scons: done reading SConscript files.
scons: Building targets ...
g++ -o source/engine/engine source/engine/SpritesetServer.o source/engine/benchmark.o source/engine/engine.o source/engine/log.o source/engine/map_engine.o source/engine/render.o source/engine/rendersort.o source/engine/parameters.o source/engine/script.o source/engine/sfont.o source/engine/sfxr.o source/engine/simage.o source/engine/smap.o source/engine/sphere.o source/engine/ssfxr.o source/engine/sspriteset.o source/engine/swindowstyle.o source/engine/PlayerConfig.o -Lsource/common -Lsource/particle_engine -L/usr/lib/i386-linux-gnu -Lsource/engine/unix -lcommon -laudiere -lcorona -lmng -ljpeg -lz -lparticle_engine -lSDL -lunix -ldl -ljs
source/engine/unix/libunix.a(unix_input.o): In function `UpdateSystem()':
unix_input.cpp:(.text+0x115b): undefined reference to `SDL_PollEvent'
source/engine/unix/libunix.a(unix_input.o): In function `SetMousePosition(int, int)':
unix_input.cpp:(.text+0x1409): undefined reference to `SDL_WarpMouse'
source/engine/unix/libunix.a(unix_input.o): In function `GetNumJoysticks()':
unix_input.cpp:(.text+0x1473): undefined reference to `SDL_NumJoysticks'
source/engine/unix/libunix.a(unix_input.o): In function `GetNumJoystickAxes(int)':
unix_input.cpp:(.text+0x1486): undefined reference to `SDL_NumJoysticks'
unix_input.cpp:(.text+0x14ad): undefined reference to `SDL_JoystickOpen'
unix_input.cpp:(.text+0x14c8): undefined reference to `SDL_JoystickNumAxes'
source/engine/unix/libunix.a(unix_input.o): In function `GetJoystickAxis(int, int)':
unix_input.cpp:(.text+0x14db): undefined reference to `SDL_NumJoysticks'
unix_input.cpp:(.text+0x150e): undefined reference to `SDL_JoystickOpen'
unix_input.cpp:(.text+0x1530): undefined reference to `SDL_JoystickGetAxis'
source/engine/unix/libunix.a(unix_input.o): In function `GetNumJoystickButtons(int)':
unix_input.cpp:(.text+0x155e): undefined reference to `SDL_NumJoysticks'
unix_input.cpp:(.text+0x1585): undefined reference to `SDL_JoystickOpen'
unix_input.cpp:(.text+0x15a0): undefined reference to `SDL_JoystickNumButtons'
source/engine/unix/libunix.a(unix_input.o): In function `IsJoystickButtonPressed(int, int)':
unix_input.cpp:(.text+0x15b3): undefined reference to `SDL_NumJoysticks'
unix_input.cpp:(.text+0x15da): undefined reference to `SDL_JoystickOpen'
unix_input.cpp:(.text+0x15fb): undefined reference to `SDL_JoystickNumButtons'
unix_input.cpp:(.text+0x1629): undefined reference to `SDL_JoystickGetButton'
source/engine/unix/libunix.a(unix_time.o): In function `GetTime()':
unix_time.cpp:(.text+0x7): undefined reference to `SDL_GetTicks'
collect2: error: ld returned 1 exit status
scons: *** [source/engine/engine] Error 1
scons: building terminated because of errors.


Now, here's the interesting thing:
Code: [Select]
g++ -o source/engine/engine source/engine/SpritesetServer.o source/engine/benchmark.o source/engine/engine.o source/engine/log.o source/engine/map_engine.o source/engine/render.o source/engine/rendersort.o source/engine/parameters.o source/engine/script.o source/engine/sfont.o source/engine/sfxr.o source/engine/simage.o source/engine/smap.o source/engine/sphere.o source/engine/ssfxr.o source/engine/sspriteset.o source/engine/swindowstyle.o source/engine/PlayerConfig.o -Lsource/common -Lsource/particle_engine -L/usr/lib/i386-linux-gnu -Lsource/engine/unix -lcommon -laudiere -lcorona -lmng -ljpeg -lz -lparticle_engine -lSDL -lunix -ldl -ljs

I've Googled the problem, and so far about five different forums state that if you put -lSDL at the very end instead of where it is now (4th last), that should fix things. I have no idea how to do that with a scons file, though.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 17, 2014, 10:44:02 pm
To put -lSDL at the end:

Code: (python) [Select]

Import('base_env COMPILER')

env = base_env.Clone()
COMPILER.SetupSDL(env)

#This is new.
env.Append(LINKFLAGS = ' -lSDL ')

env.Library('unix', Split("""
   unix_audio.cpp
   unix_filesystem.cpp
   unix_input.cpp
   unix_network.cpp
   unix_screenshot.cpp
   unix_system.cpp
   unix_sphere_config.cpp
   unix_time.cpp
   unix_video.cpp
   unix_main.cpp
   """))
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 18, 2014, 09:06:59 am
Well... Looks like that made no difference. Same output as before. I really have no clue why I can't compile - I have the libsdl1.2-dev and related source packages installed, after all!

Where does it try to look for SDL? Or is that done in an automated way? The only place I could locate SDL.h is /usr/include/SDL/SDL.h.
Title: Re: Sphere 1.5, 1.6 beta
Post by: N E O on January 18, 2014, 04:12:10 pm
Doesn't SDL normally use `sdl-config --libs` or something to generate the necessary parameters? Find which SConscript files are calling that then go from there?
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 18, 2014, 04:45:34 pm
Yes, you can use SDL-Config, and Sphere does. It doesn't work nearly as well as it is claimed to.

What is the output of `sdl-config --libs`? This looks like a linking issue.

...It is possible that the SDL in Ubuntu repos is compiled without joystick and timer support, but that would be strange.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 18, 2014, 06:15:59 pm
-L/usr/lib/i386-linux-gnu -lSDL

I also can't imagine joystick support not being there. I remember a few years ago at least I could use the joystick in pygame, which is based on SDL... But that's a pretty distant link to this. :P
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 18, 2014, 06:29:44 pm
That output sounds fine, what about `sdl-config --cflags`? That's the other thing that sdl-config is often used for.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 18, 2014, 06:32:21 pm
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT

Edit: I also have SDL2 installed. Could it be confusing them somehow?
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 18, 2014, 07:07:08 pm
That also looks good.

SDL2 shouldn't conflict. All the SDL2 headers should be in /usr/include/SDL2, and the libraries should be called SDL2 and SDL2_[libname].

When I compiled Sphere on Linux (I did it again, just to check), I had both SDL and SDL2, as well as a separate SDL2 install in /usr/local (which is given preference on my system), which has no audio or power management compiled in. I'll see what I can find about this. I would really like to think it is the SDL included in the Ubuntu repos based on what we are seeing. But that also sounds strange, since these are very commonly used features in SDL, and it would be very surprising if these weren't a part of Ubuntu's SDL.

EDIT: What version of SDL do you have? I am specifically compiling against SDL 1.2.15, but it very likely will work against any SDL version 1.2.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 18, 2014, 07:42:26 pm
Standard Ubuntu version: package libsdl1.2debian and libsdl1.2-dev, version 1.2.15ubuntu2. Man, I wonder what's going on here.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 18, 2014, 07:51:54 pm
I've pushed all the changes that I need for Sphere to compile on my system to my github fork.

Perhaps if you clone from it, specifically here (https://github.com/FlyingJester/sphere), with the changes that work for me, and try compiling that?

EDIT: Question for someone who is more knowledgeable about the wiki: What page should I add the steps for compiling Sphere on Linux? I was looking at the Getting Started, Linux section (http://wiki.spheredev.org/Getting_started#Linux), but I seem to recall the old wiki having instructions for compiling in the past.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 18, 2014, 08:09:15 pm
Was already getting Sphere from there, so I just undid my local changes and did a git pull. That didn't work; got the same output. So then I did a clean checkout. Still gives the same error.


Quote
EDIT: Question for someone who is more knowledgeable about the wiki: What page should I add the steps for compiling Sphere on Linux? I was looking at the Getting Started, Linux section, but I seem to recall the old wiki having instructions for compiling in the past.

If memory serves properly, there was an article called "Compiling Sphere" which had a Linux section on it.
I'm also hoping to have a full script soon to pull in your version of Sphere, all of its dependencies, and compile it all. But I need to get it compiling here first...
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 18, 2014, 08:23:52 pm
I pushed some more changes (mostly the ones we just worked out) to it before my last post.
OK, let's just test to see that the SDL libraries for Ubuntu have the functions that are apparently missing.

To find where the libraries are:
Code: [Select]

ls /usr/lib | grep -i libsdl


Or at least it is /usr/lib on my machine. It might be different on Ubuntu.

If there are multiple results (usually with different numbers on the end of .so), run `file` on them to see where they point (many will be symlinks). Once you get an actual executable, see what the output of this is:

Code: [Select]

nm -D /usr/lib/[what the above command produced] | grep SDL_NumJoysticks


The output should be an address, a letter, and then SDL_NumJoysticks. The letter should also not be 'U'.

EDIT: Interesetingly, from a little snooping it seems that Ubuntu gets a man page for sdl-config (Arch doesn't!). Maybe that has some info on linking.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 18, 2014, 08:47:41 pm
Your first command outputs nothing!
Okay, turns out it's in /usr/lib/i386-linux-gnu/.
libSDL-1.2.so.0.11.4 is a valid file there.
Your final command prints out this:
Code: [Select]
00032900 T SDL_NumJoysticks
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 18, 2014, 10:59:14 pm
Makes sense, the sdl-config --libs includes that path. And that is exactly the same as what I get (in fact, I get the exact same actual executable, and the same address and symbol type).

Ubuntu also distributes static libraries for SDL 1.2. We can check to see if linking is being done against that (again, shouldn't really make a difference, but that's not how it's working on my system).

You can try changing the SConscript file in sphere/source/unix to this:

Code: (python) [Select]

Import('base_env COMPILER')

env = base_env.Clone()
COMPILER.SetupSDL(env)

#this is what we want.
env.SharedLibrary('unix', Split("""
    unix_audio.cpp
    unix_filesystem.cpp
    unix_input.cpp
    unix_network.cpp
    unix_screenshot.cpp
    unix_system.cpp
    unix_sphere_config.cpp
    unix_time.cpp
    unix_video.cpp
    unix_main.cpp
    """))

#this keeps the build working, but the engine executable will be non-functional.
env.Library('unix', Split("""
    unix_audio.cpp
    unix_filesystem.cpp
    unix_input.cpp
    unix_network.cpp
    unix_screenshot.cpp
    unix_system.cpp
    unix_sphere_config.cpp
    unix_time.cpp
    unix_video.cpp
    unix_main.cpp
    """))


Then, run `ldd libunix.so` in the same directory. It should show libSDL-1.2.so (possibly with a number appended) as one of the linked libraries if you are linking to the shared library.

You will have to manually delete libunix.so afterwards for the build to produce a functional engine executable.

It really should work anyway, but if you are not getting linked to the shared library then things aren't working the same way as on my machine.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 19, 2014, 07:59:59 am
Quote
Then, run `ldd libunix.so` in the same directory.

I suppose I need to do this after I have successfully run Scons? Building still fails, but at least it fails at a different point now:

Code: [Select]
scons: Reading SConscript files ...
os.name: posix
Using compiler: linux
Found sdl-config: /usr/bin/sdl-config
Using subsystem: unix
Found sdl-config: /usr/bin/sdl-config
Found wx-config: /usr/bin/wx-config
Found sdl-config: /usr/bin/sdl-config
Found sdl-config: /usr/bin/sdl-config
scons: done reading SConscript files.
scons: Building targets ...
g++ -o source/engine/engine source/engine/SpritesetServer.o source/engine/benchmark.o source/engine/engine.o source/engine/log.o source/engine/map_engine.o source/engine/render.o source/engine/rendersort.o source/engine/parameters.o source/engine/script.o source/engine/sfont.o source/engine/sfxr.o source/engine/simage.o source/engine/smap.o source/engine/sphere.o source/engine/ssfxr.o source/engine/sspriteset.o source/engine/swindowstyle.o source/engine/PlayerConfig.o -Lsource/common -Lsource/particle_engine -L/usr/lib/i386-linux-gnu -Lsource/engine/unix -lcommon -laudiere -lcorona -lmng -ljpeg -lz -lparticle_engine -lSDL -lunix -ldl -ljs
g++ -o source/video_unix/sdl32/libsdl32.so -shared source/video_unix/sdl32/sdl32.os source/video_unix/sdl32/configfile.os source/video_unix/sdl32/defaultfile.os source/video_unix/sdl32/defaultfilesystem.os -lz
g++ -o source/util/spktest/spktest source/util/spktest/spktest.o -Lsource/common -lz -lcommon -lcorona
Install file: "source/util/tst2rts/tst2rts" as "build/linux/util/tst2rts"
g++ -o source/util/vmap2rmp/vmap2rmp source/util/vmap2rmp/vmap2rmp.o -Lsource/common -lz -lcommon -lcorona
Install file: "source/util/vsp2rts/vsp2rts" as "build/linux/util/vsp2rts"
Install file: "source/video_unix/sdl32/libsdl32.so" as "build/linux/system/video/sdl32.so"
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Close()':
PackageFile.cpp:(.text+0x38): undefined reference to `inflateEnd'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Read(void*, int)':
PackageFile.cpp:(.text+0x165): undefined reference to `inflate'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Seek(int)':
PackageFile.cpp:(.text+0x395): undefined reference to `inflateEnd'
PackageFile.cpp:(.text+0x3d8): undefined reference to `inflateInit_'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::CPackageFile(_IO_FILE*, int, int, int)':
PackageFile.cpp:(.text+0x517): undefined reference to `inflateInit_'
collect2: error: ld returned 1 exit status
scons: *** [source/util/spktest/spktest] Error 1
scons: building terminated because of errors.


The internet tells me this (https://stackoverflow.com/questions/1632201/error-deflate-and-inflate-with-zlib), but trying to add env.Append(LINKFLAGS = ' -lz ') makes zero difference in the output.

I also just tried to compile something entirely unrelated (OpenMW) to see if my build system didn't somehow break, but that compiles just fine.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 19, 2014, 08:48:48 am
I used both env.Prepend(LINKFLAGS ' -lz ')  and env.Append(LINKFLAGS ' -lz '). You will probably need to put that in the top level SConstruct file, right after
Code: [Select]


# common options
base_env.Append(CXXFLAGS = ['-DUNIX'])
#new
base_env.Prepend(LINKFLAGS ' -lz ')
base_env.Append(LINKFLAGS ' -lz ')


I thought that made it into the git repo. Actually makes me wonder why it's working for me now when I definitely had to do that before.

If there is a libunix.so in the unix folder, you can run ldd on it at any point. Shared libraries need to be all linked up (not necessarily have all their symbols defined, though), while static libraries are just archives of object files. We need a shared library of libunix so we can see how it got linked to SDL.

If everything compiles and links fine with a shared library of libunix, there is a slightly inelegant way of making it all work, though--as in, having fully functional Sphere native on Linux. If it comes to it, it may at least be worth doing to see if that's the only problem left.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 20, 2014, 07:52:22 am
Adding that results in
Code: [Select]
scons: Reading SConscript files ...
  File "/home/vincent/src/sphere/sphere/SConstruct", line 134

    base_env.Prepend(LINKFLAGS  ' -lz ')

                                      ^

SyntaxError: invalid syntax


Changing the lines to
Code: [Select]
base_env.Prepend(LINKFLAGS = ' -lz ')
base_env.Append(LINKFLAGS = ' -lz ')

but I don't know if that's the right thing to do or not. In any case, it resulted in this:

Code: [Select]
scons: Reading SConscript files ...
os.name: posix
Using compiler: linux
Found sdl-config: /usr/bin/sdl-config
Using subsystem: unix
Found sdl-config: /usr/bin/sdl-config
Found wx-config: /usr/bin/wx-config
Found sdl-config: /usr/bin/sdl-config
Found sdl-config: /usr/bin/sdl-config
scons: done reading SConscript files.
scons: Building targets ...
g++ -o source/util/spktest/spktest -lz -lz source/util/spktest/spktest.o -Lsource/common -lz -lcommon -lcorona
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Close()':
PackageFile.cpp:(.text+0x38): undefined reference to `inflateEnd'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Read(void*, int)':
PackageFile.cpp:(.text+0x165): undefined reference to `inflate'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Seek(int)':
PackageFile.cpp:(.text+0x395): undefined reference to `inflateEnd'
PackageFile.cpp:(.text+0x3d8): undefined reference to `inflateInit_'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::CPackageFile(_IO_FILE*, int, int, int)':
PackageFile.cpp:(.text+0x517): undefined reference to `inflateInit_'
collect2: error: ld returned 1 exit status
scons: *** [source/util/spktest/spktest] Error 1
scons: building terminated because of errors.

It seems to error less than before, but maybe it didn't make a difference since it's stumbling on the same issue.
Title: Re: Sphere 1.5, 1.6 beta
Post by: N E O on January 20, 2014, 05:49:38 pm
Yet another reason to hate dependency on SCons and/or cmake and the like :/

Handcrafted makefiles FTW! ;)
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 21, 2014, 01:13:48 am
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.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 21, 2014, 04:04:28 am
Already did that, with the same results. :(
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 21, 2014, 04:11:58 am
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).
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 21, 2014, 04:27:31 am
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.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 21, 2014, 04:36:10 am
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']
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 21, 2014, 04:46:51 am
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)
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 21, 2014, 04:59:08 am
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.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 21, 2014, 06:42:14 am
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...
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 21, 2014, 07:42:19 am
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.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 21, 2014, 09:43:52 am
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?
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 21, 2014, 03:43:50 pm
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 (http://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.
Title: Re: Sphere 1.5, 1.6 beta
Post by: N E O on January 21, 2014, 04:27:48 pm
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.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 21, 2014, 05:18:20 pm
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.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 22, 2014, 08:43:51 am
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.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 22, 2014, 12:13:41 pm
Oh yeah. And I don't have 32-bit gcc or any of the libraries to make this work on my machine.

Do you have GDB or Valgrind installed? Both libjs and all of Sphere are compiled with debugging symbols enabled by default, so we can get informative stack traces and likely see where it is failing.

Also, I forgot to mention that the SDL_GL video driver doesn't work. I had to add to its SConscript to make it link with GL, and even then it seems to crash from time to time. sdl32 works fine, although it's very slow.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 25, 2014, 08:43:13 pm
Ah, sorry. Only seeing your post just now. I do seem to have GDB installed. How do I invoke it?
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 25, 2014, 09:18:02 pm
Code: [Select]

gdb ./engine
run


When it crashes, type `backtrace`, and we'll check the output.

Type `quit` to stop gdb.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 26, 2014, 04:01:58 pm
Okay, wow, that is convenient.

Code: [Select]
vincent@vincent-K93SV:~/src/sphere/sphere/build/linux$ gdb ./engine
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/vincent/src/sphere/sphere/build/linux/engine...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/vincent/src/sphere/sphere/build/linux/./engine
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
/dev/dsp: No such file or directory
[New Thread 0xb70a9b40 (LWP 13950)]
[New Thread 0xb68a8b40 (LWP 13951)]
Error opening sound device, is it busy perhaps?
Game: "startup"
Parameters: ""
[New Thread 0xb5d01b40 (LWP 13952)]

Program received signal SIGSEGV, Segmentation fault.
0x08195990 in SetClippingRectangle ()
(gdb) backtrace
#0  0x08195990 in SetClippingRectangle ()
#1  0xb70b85b1 in InitVideo () from /home/vincent/src/sphere/sphere/build/linux/system/video/sdl32.so
#2  0xb7ebf474 in SwitchResolution(int, int) () from /usr/lib/libunix.so
#3  0x080547c9 in CGameEngine::Run() ()
#4  0x080e3d09 in DoRunGame(char const*, char const*) ()
#5  0x080e4284 in RunGame(char const*, char const*) ()
#6  0x080e3af5 in RunSphere(int, char const**) ()
#7  0xb7ec07b0 in main () from /usr/lib/libunix.so
#8  0xb7afb905 in __libc_start_main (main=0x8050c30 <main@plt>, argc=1, ubp_av=0xbffff124, init=0x8127610 <__libc_csu_init>, fini=0x8127680 <__libc_csu_fini>,
    rtld_fini=0xb7fed5f0 <_dl_fini>, stack_end=0xbffff11c) at libc-start.c:260
#9  0x08051961 in _start ()
(gdb) quit
A debugging session is active.

Inferior 1 [process 13946] will be killed.

Quit anyway? (y or n) y
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on January 26, 2014, 09:09:17 pm
Code: [Select]
Hmm. Makes me wonder if SDL is actually initializing correctly. Try adding this:

[code = c++]
if(SDLScreenBuffer==NULL){
  fprintf(stderr, "SDLScreenBuffer is null\n");
  return false;
}


in sphere/source/video_unix/sdl32/sdl32.cpp at line 371 (just before the only call to SDL_ShowCursor), and then rerun scons. That will make the SDL32 driver tell Sphere it couldn't initialize if the screen surface couldn't be made. Not a bad thing to do have a check for in any case, actually.

That will make Sphere quit gracefully instead of crashing, if I'm right about why it's failing.

We could also try running Sphere under gdb with the SDL_GL driver selected, too, just to see where that is crashing.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on January 28, 2014, 03:22:40 pm
I deleted the build folder, cleaned scons, then reran it. At first my output was like this:
Code: [Select]
/home/vincent/src/sphere/sphere/build/linux/system/video/: cannot read file data: Is a directory
Video subsystem could not be initialized...

But then I realized it's because I didn't run config yet. (It's sensible to set a default!)
Then I selected sdl32, and it still crashes with a segfault:
Code: [Select]
$ ./engine 
/dev/dsp: No such file or directory
Error opening sound device, is it busy perhaps?
Game: "startup"
Parameters: ""
Segmentation fault (core dumped)


GDB output:
Code: [Select]
Reading symbols from /home/vincent/src/sphere/sphere/build/linux/engine...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/vincent/src/sphere/sphere/build/linux/./engine
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
/dev/dsp: No such file or directory
[New Thread 0xb70a9b40 (LWP 4926)]
[New Thread 0xb68a8b40 (LWP 4927)]
Error opening sound device, is it busy perhaps?
Game: "startup"
Parameters: ""
[New Thread 0xb5d01b40 (LWP 4928)]

Program received signal SIGSEGV, Segmentation fault.
0x08195990 in SetClippingRectangle ()
(gdb) backtrace
#0  0x08195990 in SetClippingRectangle ()
#1  0xb70b85ef in InitVideo () from /home/vincent/src/sphere/sphere/build/linux/system/video/sdl32.so
#2  0xb7ebf474 in SwitchResolution(int, int) () from /usr/lib/libunix.so
#3  0x080547c9 in CGameEngine::Run() ()
#4  0x080e3d09 in DoRunGame(char const*, char const*) ()
#5  0x080e4284 in RunGame(char const*, char const*) ()
#6  0x080e3af5 in RunSphere(int, char const**) ()
#7  0xb7ec07b0 in main () from /usr/lib/libunix.so
#8  0xb7afb905 in __libc_start_main (main=0x8050c30 <main@plt>, argc=1, ubp_av=0xbffff104, init=0x8127610 <__libc_csu_init>, fini=0x8127680 <__libc_csu_fini>,
    rtld_fini=0xb7fed5f0 <_dl_fini>, stack_end=0xbffff0fc) at libc-start.c:260
#9  0x08051961 in _start ()
(gdb) quit

Seems to be the same? Though maybe I'm overlooking a change.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on February 16, 2014, 10:42:14 pm
You could try running SDL_GL, too. I pushed the changes that fix it (linking to OpenGL...no idea how it would work without that in the first place).

In GDB, after it breaks, what is the output of `mappings`?
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on April 23, 2014, 08:59:08 pm
@Rahkiin: Could you perhaps try compiling Sphere from Git on OS X, but using the Linux profile?

The Linux profile basically means 'use SDL', so I'd be interested to see if/why it fails.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Rahkiin on April 24, 2014, 07:43:54 am
Part 1 of my quest to building Sphere for Mac.

In this quest, I will be trying to build (Do or do not, there is no try -- Yoda) building Sphere for Mac from source. I will explain everything I do so that 1) It becomes a funny story, 2) I can be judged about how much I suck at SCons, 3) Others can reproduce what I do and build Sphere themselves.
Some parts will not need to be reproduced because I put them on the git repo.

First, a git clone of the sphere repository.
It seems Sphere uses some obscene building system called SCons, so installing it from the website.
Then scons nags about sdl, so I install SDL2 with brew install sdl2. Seems I needed SDL1, so installed that.
Then it started about wxWidgets, presumably needed for the config program. Installing that.
But even after installing wxWidgets, it does not build the config because wxMac is broken, kinda. Instead, I removed config from the build. (I will push this to the repo. Nobody needs that silly program anyways.)

Executing scons once more:

Code: [Select]

source/engine/video.hpp:11:2: error: unsupported platform
#error unsupported platform


Seems that you failed to use the correct macros on platform-specific stuff. So I fixed that using information on this page: http://sourceforge.net/p/predef/wiki/OperatingSystems/

I created a platform.h in common/ that generates macro-definitions for all platforms (we use). Then I include that file where it is needed. Now the checking for compiler stuff is in 1 place and can be easily updated. Example for video.hpp:

Code: [Select]

#include "platform.h"

#if SPHERE_WIN32
# include "win32/win32_video.hpp"
#elif SPHERE_MAC_OSX
# include "mac/mac_video.h"
#elif SPHERE_UNIX
# include "unix/unix_video.h"
#endif


(Sidenote, the use of '../common' everywhere is useless, as common is included in the search path. At least, here it is.)

By defining the SPHERE_* macros as 1, we can use a simple #if and #elif, because a non-defined macro is 0. Cleans up :)
I also included compiler macros: SPHERE_MSC, SPHERE_CLANG, SPHERE_GCC, SPHERE_MYNGW.
And then I added SPHERE_STDCALL that only expands to __attribute__((stdcall)) on SPHERE_WIN32. It cleans up dozens of warnings on my side.
I can't confirm the working of the platform macros that are not SPHERE_MAC_OSX. I will push it: please (@FlyingJester) try it out on your Gentoo machine and @Radnen/@Neo try it out on windows. :)

It builds! Until it tells me it can't find audiere.

In the next part of our quest, part 2, we will build Audiere and see what else crosses our road.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Rahkiin on April 24, 2014, 08:45:25 am
Building Sphere for OSX: Part 2.

This is part 2 of my adventures, when building Sphere Vanilla from source, for Mac OSX Mavericks. In the previous chapter, I downloaded the sources, installed wxWidgets and changed configurations to exclude the config app (wxMac is broken). I then updated source code of Sphere to fix a lot of warnings and platform errors. (I push these so you don't have to).

If you ever want to reproduce this: sorry for the hasty texts, but when building such a horrible thing, one does not want to write every step down cleanly.

So I downloaded Audiere. It has some odd build system. But i started with ./bootstrap. It told me I had no libtoolize.
A brew install libtool solved that, except I already had libtool. Therefor I symlinked libtoolize to glibtoolize (because brew renamed its packages to not cause conflict.)
Now bootstrap worked, and it generated configure. Running configure succeeds, at try one! Time for make.
Yeah! It has an error! Someone forgot to include stdlib for malloc in utility.h.
Next, error: undeclared identifier wxOPEN. So what is an audio-lib doing with WxWidgets?
It seems to be one of the examples. Fine: remove it from the build. (Makefile SUBDIRS). Done :)
Running make install to install the library.

I fear for Corona...

But first, running 'scons' again on sphere. Surprise: it does not find audiere.h. So I add -I/usr/local/include to the compiler construct, next to -DNO_WRITE_MNG (because I am lazy and have no clue how SCons works).
Now it continues.

Next up: can't find jsapi.h.
It would be cool if such a package with thousands of dependencies could just deliver these dependencies too..
Googling that file sends me directly to SpiderMonkey. I am going to build it from source.

EDIT: In part 3, I discover that downloading the whole tree with history can be avoided by downloading a tar. http://hg.mozilla.org/mozilla-central/file/tip and click on tar at the top. I tried to download with HG so you will find my adventures below. Just don't try it at home (tm).

First, my HG is screwed up due to the Mavericks update, so reinstalling that using brew. After doing a brew doctor and brew link overwrite, HG works again.
Mercurial is surprisingly slower than git... (already waiting 15min)

In part 3 we will be continuing our quest to build Sphere for Mac! We will start by building SpiderMonkey. Because HG takes ages, I might first update gitignore and the buildfiles to skip the config. And then I will push that to git.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Rahkiin on April 24, 2014, 09:15:22 am
There we are, with part 3 of our grand quest to building Sphere for Mac!

In part 2 we installed Audiere, which was a pain due to its dependencies. Then we configured the build to actually see audiere.h. Then I fixed mercurial for Mavericks and started its download. It is still busy. (That is, 7 minutes after posting my last post). Sigh.

So instead, I will fix the code of Sphere and its build configuration, to skip the examples and include the platform.h. If you are someone trying to reproduce what I do: you don't need to do this. I will update the project on GitHub.
I like where I put the include-flag for Audiere, so I keep it there, but I add a comment line for future maintainers.

Somehow, .o files are not excluded from git. Which is odd, because most often that is the first thing you add to gitignore. So I add a UNIX section and add *.o. Git status tells me that there is data in build/linux/docs. On github, it only has an engine.ini in linux/. Excluding the docs folder.
There seems to be some kind of database file for SCons: adding it do gitignore too.

I have seriously no clue how SCons works, but in the SConscript where I removed 'config', there already is a statement to add a folder in case of a unix build. I add an else clause and put config there. Now config is build on everything but Unix.
If another maintainer can tell me how I can add a clause specially for Mac, please :)

Now, HG tells me:
Code: [Select]

added 179880 changesets with 1008534 changes to 155940 files.

It does kind of explain why it took so long. (It is still busy 17 min after my last post).

Great, i accidentally deleted the mozilla directory because I put it in sphere/...
So I forgot to read the SM page, and it tells me: "To avoid downloading the full history, download the tar by clicking on tar at http://hg.mozilla.org/mozilla-central/file/tip". (Updated part 2)
For me, it is 168MB. Now is hoping that SM has a stable API and Sphere can use the latest version.

WARNING: Scroll below, because Sphere is so extremely outdated that it is not fixable for the newest SpiderMonkey. Below, we try to get an ancient (2009) spidermonkey running.

Untar the directory. I never understand the tar command, so i just open the file using 'open ...tar.gz'.
Code: [Select]

open *.tar.gz (name is dependent on last commit id)
cd mozilla-central<tab>
cd js/src


Mozilla tells me I can only use 1 specific version of autoconf: 2.13, and nothing later. Of course I have 2.68. Lets try it anyway.
Code: [Select]

autoconf

And No, it does not work. I think that on this quest, at least one thing has to be wrong with every step...

I must say I am surprised: homebrew tells me there is a 2.13 package for me!
Code: [Select]

brew install homebrew/versions/autoconf213

There was some link problem: I don't think it is a big trouble-file, so I renamed the standards.info to standards.info_bak.
Now that I have autoconf213, lets try it again.

Code: [Select]

autoconf213
./configure

What a fun: I have Python 2.7.2 but we need at least 2.7.3 (but not 3). Brew has python 2.7.6, so lets try:
Code: [Select]

brew install python
brew link python


After running above commands, I had to add the full python 2.7.6 path before ./configure
Code: [Select]

PYTHON=/usr/local/Cellar/python/2.7.6_1/bin/python2.7 ./configure


Now running make.
...
I almost can't believe it: no errors! I finished with make install.

Lets try SCons again on Sphere. Nope, it can't find SM.
Make install installed the headers in  /usr/local/include/-/mozjs-31a1/. Lets fix that by moving it to /usr/local/include/mozjs.
When SCons still can't find the headers, I discovered that it looks only in /usr/bin/mozjs and not in /usr/local/bin/mozjs. I added that searchpath too. I also added an error when it can't find the javascript engine.

So, running scons throws some errors (surprise!):
Code: [Select]

/usr/local/include/mozjs/mozilla/NullPtr.h:17:6: error: "clang version natively supporting nullptr is required."
/usr/local/include/mozjs/js/TypeDecls.h:23:10: fatal error: 'js-config.h' file not found

It also throws a bunch of warnings about C++11. The first error tells me I need to activate C++11 in clang. I added -std=c++11 to the compiler flags for linux, but again, this should only be done when using Clang. But I have no clue how to do that. Maybe other do.

The c++11 switch dismisses a lot of warnings, and the first error. Now, the second error.
For some reason, make install did not install js-config.h. I am lazy and copy it by hand.
Code: [Select]

cp mozilla-central/js/src/js/src/js-config.h /usr/local/include/mozjs/
scons


I forgot to platform-erize network.hpp (I will push this to GitHub ofcourse), solving an error.

Now, I am going to cry for a bit: I see a lot of errors coming from the Sphere engine code about missing JS declarations. Three of them:
Code: [Select]

source/engine/ss_functions.table:6:1: error: unknown type name 'JSBool'
source/particle_engine/ScriptInterface.hpp:87:41: error: use of undeclared identifier 'JS_TRUE'
source/engine/ss_functions.table:16:1: error: unknown type name 'uintN'


It seems JSBool has become bool, JS_TRUE becomes true and JS_FALSE becomes false. That is an easy fix.
The documentation does not say anything about removing uintN: instead, it is noted that uintN is the native unsigned int, and intN is the native int. So I replaced those.

Next problem: JS_AddRoot is gone and made place for more specific functions, as seem https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_AddRoot.

Ok, I think I give up on refactoring all of Sphere's javascript code... The documentation does not event seem to match the current code.

I am rolling back the changes I made to the code, and instead am going to try to get the VERY old SpiderMonkey: from 2009. version 1.8.
Code: [Select]

wget http://ftp.mozilla.org/pub/mozilla.org/js/js-1.8.0-rc1.tar.gz
tar xvzf js-1.8.0-rc1.tar.gz
cd js/src
make BUILD_OPT=1 -f Makefile.ref


Wow, not even a configure! It also fails. Something about assigning to va_list. I know that clang supports va_copy, so I forced that in the faulting file.
Code: [Select]

//#ifdef HAVE_VA_COPY
#define VARARGS_ASSIGN(foo, bar)        va_copy(foo,bar)
//#elif defined(HAVE_VA_LIST_AS_ARRAY)
//#define VARARGS_ASSIGN(foo, bar)        foo[0] = bar[0]
//#else
//#define VARARGS_ASSIGN(foo, bar)        (foo) = (bar)
//#endif


There is no make install, so I did the stuff below to make it work:
Code: [Select]

mkdir /usr/local/include/js
cp js/src/*.{h,tbl} /usr/local/include/js
cp js/src/Darwin_OPT.OBJ/*.h /usr/local/include/js
cp js/src/Darwin_OPT.OBJ/libjs.* /usr/local/lib


Then Sphere built a bit more for me: it now gives me an error on Audiere :(

In this part I tried to get the most up to date SpiderMonkey to run. I achieved that (try the js command) but sadly, Sphere is so outdated that its API is nearly not convertable: at least not in a couple of hours. Instead, I build and installed-by-hand the ancient SpiderMonkey.
In part 4, I will be fixing more errors and I will probably meet the missing Corona and LibMNG.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Rahkiin on April 24, 2014, 12:03:59 pm
This is part 4 of my quest to building Vanilla Sphere for Mac!

In part 3 I tried to use the latest version of SpiderMonkey, which utterly failed because Sphere is extremely outdated. Instead I installed the ancient 1.8 version and it seems to pass that part.

Lets fix more errors!

The Audiere error was a mistake on my side: I forgot to include platform.h in audio.h.

I saw 4 warnings in script.cpp I could easily fix. One of the errors needs to be highlighted:

Code: [Select]

source/engine/script.cpp:5113:10: warning: result of comparison against a string literal is unspecified (use strncmp instead) [-Wstring-compare]
if (name == "")
         ^  ~~

Don't do this! I replaced it with:
Code: [Select]

if (name == NULL || strnlen(name,1) == 0 )


Next up: can't find libmng.h! :) So we can almost conclude that we are done with Audiere and JS.

Brew does not have libmng. http://sourceforge.net/projects/libmng/files/libmng-devel/ has two version: 1.x and 2.x. 2.x seems new: 2013. So we will go with the ancient version (like we did before).

Code: [Select]

cd libmng
./unmaintained/autogen.sh
./configure
make


BOOM! Error. jpeglib.h not found! Ofcourse, it should not Just Work (tm).
Try brew install jpeg, or use this: http://ethan.tira-thompson.com/Mac_OS_X_Ports.html

Code: [Select]

./configure --with-jpeg=/usr/local
make


Still does not work. I added /usr/local/include to DEFAULT_INCLUDES in the Makefile. And now it builds!
Code: [Select]

make
make install


Lets try SCons again. It works! And now we need to build Corona, which is the next complaint.
Get it from http://prdownloads.sourceforge.net/corona/corona-1.0.2.tar.gz?download

Code: [Select]

open corona-1.0.2.tar.gz
<wait>
cd corona-1.0.2
./configure
make

Oh it went so well... png.h not found.

Configure tells me that both png and jpeg cant be found and they therefor won't be supported. That is funny because it means MNG is an empty container :)
After some try-and-error:
Code: [Select]

CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include CXXFLAGS=-I/usr/local/include ./configure


Code: [Select]

OpenPNG.cpp:42:27: error: member access into incomplete type 'png_struct' (aka 'png_struct_def')
    memcpy(jmpbuf, png_ptr->jmpbuf, sizeof(jmp_buf));

Corona is outdated. The struct was removed in 1.5. I do have libs of 1.4 so I switch all the symlinks to libpng15 to libpng14.

Next up: errors when linking: duplicate symbols in libungif!

Derp i accidentally refreshed...
I don't want to rewrite all of it, so a quick rundown:
Fixed the duplicate symbols by removing the linking of libungif in one part (it got linked twice. Then libmng builds.

I had to fix a lot of Sphere by hand in code and the build system. These changes will all be up on the GitHub.

Most 'cant find lib' problems are because they don't look in /usr/local/, which is where all my brew stuff is placed, and almost everything else too.

11:36PM: I have: 'scons: done building targets.'! That is, using the mac video driver and the unix platform code. Lets try to run it.
I think it will fault.

Code: [Select]

Assertion failed: (sizeof(LAYER_HEADER) == 30), function LAYER_HEADER_AssertStructSize__, file source/common/Map.cpp, line 141.

Note to other developers: these assertions can be done at compile time using _Static_assert, if available.

For OSX, it now uses -std=c++11, so I can have static asserts. I then changed ASSERT_STRUCT_SIZE to use static assert when that is available. I also replaced size-sensitive typedefs in types.h to stdint.h types so it always works on 64 bit systems.

I also fixed more warnings and errors that came with the more strict c++11 :)

Lets run it again...
Code: [Select]

dlopen(/Users/jos/Development/SphereVanilla/sphere/sphere/build/mac/system/video/sdl32.so, 1): image not found


That is easy to solve: OSX has dynamic library extensions dyld, and I named them like that, and those files actually exist. So the dlopen call is using the wrong extension.
It is a value in the engine.ini.

And it crashes again:

Code: [Select]

dyld: lazy symbol binding failed: Symbol not found: _DGifOpen
  Referenced from: /usr/local/lib/libcorona-1.0.2.dylib
  Expected in: flat namespace


Honestly, I have no clue anymore. It is now 12:36AM. Committing code and pushing and then it is fine for today.

What I am doing though, is getting engine/mac to work by fixing its code. There's hoping.

This was part 4 of my quest to Building Vanilla Sphere for Mac. In this part I got quite some results: it actually builds. I fixed a lot of warnings and errors and made the build system much nicer, and made it work for OSX. Corona was and is a pain. I don't remember what more I did there, it got lost in a refresh.

The next part, part 5 already, of my quest will put some conclusion to it. I hope to reach my final destination (tm): a working engine. After that, I might go do a part 6, by starting on using Xcode projects and frameworks instead, so that a Sphere.app can be delivered.
However, I am not putting too much time in that as I am making my own engine, Andromeda, which is a completely other quest :)

The commits: https://github.com/sphere-group/sphere/commit/fb598fc58abb8374c856852681abfd2b686dcb45 (https://github.com/sphere-group/sphere/commit/fb598fc58abb8374c856852681abfd2b686dcb45) https://github.com/sphere-group/sphere/commit/5d45b4e4572b46723661f91a7fca65d0b2145eab (https://github.com/sphere-group/sphere/commit/5d45b4e4572b46723661f91a7fca65d0b2145eab)
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on April 24, 2014, 03:55:33 pm
I really recommend using Spidermonkey 1.5. That's what I've been using, and it looks like there will be huge headaches with using anything else.

The issue with libpng and Corona was fixed in my version of Corona, although if you know C or C++ it's an easy fix anyway.

The examples in Audiere are known to just be completely broken.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Rahkiin on April 24, 2014, 05:13:21 pm
Yes well, I got it compiling with 1.8 :) I have no idea how it runs. I am still fixing code of Sphere itself: using Mac video but Unix system.
Also a lot of flags and stuff are different and, it is just generally different.

I accidentally refreshed so I lost quite a lot of my text (everything between fixing corona and fixing a lot of Sphere). :(

Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on April 24, 2014, 10:40:20 pm
Most of the stuff that you are changing is in the Linux code, right?

Ideally, I would hope these changes would only/mostly affect the OS X build. The build is working quite well for Win32 and fairly well for Linux already.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Rahkiin on April 24, 2014, 11:18:21 pm
Almost all code in either in unix (fixing warnings) or in mac yes. And other code is safeguarded with preprocessor directives. I would like if someone made sure I did not screw up tho. :) There is always rollback ghehe.
There were problems in shared code too so I had to fix those. And the buildsystem is shared per definition.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Harry Bo21 on May 13, 2014, 09:16:29 pm
If you updated sphere with Xcode I would literally have your babies... *deep breathing*...
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on July 31, 2014, 06:52:31 pm
It's kind of working on OS X. The thing is, the old Mac video driver is busted big time, and the Unix video drivers kind of...don't work. The SDL32 driver has severely messed up colors (how!?) and does not participate as a proper OS X application (no menu bar, can't get focus), and the SDL_GL driver just has a black screen. I've tried get FJ-GL to work, but there are some issues with it dynamically loading GL symbols (I'll have to face this with TurboSphere at some point, too).

I think the easiest thing would be to port the shader I'm using in FJ-GL to SDL_GL and use that since it can't get an FFP OpenGL context on a modern machine. I'll have a look, and see if I can get FJ-GL working, too. it would be nice to get a working binary for Mavericks.

I also found that Rahkiin was certainly right, I can use libjs 1.7 for Sphere 1.6. I don't even remember why I thought I couldn't. It did require a single modification to compile with the newest version of Clang (related to assigning from variadic arguments...the trick was just to dereference both the lvalue and rvalue and assign by value, which is fine since they are ints). Nice job, Mozilla from 10 years ago, your code still compiles!
Title: Re: Sphere 1.5, 1.6 beta
Post by: Rhuan on October 18, 2014, 11:29:30 am
That weird yellow shifted screenshot looks the way my first compiles of sphere for mac looked before I was helped with getting the endian swaps right.

Are you using any of my old source and somewhere setting the big endian flag?
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on October 20, 2014, 05:42:22 am
Yeah, endian issues were my first guess.

I think your old source was rolled into 1.6 at some point.

I'm using a combination of the Unix sources and the Mac sources. Some of the Mac stuff really doesn't work anymore, and some of the Unix stuff really doesn't work on Mac. Luckily, there seems to be enough of each to get a mostly working engine. The thing is, I'm using the Unix video drivers, so I don't really see how that could be the issue? Unless the endian code was elsewhere?

I poked around a little bit on this, but I didn't see right away how to fix it.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Rhuan on October 20, 2014, 08:14:20 am
Couple of points:

The "old" mac video driver was heavily SDL dependent how is your SDL implementation? Also it was designed to be compiled desperately to the engine app like the windows drivers. (There was then a configuration app as it had various settings)

The endian issues are all addressed when loading resources so you need to look at the code that opens an image or a spriteset etc not the video driver code.

If endian issues are your only problem graphics primaries should work fine so you could try looking at those to see if that's the issue.

Also if it is just an endian matter assuming you've got the latest version of my code you should just need to change a compiler flag, the source shouldn't need any changes.


EDIT: Also I feel obliged to mention that I have an Xcode project for all the dependencies (other than wx and SDL) and then the config, the video drivers and the engine itself I'll try and get it across to one of you shortly. Obviously it's for osx 10.5 so maybe a bit outdated but fundamentally should work.

Thing that should be changed before taking it forward to release is migrating it to a newer version of JS it still uses the old 1.5

EDIT2: looks like it still builds as well except the config tool as I've deleted the version of wxMac it needs (can't re-acquire as this machine has no internet connection) going to clean it a bit then at some point in the next couple of weeks will get it on a memory stick and then to email via a different computer.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on November 04, 2014, 08:38:18 pm
I give you Sphere 1.6 (engine only) for OS X Mavericks and Yosemite.

https://drive.google.com/file/d/0B-hkR9nzCDDKZXdJMnZIOHZqVzQ/view

UPDATE: Use https://drive.google.com/file/d/0B-hkR9nzCDDKaDNFVDliVEYyam8/view (https://drive.google.com/file/d/0B-hkR9nzCDDKaDNFVDliVEYyam8/view)

I've barely tested this at all. If anyone has a newer Mac (it might work back to Snow Leopard, I don't know), please give it a try!

NOTE! This is very much a Unix program right now and doesn't really act like an OS X application. It needs to be run from the terminal in its own directory. I may try to fix that (it's an issue with directory paths in the engine proper, I believe), but for now I figured I would share what I got. It also tries to use ANCIENT oss audio. Which OS X never had as far as I know, and we will likely never see again. Unless someone got CoreAudio working in Audiere, there won't be any sound.

It should work without any extra dependencies, but I've only got a single machine to test it on which has quite a bad case of development library contamination.

I got video working mostly right by backporting more video driver stuff from TurboSphere into FJ-GL, and upgrading the T5 dependency to the newest version. So really, this is very almost a Unix build of Sphere 1.6 with an OS X build of FJ-GL. It still has the old FJ-GL concave polygon issues on some Intel cards (It works fine on my Mac's Intel Iris), and a few bugs with certain blend modes. Please let me know if you find any of these!
Title: Re: Sphere 1.5, 1.6 beta
Post by: N E O on November 06, 2014, 12:41:12 am
I'm running Mavericks on my Air (I'll give specs later) right now. I'll give this a go and report back by the end of the weekend.

Re sound - OSX never had OSS, but CoreAudio with the Core* prefix didn't come about until maybe 10.2 or so.
Title: Re: Sphere 1.5, 1.6 beta
Post by: N E O on November 12, 2014, 02:18:50 pm
Update: running ./engine results in the following error:

Quote

dyld: Library not loaded: Darwin_OPT.OBJ/libjs.dylib
  Referenced from: /Users/lux/Applications/sphere_osx/./engine
  Reason: image not found
Trace/BPT trap: 5


OSX Mavericks 10.9.5
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on November 13, 2014, 07:52:36 am
Oh, well the solution is simple. You just need to guess which version of SpiderMonkey I used, find the unadvertised Mozilla FTP address you can get it at, compile it with the same version of clang I used, install it to the default prefix + Darwin_OPT.OBJ, and then doctor up the install name of the library and the engine binary.

...don't actually do that. Well I mean you could, if you were feeling super adventurous...

I'll fix that up. It'll be pretty simple.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on November 26, 2014, 05:42:33 pm
Here it is.

https://drive.google.com/file/d/0B-hkR9nzCDDKaDNFVDliVEYyam8/view (https://drive.google.com/file/d/0B-hkR9nzCDDKaDNFVDliVEYyam8/view)

That was really weird. I don't really know how it was linking right on my machine.

But now it has SpiderMonkey, and I've changed the engine's link settings to use the local version.
Title: Re: Sphere 1.5, 1.6 beta
Post by: N E O on November 27, 2014, 02:34:39 pm
The following audiere error:

Quote

airlux:sphere_osx lux$ ./engine
dyld: Library not loaded: /usr/local/lib/libvorbisfile.3.dylib
  Referenced from: /Users/lux/Applications/sphere_osx/./libaudiere.dylib
  Reason: image not found
Trace/BPT trap: 5


I have a gut feeling every single audio file supported by audiere will give out an error like this, so this is a thing to look at.

edit: Attempted to put the libs from the 5-year-old https://github.com/rubygame/rubygame-mac-pack (https://github.com/rubygame/rubygame-mac-pack) into /usr/local/lib and get a "mach-o, but wrong architecture" error in my Mavericks, presumably because I'm 64-bit and it's 32-bit. So...it appears that if Sphere OS X is going to continue to support Snow Leopard and Leopard there will need to be separate 32-bit builds. Let's concentrate on 64-bit first.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on November 27, 2014, 07:35:30 pm
I can fix this. I'm betting that a similar issue will exist for Corona.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Fat Cerberus on May 28, 2015, 05:27:23 pm
Wow, reading through the ordeals in this thread again makes me glad minisphere is a thing now. :P. The vanilla engine is so ancient and so broken using modern tools and libraries that it's not really worth maintaining anymore.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on May 28, 2015, 05:40:15 pm
I recently learned that Corona was maintained for a time by someone unrelated to Sphere, who added a lot of useful stuff. Chad Austin then, relatively recently, began maintaining and improving it again.

That, combined with what I've learned about modern SpiderMonkey, almost made me want to try and build a new version of Sphere based on the original sources.

But the biggest issue is that no one really knows how most of the old engine works anymore. Audiere is a particularly thorny library, it doesn't work with newer OS X or Linux (either through OpenAL/CoreAudio or ALSA), only the OSS interface which only BSD and Solaris still use. There is a lot of stuff that is undocumented about the 1.6 branch. There are things that kind of make no sense. It would be pretty easy to work on Sphere 1.6, if I actually had written any part of it.

To be fair, SM 1.8.5 is like Java 6. A lot of stuff is still stuck using it, when it really shouldn't be.

With TurboSphere incorporating the more experimental sphere stuff I work on, it wasn't too appealing to fully grok the old Sphere code. With Minisphere, the other promise of proper compatibility is less interesting as well, since it is rather close, and has not accumulated the 15 years of cruft that Sphere has. For its age and complexity, Sphere's code is easy to read. But 15 years is a long time for any project to be in active development.

Finishing my Unix-based OS X release wouldn't have been too useful, either. No one really wanted it that bad, even me. I've only used my OS X build a handful of times. At that point, truly fixing the underlying issues with my OS X build would be more work than either writing full compatibility wrappers for TurboSphere, trying to make some fork of Minisphere that uses SpiderMonkey, or fixing up my Turbo runtime to work in a pre-ES5 environment.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Fat Cerberus on May 28, 2015, 11:32:26 pm

For its age and complexity, Sphere's code is easy to read.


Believe me, I am very thankful for this.  I reverse-engineered a lot of stuff through playtesting, but there were some things, like zone handling, that required a read of the source.  If the original source weren't as clean as it is, minisphere 1.0 would still probably be in alpha. :P

Nonetheless, some of the algorithms used in it are pretty dumb, like reading strings from a file one character at a time or similar nonsense.  It also violates DRY a lot.  This, for example, happens way too often:
Code: (cpp) [Select]
    if (!m_Engine->IsScriptBeingUsed(m_DefaultMapScripts[which]))
    {
        std::string error;

        if (!ExecuteScript(m_DefaultMapScripts[which], error))
        {
            m_ErrorMessage = "Could not execute default " + list[which] + " map script\n" + error;
            return false;
        }
    }


In minisphere, that functionality is centralized in script.c, so from outside all you see is run_script(s_update_script, false);, which makes the intent much clearer and cuts down on the boilerplate.
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on May 28, 2015, 11:57:21 pm

Nonetheless, some of the algorithms used in it are pretty dumb, like reading strings from a file one character at a time or similar nonsense. 


This isn't as bad as you'd think. Almost all file reading is well buffered on a modern OS (I mean even vaguely modern, think Windows NT, OS X 1.0, Linux 2.6, that stuff and newer). Plus, std::strings aren't naive, and begin with anywhere from 8 to 255 bytes preallocated (older GCC and Apache, respectively). It was just likely never an area that needed much optimization.


It also violates DRY a lot.  This, for example, happens way too often:
Code: (cpp) [Select]
    if (!m_Engine->IsScriptBeingUsed(m_DefaultMapScripts[which]))
    {
        std::string error;

        if (!ExecuteScript(m_DefaultMapScripts[which], error))
        {
            m_ErrorMessage = "Could not execute default " + list[which] + " map script\n" + error;
            return false;
        }
    }


In minisphere, that functionality is centralized in script.c, so from outside all you see is run_script(s_update_script, false);, which makes the intent much clearer and cuts down on the boilerplate.


The part that surprised me was that basically all error messages are not just hard coded that way, they are almost all written inline. TurboSphere is similar in some places, but the basic stuff like argument parsing, number of args, and argument unwrapping/wrapping has system-wide error messages. Similarly, I use a library that is shared between all my plugins to perform script compilation, and it sets the error on the context internally (and can be flagged not to, in case we want to tolerate errors).
Title: Re: Sphere 1.5, 1.6 beta
Post by: FBnil on June 07, 2015, 01:54:11 pm
Is there someone who has compiled 1.6 and has it stable? Is there a place I can read up on compiling in Linux? (seems like the wiki is gone?)
Title: Re: Sphere 1.5, 1.6 beta
Post by: Flying Jester on June 09, 2015, 12:22:36 pm
Stable is relative :)

The code on the github repo https://gihub.com/Sphere-Group/Sphere (https://gihub.com/Sphere-Group/Sphere) should work. You will need a slightly doctored version of Corona (either mine, at https://gihub.com/FlyingJester/Corona (https://gihub.com/FlyingJester/Corona) or Chad Austins at https://gihub.com/ChadAustin/Corona (https://gihub.com/ChadAustin/Corona)), and Audiere https://gihub.com/ChadAustin/Audiere (https://gihub.com/ChadAustin/Audiere). Obviously you will need SM 1.8.5, which OpenSuse still hosts RPMs of. Otherwise, it still compiles pretty easily.

There is no sound with Audiere anymore, since OSS doesn't really exist on Linux anymore. But other than that it works fine.
Title: Re: Sphere 1.5, 1.6 beta
Post by: DaVince on June 09, 2015, 02:15:23 pm

There is no sound with Audiere anymore, since OSS doesn't really exist on Linux anymore. But other than that it works fine.

What about padsp (https://wiki.archlinux.org/index.php/PulseAudio#OSS)?
Title: Re: Sphere 1.5, 1.6 beta
Post by: FBnil on June 09, 2015, 04:37:43 pm
Ok, so what I understand: engine is not functional, it needs replacement of:

The link to SpiderMonkey 31 shows what functions to replace with which, and the current unstable is 38.

That is a huge effort. For now, not too enticing (as we also need to test on Linux, Mac and Windows).

My perspective: I have limited time. I want to start again on the RPG I was making, and get Sphere running on an OpenPandora Handheld. I want to make some testcases to make sure quality is ok (all Sphere forks can benefit of that). My C/C++ is rusty, as is my Javascript.
Several ppl have pointed me to MiniSphere, so I think that is the way to go (I'll miss those particle effects, but most of my gamelibs are vanilla Sphere1.5, so no biggie). And sfxr's can be made online http://www.bfxr.net/ now ... although it was nice for pseudo random sounds.

And of course, I'm curious too to see if SpiderMonkey (JaegerMonky).... whatever... EcmaScript... can work again. But I'd rather help on Sphere-sfml (browser Sphere... huge user base!).


For now I have: migrated from Debian 7 to 8 (2Gb of downloads, at least 3 reboots, and a whole lot of reconfigurations later, I meet the requirements to compile MS). Not sure what I miss, as I still have this error:

Quote
fbnil@tortuga:~/JUMP/minisphere/minisphere$ gcc -o obj/animation.o -c obj/animation.c
In file included from /usr/include/allegro5/internal/alconfig.h:57:0,
                 from /usr/include/allegro5/base.h:50,
                 from /usr/include/allegro5/allegro.h:26,
                 from obj/minisphere.h:23,
                 from obj/animation.c:1:
/usr/include/allegro5/platform/alucfg.h:53:2: error: #error Unix Allegro now REQUIRES pthreads
#error Unix Allegro now REQUIRES pthreads
  ^


Allegro "make" only plays nice if I disable FFMPEG and CG

Allegro for Debian: https://wiki.allegro.cc/index.php?title=Install_Allegro5_From_Git/Linux/Debian

Please note you need to also enable HEAD:
Code: [Select]
git clone git://git.code.sf.net/p/alleg/allegro
cd allegro
git checkout 5.1.3



Brush up your C++:  http://www.entish.org/realquickcpp/realquickcpp.html
Title: Re: Sphere 1.5, 1.6 beta
Post by: Fat Cerberus on June 09, 2015, 04:58:18 pm
I'd like to implement a particle engine in minisphere at some point, so you might not have to go without it for too long.

Allegro sans ffmpeg is fine, I don't use the video component at all.  You do need libmng to build the engine though.  And Allegro 5.1.10 (5.1.3 you have there is too old to support shaders I think, which minisphere requires).

As for that error, it says it right there, you need pthreads.  Presumably you don't have a dev package installed for that...?

Also minisphere is written in pure C, not c++.
Title: Re: Sphere 1.5, 1.6 beta
Post by: FBnil on June 09, 2015, 06:19:02 pm
Thanks a lot! I had to go to 5.1.10, recompile allegro, and scons now continues.

Quote
galileo.c:(.text+0x70a): undefined reference to `al_destroy_vertex_buffer'

Strange, because I do have...
/usr/include/allegro5/allegro_primitives.h:ALLEGRO_PRIM_FUNC(void, al_destroy_vertex_buffer, (ALLEGRO_VERTEX_BUFFER* buffer));
Had to clear out manually the old allegro .so files... although they seem to coexist happily... probably still an old header files somewhere... hunt continues tomorrow...


About the OSS wrapper : I remember using that some years ago, it made the game sound a bit stuttery. not unbearable. I guess now with faster computers it should not matter all that much.