marathon-devel — Development-related discussion

Re: [M-dev] 60fps!

[Solra B. <sb...@te...>]

I tested it with a mouse, both with and without Accelerate Mouse, and
didn't experience any difference from the vanilla experience. There
goes that theory. The only problem I've personally encountered that
isn't fixed yet is the polygon sorting freeze, which happens about
once every five hours of gameplay. (I'm almost certain it's because
I'm being lazy about determining the camera polygon.)

I'd like people (especially people on Windows and MacOS) to test it
and submit issues on GitHub if there are any problems. I'd especially
like to hear more about Darren's problem.

Re: [M-dev] 60fps!

[Darren W. <dd...@gm...>]

Sorry, meant to type that I'm NOT on my linux computer right now.

On Wed, Aug 24, 2016 at 8:57 PM, Darren Watts <dd...@gm...> wrote:

> I'm on on my linux computer right now so I can't validate my preferences
> for sure, but yes I am using the mouse, and I typically uncheck the box to
> accelerate the mouse.  Assuming that build was using the regular
> preferences file, it was probably not accelerating the mouse.  What I saw
> was far more than 15ms.  The input lag seemed pretty random and seemed to
> go anywhere from 30-1000 ms.  I think on a number of occasions I pushed the
> mouse button and the gun did not fire at all, or there was a delay of 1-2
> seconds.  It's hard to say for sure, because usually when it didn't fire,
> I'd instinctively click the button again.
>
> On Wed, Aug 24, 2016 at 8:25 PM, Solra Bizna <sb...@te...> wrote:
>
>> On Tue, Aug 23, 2016 at 7:18 PM, Darren Watts <dd...@gm...> wrote:
>> > I was holding off on saying anything, because I don't know how far into
>> > development it is, yet.  So far I was able to get 60fps, but the
>> controls
>> > were very unresponsive, and I'd call it "unplayable" in its current
>> state.
>> > I tried it about a week ago though, so maybe there have been updates
>> since
>> > then.
>> I've logged over 12 hours of testing since I did the first push. I
>> haven't experienced unresponsiveness of any kind, other than an
>> imperceptible (and expected) ~15ms perceived input latency. What I
>> _have_ experienced is the occasional freeze, which I'm still working
>> on. By any chance, are you using a mouse to aim, and if you are, do
>> you have Accelerate Mouse on? I've been playing keyboard-only, because
>> my "work" machine has a trackpad, and trackpad Marathon is
>> intolerable...
>>
>> ------------------------------------------------------------
>> ------------------
>> _______________________________________________
>> Marathon-devel mailing list
>> Mar...@li...
>> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>>
>
>

Re: [M-dev] 60fps!

[Darren W. <dd...@gm...>]

I'm on on my linux computer right now so I can't validate my preferences
for sure, but yes I am using the mouse, and I typically uncheck the box to
accelerate the mouse.  Assuming that build was using the regular
preferences file, it was probably not accelerating the mouse.  What I saw
was far more than 15ms.  The input lag seemed pretty random and seemed to
go anywhere from 30-1000 ms.  I think on a number of occasions I pushed the
mouse button and the gun did not fire at all, or there was a delay of 1-2
seconds.  It's hard to say for sure, because usually when it didn't fire,
I'd instinctively click the button again.

On Wed, Aug 24, 2016 at 8:25 PM, Solra Bizna <sb...@te...> wrote:

> On Tue, Aug 23, 2016 at 7:18 PM, Darren Watts <dd...@gm...> wrote:
> > I was holding off on saying anything, because I don't know how far into
> > development it is, yet.  So far I was able to get 60fps, but the controls
> > were very unresponsive, and I'd call it "unplayable" in its current
> state.
> > I tried it about a week ago though, so maybe there have been updates
> since
> > then.
> I've logged over 12 hours of testing since I did the first push. I
> haven't experienced unresponsiveness of any kind, other than an
> imperceptible (and expected) ~15ms perceived input latency. What I
> _have_ experienced is the occasional freeze, which I'm still working
> on. By any chance, are you using a mouse to aim, and if you are, do
> you have Accelerate Mouse on? I've been playing keyboard-only, because
> my "work" machine has a trackpad, and trackpad Marathon is
> intolerable...
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>

Re: [M-dev] 60fps!

[Solra B. <sb...@te...>]

On Tue, Aug 23, 2016 at 7:18 PM, Darren Watts <dd...@gm...> wrote:
> I was holding off on saying anything, because I don't know how far into
> development it is, yet.  So far I was able to get 60fps, but the controls
> were very unresponsive, and I'd call it "unplayable" in its current state.
> I tried it about a week ago though, so maybe there have been updates since
> then.
I've logged over 12 hours of testing since I did the first push. I
haven't experienced unresponsiveness of any kind, other than an
imperceptible (and expected) ~15ms perceived input latency. What I
_have_ experienced is the occasional freeze, which I'm still working
on. By any chance, are you using a mouse to aim, and if you are, do
you have Accelerate Mouse on? I've been playing keyboard-only, because
my "work" machine has a trackpad, and trackpad Marathon is
intolerable...

Re: [M-dev] 60fps!

[Darren W. <dd...@gm...>]

I was holding off on saying anything, because I don't know how far into
development it is, yet.  So far I was able to get 60fps, but the controls
were very unresponsive, and I'd call it "unplayable" in its current state.
I tried it about a week ago though, so maybe there have been updates since
then.

On Tue, Aug 23, 2016 at 3:17 PM, Bob Chamot <bo...@ch...> wrote:

> Well, if no one else is going to say anything...
>
> This is wonderful to hear!  I hope I can try it out sometime.  What are
> the chances of this seeing its way into an official build?
>
> For your next trick, any interest in squeezing more frogblasts into a
> circle? ;)
>
> Sent from my iPhone
>
> > On Aug 15, 2016, at 1:32 AM, Solra Bizna <sb...@te...> wrote:
> >
> > I'm surprised at how easy it was to get this far. I only started
> > working on it four hours ago, and I already have working (partial)
> > 60fps support. It only tweens the player's view and the positions of
> > objects, but this alone makes a huge difference to the experience. In
> > its current state, it's a step up from the non-30fps support that Halo
> > for PC had; Halo only tweens the player's view.
> >
> > If you leave the framerate target setting at the default 30fps,
> > nothing will change. Only if you change that setting does the new
> > timing and rendering logic even apply. (Note that the built-in
> > framerate measurement has always been wrong. I made it less wrong, but
> > it still seems to be _slightly_ wrong, and I'm not sure why.)
> >
> > Film, save, and network compatibility are not affected, but netplay
> > and non-realtime film playback are likely to be hilarious jitterfests
> > in the current version. For now, set the target to 30fps when doing
> > those things. Depending on how hard it is to fix those, I may end up
> > forcing 30fps in either or both circumstances.
> >
> > Interested parties who can build Aleph One from source can check it
> > out on GitHub: https://github.com/SolraBizna/alephone Make sure you
> > check out the 60fps branch before building.
> >
> > P.S. It's ironic that, almost exactly 10 years ago, I was dashing
> > someone's dreams for silken Marathon, insisting that implementing it
> > would be "hugely complicated for a fairly minor return."
> >
> > ------------------------------------------------------------
> ------------------
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols
> are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports. http://sdm.link/zohodev2dev
> > _______________________________________________
> > Marathon-devel mailing list
> > Mar...@li...
> > https://lists.sourceforge.net/lists/listinfo/marathon-devel
> >
>
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>

Re: [M-dev] 60fps!

[Bob C. <bo...@ch...>]

Well, if no one else is going to say anything...

This is wonderful to hear!  I hope I can try it out sometime.  What are the chances of this seeing its way into an official build?

For your next trick, any interest in squeezing more frogblasts into a circle? ;)

Sent from my iPhone

> On Aug 15, 2016, at 1:32 AM, Solra Bizna <sb...@te...> wrote:
> 
> I'm surprised at how easy it was to get this far. I only started
> working on it four hours ago, and I already have working (partial)
> 60fps support. It only tweens the player's view and the positions of
> objects, but this alone makes a huge difference to the experience. In
> its current state, it's a step up from the non-30fps support that Halo
> for PC had; Halo only tweens the player's view.
> 
> If you leave the framerate target setting at the default 30fps,
> nothing will change. Only if you change that setting does the new
> timing and rendering logic even apply. (Note that the built-in
> framerate measurement has always been wrong. I made it less wrong, but
> it still seems to be _slightly_ wrong, and I'm not sure why.)
> 
> Film, save, and network compatibility are not affected, but netplay
> and non-realtime film playback are likely to be hilarious jitterfests
> in the current version. For now, set the target to 30fps when doing
> those things. Depending on how hard it is to fix those, I may end up
> forcing 30fps in either or both circumstances.
> 
> Interested parties who can build Aleph One from source can check it
> out on GitHub: https://github.com/SolraBizna/alephone Make sure you
> check out the 60fps branch before building.
> 
> P.S. It's ironic that, almost exactly 10 years ago, I was dashing
> someone's dreams for silken Marathon, insisting that implementing it
> would be "hugely complicated for a fairly minor return."
> 
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel
> 

[M-dev] 60fps!

[Solra B. <sb...@te...>]

I'm surprised at how easy it was to get this far. I only started
working on it four hours ago, and I already have working (partial)
60fps support. It only tweens the player's view and the positions of
objects, but this alone makes a huge difference to the experience. In
its current state, it's a step up from the non-30fps support that Halo
for PC had; Halo only tweens the player's view.

If you leave the framerate target setting at the default 30fps,
nothing will change. Only if you change that setting does the new
timing and rendering logic even apply. (Note that the built-in
framerate measurement has always been wrong. I made it less wrong, but
it still seems to be _slightly_ wrong, and I'm not sure why.)

Film, save, and network compatibility are not affected, but netplay
and non-realtime film playback are likely to be hilarious jitterfests
in the current version. For now, set the target to 30fps when doing
those things. Depending on how hard it is to fix those, I may end up
forcing 30fps in either or both circumstances.

Interested parties who can build Aleph One from source can check it
out on GitHub: https://github.com/SolraBizna/alephone Make sure you
check out the 60fps branch before building.

P.S. It's ironic that, almost exactly 10 years ago, I was dashing
someone's dreams for silken Marathon, insisting that implementing it
would be "hugely complicated for a fairly minor return."

Re: [M-dev] C++11?

[Bruce M. <hip...@bu...>]

No it plays the same. But run/walk is on the analogue stick, instead of a run key. 

I assure you we were extremely careful to match gameplay. 

-Bruce

> On Aug 13, 2016, at 9:45 PM, Brandon Smith <st...@ml...> wrote:
> 
> The issue with the 360 port is the game "plays" way faster than it 
> should. It seems they upped the FPS, which also caused the game to play 
> much faster. To me at least it feels very wrong, but then I grew up 
> playing the originals.
> 
> -Brandon
> 
>> On 8/13/16 3:50 PM, Solra Bizna wrote:
>>> On Sat, Aug 13, 2016 at 12:12 PM, Darren Watts <dd...@gm...> wrote:
>>> I don't know the answer to your question, but hippieman (who worked on the
>>> xbox 360 port) recently posted something on reddit related to this subject
>>> that you might find interesting
>>> https://www.reddit.com/r/Marathon/comments/4ux35w/60_fps/.
>> I didn't realize the 360 port ran at 60tps. Interesting. That breaks
>> film compatibility, which a lot of people recently worked *very* hard
>> on---but which doesn't matter to the 360 port one bit.
>> 
>> Fortunately for me, I wasn't planning to increase the tickrate, only
>> the framerate. Games with tickrates as low as 12tps can look
>> smooth(ish) through the magic of interpolation.
>> 
>> ------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning reports. http://sdm.link/zohodev2dev
>> _______________________________________________
>> Marathon-devel mailing list
>> Mar...@li...
>> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>> 
>> 
> 
> 
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel

Re: [M-dev] C++11?

[Brandon S. <st...@ml...>]

The issue with the 360 port is the game "plays" way faster than it 
should. It seems they upped the FPS, which also caused the game to play 
much faster. To me at least it feels very wrong, but then I grew up 
playing the originals.

-Brandon

On 8/13/16 3:50 PM, Solra Bizna wrote:
> On Sat, Aug 13, 2016 at 12:12 PM, Darren Watts <dd...@gm...> wrote:
>> I don't know the answer to your question, but hippieman (who worked on the
>> xbox 360 port) recently posted something on reddit related to this subject
>> that you might find interesting
>> https://www.reddit.com/r/Marathon/comments/4ux35w/60_fps/.
> I didn't realize the 360 port ran at 60tps. Interesting. That breaks
> film compatibility, which a lot of people recently worked *very* hard
> on---but which doesn't matter to the 360 port one bit.
>
> Fortunately for me, I wasn't planning to increase the tickrate, only
> the framerate. Games with tickrates as low as 12tps can look
> smooth(ish) through the magic of interpolation.
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>
>

Re: [M-dev] C++11?

[Solra B. <sb...@te...>]

On Sat, Aug 13, 2016 at 12:12 PM, Darren Watts <dd...@gm...> wrote:
> I don't know the answer to your question, but hippieman (who worked on the
> xbox 360 port) recently posted something on reddit related to this subject
> that you might find interesting
> https://www.reddit.com/r/Marathon/comments/4ux35w/60_fps/.
I didn't realize the 360 port ran at 60tps. Interesting. That breaks
film compatibility, which a lot of people recently worked *very* hard
on---but which doesn't matter to the 360 port one bit.

Fortunately for me, I wasn't planning to increase the tickrate, only
the framerate. Games with tickrates as low as 12tps can look
smooth(ish) through the magic of interpolation.

Re: [M-dev] C++11?

[Darren W. <dd...@gm...>]

I don't know the answer to your question, but hippieman (who worked on the
xbox 360 port) recently posted something on reddit related to this subject
that you might find interesting
https://www.reddit.com/r/Marathon/comments/4ux35w/60_fps/.

On Sat, Aug 13, 2016 at 11:17 AM, Solra Bizna <sb...@te...> wrote:

> The wheel of life has brought me into Marathon territory once again.
> I've been doing preliminary work to see about repealing the 30 FPS
> limit. I have a pretty good idea of what needs to be done, but before
> I can begin work I have one big question:
>
> Are any of the official build environments still lacking C++11 support?
>
> I ask because C++11's built-in timing facilities are significantly
> less jittery than SDL_GetTicks/SDL_Delay, in practice. At 30fps the
> jitter is less than ten percent, but at framerates near and above 60
> it starts to make a huge difference. Since I'm going to have to hugely
> alter the game's timing code anyway, I'd like to replace it with
> something better. I don't want a repeat of the time when a patch of
> mine got stalled because the Windows build environment was still stuck
> on OpenGL 1.1...
>
> ------------------------------------------------------------
> ------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>

[M-dev] C++11?

[Solra B. <sb...@te...>]

The wheel of life has brought me into Marathon territory once again.
I've been doing preliminary work to see about repealing the 30 FPS
limit. I have a pretty good idea of what needs to be done, but before
I can begin work I have one big question:

Are any of the official build environments still lacking C++11 support?

I ask because C++11's built-in timing facilities are significantly
less jittery than SDL_GetTicks/SDL_Delay, in practice. At 30fps the
jitter is less than ten percent, but at framerates near and above 60
it starts to make a huge difference. Since I'm going to have to hugely
alter the game's timing code anyway, I'd like to replace it with
something better. I don't want a repeat of the time when a patch of
mine got stalled because the Windows build environment was still stuck
on OpenGL 1.1...

[M-dev] Aleph One 1.2

[Jeremiah M. <jm...@wh...>]

Aleph One 1.2 is now available from http://marathon.sourceforge.net/

Aleph One 1.2 features online leaderboards and game statistics, a streamlined saved-game system, and full multiplayer support for the original Marathon game. This release also includes a number of other new features and bug fixes.

If you do not use the bundled downloads, we recommend that you update your scenario files. Each game includes a new plugin for the online leaderboards, and the Marathon scenario includes an important compatibility fix.

For more details, please read the full release notes:

https://sourceforge.net/projects/marathon/files/Aleph%20One/2015-06-19/#readme

Re: [M-dev] Alephone crash on PPC linux

[Jeremiah M. <jm...@wh...>]

Also, be sure to run make as well as configure:

CXXFLAGS="-g" ./configure
make
./Source_Files/alephone

- JM


> On Mar 10, 2015, at 8:35 AM, Gregory Smith <wo...@tr...> wrote:
> 
> Thanks. Can you run the version you compiled with symbols and do the same?
> 
> ~/Downloads/AlephOne-20140104/Source_Files/alephone
> 
> Then the backtrace will include the function names where it crashed.
> 
> Gregory
> 
> On Tue, Mar 10, 2015 at 8:16 AM, David Howe <how...@gm...> wrote:
>> As suggested, I recompiled with symbols ie
>> 
>> CXXFLAGS="-g" ./configure
>> 
>> 
>> and I get this (full backtrace)
>> 
>> 
>> 
>>> david@G5:~/Downloads/AlephOne-20140104$ /usr/local/bin/alephone
>>> Aleph One Linux 2014-01-04 1.1
>>> http://marathon.sourceforge.net/
>> 
>>> Original code by Bungie Software <http://www.bungie.com/>
>>> Additional work by Loren Petrich, Chris Pruett, Rhys Hill et al.
>>> TCP/IP networking by Woody Zenfell
>>> Expat XML library by James Clark
>>> SDL port by Christian Bauer <Chr...@un...>
>>> 
>>> This is free software with ABSOLUTELY NO WARRANTY.
>>> You are welcome to redistribute it under certain conditions.
>>> For details, see the file COPYING.
>>> 
>>> Built with network play enabled.
>>> 
>>> Built with Lua scripting enabled.
>>> *** glibc detected *** /usr/local/bin/alephone: double free or
>> corruption (out): 0x1181e2f8 ***
>>> ======= Backtrace: =========

Re: [M-dev] Alephone crash on PPC linux

[Gregory S. <wo...@tr...>]

Thanks. Can you run the version you compiled with symbols and do the same?

~/Downloads/AlephOne-20140104/Source_Files/alephone

Then the backtrace will include the function names where it crashed.

Gregory

On Tue, Mar 10, 2015 at 8:16 AM, David Howe <how...@gm...> wrote:
> As suggested, I recompiled with symbols ie
>
> CXXFLAGS="-g" ./configure
>
>
> and I get this (full backtrace)
>
>
>
>  >david@G5:~/Downloads/AlephOne-20140104$ /usr/local/bin/alephone
>  >Aleph One Linux 2014-01-04 1.1
>  >http://marathon.sourceforge.net/
>
>  >Original code by Bungie Software <http://www.bungie.com/>
>  >Additional work by Loren Petrich, Chris Pruett, Rhys Hill et al.
>  >TCP/IP networking by Woody Zenfell
>  >Expat XML library by James Clark
>  >SDL port by Christian Bauer <Chr...@un...>
>  >
>  >This is free software with ABSOLUTELY NO WARRANTY.
>  >You are welcome to redistribute it under certain conditions.
>  >For details, see the file COPYING.
>  >
>  >Built with network play enabled.
>  >
>  >Built with Lua scripting enabled.
>  >*** glibc detected *** /usr/local/bin/alephone: double free or
> corruption (out): 0x1181e2f8 ***
>  >======= Backtrace: =========
>  >/lib/powerpc-linux-gnu/libc.so.6(+0x85be4)[0xea25be4]
>  >/lib/powerpc-linux-gnu/libc.so.6(cfree+0x8c)[0xea2b29c]
>  >/usr/local/bin/alephone[0x101f502c]
>  >/usr/local/bin/alephone[0x10201a2c]
>  >/usr/local/bin/alephone[0x1020a464]
>  >/usr/local/bin/alephone[0x101fd750]
>  >/usr/local/bin/alephone[0x101fea6c]
>  >/usr/local/bin/alephone[0x101ff530]
>  >/usr/local/bin/alephone[0x1020e9ac]
>  >/usr/local/bin/alephone[0x101fc398]
>  >/usr/local/bin/alephone[0x101fb774]
>  >/usr/local/bin/alephone[0x101fc6bc]
>  >/usr/local/bin/alephone[0x101f4708]
>  >/usr/local/bin/alephone[0x10274a88]
>  >/usr/local/bin/alephone[0x10274bac]
>  >/usr/local/bin/alephone[0x10275650]
>  >/usr/local/bin/alephone[0x10484b58]
>  >/usr/local/bin/alephone[0x104b88d0]
>  >/usr/local/bin/alephone[0x10287684]
>  >/usr/local/bin/alephone[0x1000d4c8]
>  >/usr/local/bin/alephone[0x1000b8ec]
>  >/lib/powerpc-linux-gnu/libc.so.6(+0x1fd0c)[0xe9bfd0c]
>  >/lib/powerpc-linux-gnu/libc.so.6(+0x1fed0)[0xe9bfed0]
>  >======= Memory map: ========
>  >00100000-00103000 r-xp 00000000 00:00
> 0                                  [vdso]
>  >0ced5000-0cede000 r-xp 00000000 08:03 14291149
> /usr/lib/powerpc-linux->gnu/libXrender.so.1.3.0
>  >0cede000-0ceed000 ---p 00009000 08:03 14291149
> /usr/lib/powerpc-linux-gnu/libXrender.so.1.3.0
> 0ceed000-0ceee000 rw-p 00008000 08:03 14291149
> /usr/lib/powerpc-linux-gnu/libXrender.so.1.3.0
> 0cefe000-0cf07000 r-xp 00000000 08:03 14291760
> /usr/lib/powerpc-linux-gnu/libXcursor.so.1.0.2
> 0cf07000-0cf17000 ---p 00009000 08:03 14291760
> /usr/lib/powerpc-linux-gnu/libXcursor.so.1.0.2
> 0cf17000-0cf18000 rw-p 00009000 08:03 14291760
> /usr/lib/powerpc-linux-gnu/libXcursor.so.1.0.2
> 0cf28000-0cf34000 r-xp 00000000 08:03 3556477
> /lib/powerpc-linux-gnu/libnss_files-2.13.so
> 0cf34000-0cf43000 ---p 0000c000 08:03 3556477
> /lib/powerpc-linux-gnu/libnss_files-2.13.so
> 0cf43000-0cf44000 r--p 0000b000 08:03 3556477
> /lib/powerpc-linux-gnu/libnss_files-2.13.so
> 0cf44000-0cf45000 rw-p 0000c000 08:03 3556477
> /lib/powerpc-linux-gnu/libnss_files-2.13.so
> 0cf55000-0cf60000 r-xp 00000000 08:03 3556473
> /lib/powerpc-linux-gnu/libnss_nis-2.13.so
> 0cf60000-0cf6f000 ---p 0000b000 08:03 3556473
> /lib/powerpc-linux-gnu/libnss_nis-2.13.so
> 0cf6f000-0cf70000 r--p 0000a000 08:03 3556473
> /lib/powerpc-linux-gnu/libnss_nis-2.13.so
> 0cf70000-0cf71000 rw-p 0000b000 08:03 3556473
> /lib/powerpc-linux-gnu/libnss_nis-2.13.so
> 0cf81000-0cf89000 r-xp 00000000 08:03 3556465
> /lib/powerpc-linux-gnu/libnss_compat-2.13.so
> 0cf89000-0cf98000 ---p 00008000 08:03 3556465
> /lib/powerpc-linux-gnu/libnss_compat-2.13.so
> 0cf98000-0cf99000 r--p 00007000 08:03 3556465
> /lib/powerpc-linux-gnu/libnss_compat-2.13.so
> 0cf99000-0cf9a000 rw-p 00008000 08:03 3556465
> /lib/powerpc-linux-gnu/libnss_compat-2.13.so
> 0cfaa000-0cfbd000 r-xp 00000000 08:03 3556479
> /lib/powerpc-linux-gnu/libresolv-2.13.so
> 0cfbd000-0cfcd000 ---p 00013000 08:03 3556479
> /lib/powerpc-linux-gnu/libresolv-2.13.so
> 0cfcd000-0cfce000 r--p 00013000 08:03 3556479
> /lib/powerpc-linux-gnu/libresolv-2.13.so
> 0cfce000-0cfcf000 rw-p 00014000 08:03 3556479
> /lib/powerpc-linux-gnu/libresolv-2.13.so
> 0cfcf000-0cfd1000 rw-p 00000000 00:00 0
> 0cfe1000-0d02c000 r-xp 00000000 08:03 14293313
> /usr/lib/powerpc-linux-gnu/libFLAC.so.8.2.0
> 0d02c000-0d03b000 ---p 0004b000 08:03 14293313
> /usr/lib/powerpc-linux-gnu/libFLAC.so.8.2.0
> 0d03b000-0d03c000 r--p 0004a000 08:03 14293313
> /usr/lib/powerpc-linux-gnu/libFLAC.so.8.2.0
> 0d03c000-0d03d000 rw-p 0004b000 08:03 14293313
> /usr/lib/powerpc-linux-gnu/libFLAC.so.8.2.0
> 0d04d000-0d063000 r-xp 00000000 08:03 3556485
> /lib/powerpc-linux-gnu/libnsl-2.13.so
> 0d063000-0d073000 ---p 00016000 08:03 3556485
> /lib/powerpc-linux-gnu/libnsl-2.13.so
> 0d073000-0d074000 r--p 00016000 08:03 3556485
> /lib/powerpc-linux-gnu/libnsl-2.13.so
> 0d074000-0d075000 rw-p 00017000 08:03 3556485
> /lib/powerpc-linux-gnu/libnsl-2.13.so
> 0d075000-0d077000 rw-p 00000000 00:00 0
> 0d087000-0d097000 r-xp 00000000 08:03 14291762
> /usr/lib/powerpc-linux-gnu/libXi.so.6.1.0
> 0d097000-0d0a6000 ---p 00010000 08:03 14291762
> /usr/lib/powerpc-linux-gnu/libXi.so.6.1.0
> 0d0a6000-0d0a7000 rw-p 0000f000 08:03 14291762
> /usr/lib/powerpc-linux-gnu/libXi.so.6.1.0
> 0d0b7000-0d0bb000 r-xp 00000000 08:03 3555402
> /lib/powerpc-linux-gnu/libuuid.so.1.3.0
> 0d0bb000-0d0cb000 ---p 00004000 08:03 3555402
> /lib/powerpc-linux-gnu/libuuid.so.1.3.0
> 0d0cb000-0d0cc000 r--p 00004000 08:03 3555402
> /lib/powerpc-linux-gnu/libuuid.so.1.3.0
> 0d0cc000-0d0cd000 rw-p 00005000 08:03 3555402
> /lib/powerpc-linux-gnu/libuuid.so.1.3.0
> 0d0dd000-0d0e1000 r-xp 00000000 08:03 3555376
> /lib/powerpc-linux-gnu/libattr.so.1.1.0
> 0d0e1000-0d0f1000 ---p 00004000 08:03 3555376
> /lib/powerpc-linux-gnu/libattr.so.1.1.0
> 0d0f1000-0d0f2000 r--p 00004000 08:03 3555376
> /lib/powerpc-linux-gnu/libattr.so.1.1.0
> 0d0f2000-0d0f3000 rw-p 00005000 08:03 3555376
> /lib/powerpc-linux-gnu/libattr.so.1.1.0
> 0d103000-0d107000 r-xp 00000000 08:03 14293311
> /usr/lib/powerpc-linux-gnu/libasyncns.so.0.3.1
> 0d107000-0d117000 ---p 00004000 08:03 14293311
> /usr/lib/powerpc-linux-gnu/libasyncns.so.0.3.1
> 0d117000-0d118000 rw-p 00004000 08:03 14293311
> /usr/lib/powerpc-linux-gnu/libasyncns.so.0.3.1
> 0d128000-0d192000 r-xp 00000000 08:03 14293317
> /usr/lib/powerpc-linux-gnu/libsndfile.so.1.0.25
> 0d192000-0d1a2000 ---p 0006a000 08:03 14293317
> /usr/lib/powerpc-linux-gnu/libsndfile.so.1.0.25
> 0d1a2000-0d1a5000 r--p 0006a000 08:03 14293317
> /usr/lib/powerpc-linux-gnu/libsndfile.so.1.0.25
> 0d1a5000-0d1a6000 rw-p 0006d000 08:03 14293317
> /usr/lib/powerpc-linux-gnu/libsndfile.so.1.0.25
> 0d1a6000-0d1aa000 rw-p 00000000 00:00 0
> 0d1ba000-0d1c2000 r-xp 00000000 08:03 3555802
> /lib/powerpc-linux-gnu/libwrap.so.0.7.6
> 0d1c2000-0d1d2000 ---p 00008000 08:03 3555802
> /lib/powerpc-linux-gnu/libwrap.so.0.7.6
> 0d1d2000-0d1d3000 r--p 00008000 08:03 3555802
> /lib/powerpc-linux-gnu/libwrap.so.0.7.6
> 0d1d3000-0d1d4000 rw-p 00009000 08:03 3555802
> /lib/powerpc-linux-gnu/libwrap.so.0.7.6
> 0d1e4000-0d1e9000 r-xp 00000000 08:03 14293215
> /usr/lib/powerpc-linux-gnu/libXtst.so.6.1.0
> 0d1e9000-0d1f9000 ---p 00005000 08:03 14293215
> /usr/lib/powerpc-linux-gnu/libXtst.so.6.1.0
> 0d1f9000-0d1fa000 rw-p 00005000 08:03 14293215
> /usr/lib/powerpc-linux-gnu/libXtst.so.6.1.0
> 0d20a000-0d211000 r-xp 00000000 08:03 14292542
> /usr/lib/powerpc-linux-gnu/libSM.so.6.0.1
> 0d211000-0d220000 ---p 00007000 08:03 14292542
> /usr/lib/powerpc-linux-gnu/libSM.so.6.0.1
> 0d220000-0d221000 rw-p 00006000 08:03 14292542
> /usr/lib/powerpc-linux-gnu/libSM.so.6.0.1
> 0d231000-0d247000 r-xp 00000000 08:03 14292540
> /usr/lib/powerpc-linux-gnu/libICE.so.6.3.0
> 0d247000-0d256000 ---p 00016000 08:03 14292540
> /usr/lib/powerpc-linux-gnu/libICE.so.6.3.0
> 0d256000-0d257000 rw-p 00015000 08:03 14292540
> /usr/lib/powerpc-linux-gnu/libICE.so.6.3.0
> 0d257000-0d259000 rw-p 00000000 00:00 0
> 0d269000-0d26c000 r-xp 00000000 08:03 3555479
> /lib/powerpc-linux-gnu/libgpg-error.so.0.8.0
> 0d26c000-0d27b000 ---p 00003000 08:03 3555479
> /lib/powerpc-linux-gnu/libgpg-error.so.0.8.0
> 0d27b000-0d27c000 rw-p 00002000 08:03 3555479
> /lib/powerpc-linux-gnu/libgpg-error.so.0.8.0
> 0d28c000-0d291000 r-xp 00000000 08:03 14290999
> /usr/lib/powerpc-linux-gnu/libXdmcp.so.6.0.0
> 0d291000-0d2a0000 ---p 00005000 08:03 14290999
> /usr/lib/powerpc-linux-gnu/libXdmcp.so.6.0.0
> 0d2a0000-0d2a1000 rw-p 00004000 08:03 14290999
> /usr/lib/powerpc-linux-gnu/libXdmcp.so.6.0.0
> 0d2b1000-0d2b3000 r-xp 00000000 08:03 14290997
> /usr/lib/powerpc-linux-gnu/libXau.so.6.0.0
> 0d2b3000-0d2c3000 ---p 00002000 08:03 14290997
> /usr/lib/powerpc-linux-gnu/libXau.so.6.0.0
> 0d2c3000-0d2c4000 rw-p 00002000 08:03 14290997
> /usr/lib/powerpc-linux-gnu/libXau.so.6.0.0
> 0d2d4000-0d2f3000 r-xp 00000000 08:03 3555368
> /lib/powerpc-linux-gnu/libtinfo.so.5.9
> 0d2f3000-0d303000 ---p 0001f000 08:03 3555368
> /lib/powerpc-linux-gnu/libtinfo.so.5.9
> 0d303000-0d305000 r--p 0001f000 08:03 3555368
> /lib/powerpc-linux-gnu/libtinfo.so.5.9
> 0d305000-0d306000 rw-p 00021000 08:03 3555368
> /lib/powerpc-linux-gnu/libtinfo.so.5.9
> 0d316000-0d343000 r-xp 00000000 08:03 3555483
> /lib/powerpc-linux-gnu/libncursesw.so.5.9
> 0d343000-0d352000 ---p 0002d000 08:03 3555483
> /lib/powerpc-linux-gnu/libncursesw.so.5.9
> 0d352000-0d353000 r--p 0002c000 08:03 3555483
> /lib/powerpc-linux-gnu/libncursesw.so.5.9
> 0d353000-0d354000 rw-p 0002d000 08:03 3555483
> /lib/powerpc-linux-gnu/libncursesw.so.5.9
> 0d364000-0d498000 r-xp 00000000 08:03 3555417
> /lib/powerpc-linux-gnu/libslang.so.2.2.4
> 0d498000-0d4a8000 ---p 00134000 08:03 3555417
> /lib/powerpc-linux-gnu/libslang.so.2.2.4
> 0d4a8000-0d4ac000 r--p 00134000 08:03 3555417
> /lib/powerpc-linux-gnu/libslang.so.2.2.4
> 0d4ac000-0d4bb000 rw-p 00138000 08:03 3555417
> /lib/powerpc-linux-gnu/libslang.so.2.2.4
> 0d4bb000-0d4f9000 rw-p 00000000 00:00 0
> 0d509000-0d550000 r-xp 00000000 08:03 3555804
> /lib/powerpc-linux-gnu/libdbus-1.so.3.7.2
> 0d550000-0d560000 ---p 00047000 08:03 3555804
> /lib/powerpc-linux-gnu/libdbus-1.so.3.7.2
> 0d560000-0d561000 r--p 00047000 08:03 3555804
> /lib/powerpc-linux-gnu/libdbus-1.so.3.7.2
> 0d561000-0d562000 rw-p 00048000 08:03 3555804
> /lib/powerpc-linux-gnu/libdbus-1.so.3.7.2
> 0d572000-0d57b000 r-xp 00000000 08:03 3555850
> /lib/powerpc-linux-gnu/libjson.so.0.1.0
> 0d57b000-0d58a000 ---p 00009000 08:03 3555850
> /lib/powerpc-linux-gnu/libjson.so.0.1.0
> 0d58a000-0d58b000 r--p 00008000 08:03 3555850
> /lib/powerpc-linux-gnu/libjson.so.0.1.0
> 0d58b000-0d58c000 rw-p 00009000 08:03 3555850
> /lib/powerpc-linux-gnu/libjson.so.0.1.0
> 0d59c000-0d5a0000 r-xp 00000000 08:03 3555335
> /lib/powerpc-linux-gnu/libcap.so.2.22
> 0d5a0000-0d5af000 ---p 00004000 08:03 3555335
> /lib/powerpc-linux-gnu/libcap.so.2.22
> 0d5af000-0d5b0000 rw-p 00003000 08:03 3555335
> /lib/powerpc-linux-gnu/libcap.so.2.22
> 0d5c0000-0d620000 r-xp 00000000 08:03 14386632
> /usr/lib/powerpc-linux-gnu/pulseaudio/libpulsecommon-2.0.so
> 0d620000-0d62f000 ---p 00060000 08:03 14386632
> /usr/lib/powerpc-linux-gnu/pulseaudio/libpulsecommon-2.0.so
> 0d62f000-0d631000 r--p 0005f000 08:03 14386632
> /usr/lib/powerpc-linux-gnu/pulseaudio/libpulsecommon-2.0.so
> 0d631000-0d632000 rw-p 00061000 08:03 14386632
> /usr/lib/powerpc-linux-gnu/pulseaudio/libpulsecommon-2.0.so
> 0d642000-0d64c000 r-xp 00000000 08:03 14291038
> /usr/lib/powerpc-linux-gnu/libjbig.so.0.0.0
> 0d64c000-0d65c000 ---p 0000a000 08:03 14291038
> /usr/lib/powerpc-linux-gnu/libjbig.so.0.0.0
> 0d65c000-0d65f000 rw-p 0000a000 08:03 14291038
> /usr/lib/powerpc-linux-gnu/libjbig.so.0.0.0
> 0d66f000-0d680000 r-xp 00000000 08:03 14289371
> /usr/lib/powerpc-linux-gnu/libp11-kit.so.0.0.0
> 0d680000-0d68f000 ---p 00011000 08:03 14289371
> /usr/lib/powerpc-linux-gnu/libp11-kit.so.0.0.0
> 0d68f000-0d690000 r--p 00010000 08:03 14289371
> /usr/lib/powerpc-linux-gnu/libp11-kit.so.0.0.0
> 0d690000-0d691000 rw-p 00011000 08:03 14289371
> /usr/lib/powerpc-linux-gnu/libp11-kit.so.0.0.0
> 0d6a1000-0d6b0000 r-xp 00000000 08:03 14287896
> /usr/lib/powerpc-linux-gnu/libtasn1.so.3.1.16
> 0d6b0000-0d6c0000 ---p 0000f000 08:03 14287896
> /usr/lib/powerpc-linux-gnu/libtasn1.so.3.1.16
> 0d6c0000-0d6c1000 r--p 0000f000 08:03 14287896
> /usr/lib/powerpc-linux-gnu/libtasn1.so.3.1.16
> 0d6c1000-0d6c2000 rw-p 00010000 08:03 14287896
> /usr/lib/powerpc-linux-gnu/libtasn1.so.3.1.16
> 0d6d2000-0d752000 r-xp 00000000 08:03 3555349
> /lib/powerpc-linux-gnu/libgcrypt.so.11.7.0
> 0d752000-0d761000 ---p 00080000 08:03 3555349
> /lib/powerpc-linux-gnu/libgcrypt.so.11.7.0
> 0d761000-0d763000 r--p 0007f000 08:03 3555349
> /lib/powerpc-linux-gnu/libgcrypt.so.11.7.0
> 0d763000-0d765000 rw-p 00081000 08:03 3555349
> /lib/powerpc-linux-gnu/libgcrypt.so.11.7.0
> 0d775000-0d7f2000 r-xp 00000000 08:03 14292233
> /usr/lib/powerpc-linux-gnu/liborc-0.4.so.0.16.0
> 0d7f2000-0d801000 ---p 0007d000 08:03 14292233
> /usr/lib/powerpc-linux-gnu/liborc-0.4.so.0.16.0
> 0d801000-0d805000 r--p 0007c000 08:03 14292233
> /usr/lib/powerpc-linux-gnu/liborc-0.4.so.0.16.0
> 0d805000-0d809000 rw-p 00080000 08:03 14292233
> /usr/lib/powerpc-linux-gnu/liborc-0.4.so.0.16.0
> 0d819000-0d824000 r-xp 00000000 08:03 14291642
> /usr/lib/powerpc-linux-gnu/libdrm.so.2.4.0
> 0d824000-0d833000 ---p 0000b000 08:03 14291642
> /usr/lib/powerpc-linux-gnu/libdrm.so.2.4.0
> 0d833000-0d834000 r--p 0000a000 08:03 14291642
> /usr/lib/powerpc-linux-gnu/libdrm.so.2.4.0
> 0d834000-0d835000 rw-p 0000b000 08:03 14291642
> /usr/lib/powerpc-linux-gnu/libdrm.so.2.4.0
> 0d845000-0d84a000 r-xp 00000000 08:03 14291651
> /usr/lib/powerpc-linux-gnu/libXxf86vm.so.1.0.0
> 0d84a000-0d859000 ---p 00005000 08:03 14291651
> /usr/lib/powerpc-linux-gnu/libXxf86vm.so.1.0.0
> 0d859000-0d85a000 r--p 00004000 08:03 14291651
> /usr/lib/powerpc-linux-gnu/libXxf86vm.so.1.0.0
> 0d85a000-0d85b000 rw-p 00005000 08:03 14291651
> /usr/lib/powerpc-linux-gnu/libXxf86vm.so.1.0.0
> 0d86b000-0d887000 r-xp 00000000 08:03 14291001
> /usr/lib/powerpc-linux-gnu/libxcb.so.1.1.0
> 0d887000-0d897000 ---p 0001c000 08:03 14291001
> /usr/lib/powerpc-linux-gnu/libxcb.so.1.1.0
> 0d897000-0d898000 r--p 0001c000 08:03 14291001
> /usr/lib/powerpc-linux-gnu/libxcb.so.1.1.0
> 0d898000-0d899000 rw-p 0001d000 08:03 14291001
> /usr/lib/powerpc-linux-gnu/libxcb.so.1.1.0
> 0d8a9000-0d8bd000 r-xp 00000000 08:03 14291649
> /usr/lib/powerpc-linux-gnu/libxcb-glx.so.0.0.0
> 0d8bd000-0d8cc000 ---p 00014000 08:03 14291649
> /usr/lib/powerpc-linux-gnu/libxcb-glx.so.0.0.0
> 0d8cc000-0d8cd000 r--p 00013000 08:03 14291649
> /usr/lib/powerpc-linux-gnu/libxcb-glx.so.0.0.0
> 0d8cd000-0d8ce000 rw-p 00014000 08:03 14291649
> /usr/lib/powerpc-linux-gnu/libxcb-glx.so.0.0.0
> 0d8de000-0d8df000 r-xp 00000000 08:03 14291647
> /usr/lib/powerpc-linux-gnu/libX11-xcb.so.1.0.0
> 0d8df000-0d8ee000 ---p 00001000 08:03 14291647
> /usr/lib/powerpc-linux-gnu/libX11-xcb.so.1.0.0
> 0d8ee000-0d8ef000 rw-p 00000000 08:03 14291647
> /usr/lib/powerpc-linux-gnu/libX11-xcb.so.1.0.0
> 0d8ff000-0d904000 r-xp 00000000 08:03 14291636
> /usr/lib/powerpc-linux-gnu/libXfixes.so.3.1.0
> 0d904000-0d913000 ---p 00005000 08:03 14291636
> /usr/lib/powerpc-linux-gnu/libXfixes.so.3.1.0
> 0d913000-0d914000 r--p 00004000 08:03 14291636
> /usr/lib/powerpc-linux-gnu/libXfixes.so.3.1.0
> 0d914000-0d915000 rw-p 00005000 08:03 14291636
> /usr/lib/powerpc-linux-gnu/libXfixes.so.3.1.0
> 0d925000-0d927000 r-xp 00000000 08:03 14291638
> /usr/lib/powerpc-linux-gnu/libXdamage.so.1.1.0
> 0d927000-0d936000 ---p 00002000 08:03 14291638
> /usr/lib/powerpc-linux-gnu/libXdamage.so.1.1.0
> 0d936000-0d937000 rw-p 00001000 08:03 14291638
> /usr/lib/powerpc-linux-gnu/libXdamage.so.1.1.0
> 0d947000-0d96d000 r-xp 00000000 08:03 14291645
> /usr/lib/powerpc-linux-gnu/libglapi.so.0.0.0
> 0d96d000-0d97c000 ---p 00026000 08:03 14291645
> /usr/lib/powerpc-linux-gnu/libglapi.so.0.0.0
> 0d97c000-0d97f000 rw-p 00025000 08:03 14291645
> /usr/lib/powerpc-linux-gnu/libglapi.so.0.0.0
> 0d97f000-0d980000 rw-p 00000000 00:00 0
> 0d990000-0d992000 r-xp 00000000 08:03 14294764
> /usr/lib/powerpc-linux-gnu/libts-0.0.so.0.1.1
> 0d992000-0d9a2000 ---p 00002000 08:03 14294764
> /usr/lib/powerpc-linux-gnu/libts-0.0.so.0.1.1
> 0d9a2000-0d9a3000 rw-p 00002000 08:03 14294764
> /usr/lib/powerpc-linux-gnu/libts-0.0.so.0.1.1
> 0d9b3000-0da79000 r-xp 00000000 08:03 14294636
> /usr/lib/powerpc-linux-gnu/libcaca.so.0.99.18
> 0da79000-0da88000 ---p 000c6000 08:03 14294636
> /usr/lib/powerpc-linux-gnu/libcaca.so.0.99.18
> 0da88000-0da8a000 rw-p 000c5000 08:03 14294636
> /usr/lib/powerpc-linux-gnu/libcaca.so.0.99.18
> 0da8a000-0da8e000 rw-p 00000000 00:00 0
> 0da9e000-0dab6000 r-xp 00000000 08:03 14294766
> /usr/lib/powerpc-linux-gnu/libdirect-1.2.so.9.0.1
> 0dab6000-0dac5000 ---p 00018000 08:03 14294766
> /usr/lib/powerpc-linux-gnu/libdirect-1.2.so.9.0.1
> 0dac5000-0dac7000 rw-p 00017000 08:03 14294766
> /usr/lib/powerpc-linux-gnu/libdirect-1.2.so.9.0.1
> 0dad7000-0dae0000 r-xp 00000000 08:03 14294768
> /usr/lib/powerpc-linux-gnu/libfusion-1.2.so.9.0.1
> 0dae0000-0daf0000 ---p 00009000 08:03 14294768
> /usr/lib/powerpc-linux-gnu/libfusion-1.2.so.9.0.1
> 0daf0000-0daf1000 rw-p 00009000 08:03 14294768
> /usr/lib/powerpc-linux-gnu/libfusion-1.2.so.9.0.1Aborted
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel

[M-dev] Alephone crash on PPC linux

[David H. <how...@gm...>]

As suggested, I recompiled with symbols ie

CXXFLAGS="-g" ./configure


and I get this (full backtrace)



 >david@G5:~/Downloads/AlephOne-20140104$ /usr/local/bin/alephone
 >Aleph One Linux 2014-01-04 1.1
 >http://marathon.sourceforge.net/

 >Original code by Bungie Software <http://www.bungie.com/>
 >Additional work by Loren Petrich, Chris Pruett, Rhys Hill et al.
 >TCP/IP networking by Woody Zenfell
 >Expat XML library by James Clark
 >SDL port by Christian Bauer <Chr...@un...>
 >
 >This is free software with ABSOLUTELY NO WARRANTY.
 >You are welcome to redistribute it under certain conditions.
 >For details, see the file COPYING.
 >
 >Built with network play enabled.
 >
 >Built with Lua scripting enabled.
 >*** glibc detected *** /usr/local/bin/alephone: double free or 
corruption (out): 0x1181e2f8 ***
 >======= Backtrace: =========
 >/lib/powerpc-linux-gnu/libc.so.6(+0x85be4)[0xea25be4]
 >/lib/powerpc-linux-gnu/libc.so.6(cfree+0x8c)[0xea2b29c]
 >/usr/local/bin/alephone[0x101f502c]
 >/usr/local/bin/alephone[0x10201a2c]
 >/usr/local/bin/alephone[0x1020a464]
 >/usr/local/bin/alephone[0x101fd750]
 >/usr/local/bin/alephone[0x101fea6c]
 >/usr/local/bin/alephone[0x101ff530]
 >/usr/local/bin/alephone[0x1020e9ac]
 >/usr/local/bin/alephone[0x101fc398]
 >/usr/local/bin/alephone[0x101fb774]
 >/usr/local/bin/alephone[0x101fc6bc]
 >/usr/local/bin/alephone[0x101f4708]
 >/usr/local/bin/alephone[0x10274a88]
 >/usr/local/bin/alephone[0x10274bac]
 >/usr/local/bin/alephone[0x10275650]
 >/usr/local/bin/alephone[0x10484b58]
 >/usr/local/bin/alephone[0x104b88d0]
 >/usr/local/bin/alephone[0x10287684]
 >/usr/local/bin/alephone[0x1000d4c8]
 >/usr/local/bin/alephone[0x1000b8ec]
 >/lib/powerpc-linux-gnu/libc.so.6(+0x1fd0c)[0xe9bfd0c]
 >/lib/powerpc-linux-gnu/libc.so.6(+0x1fed0)[0xe9bfed0]
 >======= Memory map: ========
 >00100000-00103000 r-xp 00000000 00:00 
0                                  [vdso]
 >0ced5000-0cede000 r-xp 00000000 08:03 14291149 
/usr/lib/powerpc-linux->gnu/libXrender.so.1.3.0
 >0cede000-0ceed000 ---p 00009000 08:03 14291149 
/usr/lib/powerpc-linux-gnu/libXrender.so.1.3.0
0ceed000-0ceee000 rw-p 00008000 08:03 14291149 
/usr/lib/powerpc-linux-gnu/libXrender.so.1.3.0
0cefe000-0cf07000 r-xp 00000000 08:03 14291760 
/usr/lib/powerpc-linux-gnu/libXcursor.so.1.0.2
0cf07000-0cf17000 ---p 00009000 08:03 14291760 
/usr/lib/powerpc-linux-gnu/libXcursor.so.1.0.2
0cf17000-0cf18000 rw-p 00009000 08:03 14291760 
/usr/lib/powerpc-linux-gnu/libXcursor.so.1.0.2
0cf28000-0cf34000 r-xp 00000000 08:03 3556477 
/lib/powerpc-linux-gnu/libnss_files-2.13.so
0cf34000-0cf43000 ---p 0000c000 08:03 3556477 
/lib/powerpc-linux-gnu/libnss_files-2.13.so
0cf43000-0cf44000 r--p 0000b000 08:03 3556477 
/lib/powerpc-linux-gnu/libnss_files-2.13.so
0cf44000-0cf45000 rw-p 0000c000 08:03 3556477 
/lib/powerpc-linux-gnu/libnss_files-2.13.so
0cf55000-0cf60000 r-xp 00000000 08:03 3556473 
/lib/powerpc-linux-gnu/libnss_nis-2.13.so
0cf60000-0cf6f000 ---p 0000b000 08:03 3556473 
/lib/powerpc-linux-gnu/libnss_nis-2.13.so
0cf6f000-0cf70000 r--p 0000a000 08:03 3556473 
/lib/powerpc-linux-gnu/libnss_nis-2.13.so
0cf70000-0cf71000 rw-p 0000b000 08:03 3556473 
/lib/powerpc-linux-gnu/libnss_nis-2.13.so
0cf81000-0cf89000 r-xp 00000000 08:03 3556465 
/lib/powerpc-linux-gnu/libnss_compat-2.13.so
0cf89000-0cf98000 ---p 00008000 08:03 3556465 
/lib/powerpc-linux-gnu/libnss_compat-2.13.so
0cf98000-0cf99000 r--p 00007000 08:03 3556465 
/lib/powerpc-linux-gnu/libnss_compat-2.13.so
0cf99000-0cf9a000 rw-p 00008000 08:03 3556465 
/lib/powerpc-linux-gnu/libnss_compat-2.13.so
0cfaa000-0cfbd000 r-xp 00000000 08:03 3556479 
/lib/powerpc-linux-gnu/libresolv-2.13.so
0cfbd000-0cfcd000 ---p 00013000 08:03 3556479 
/lib/powerpc-linux-gnu/libresolv-2.13.so
0cfcd000-0cfce000 r--p 00013000 08:03 3556479 
/lib/powerpc-linux-gnu/libresolv-2.13.so
0cfce000-0cfcf000 rw-p 00014000 08:03 3556479 
/lib/powerpc-linux-gnu/libresolv-2.13.so
0cfcf000-0cfd1000 rw-p 00000000 00:00 0
0cfe1000-0d02c000 r-xp 00000000 08:03 14293313 
/usr/lib/powerpc-linux-gnu/libFLAC.so.8.2.0
0d02c000-0d03b000 ---p 0004b000 08:03 14293313 
/usr/lib/powerpc-linux-gnu/libFLAC.so.8.2.0
0d03b000-0d03c000 r--p 0004a000 08:03 14293313 
/usr/lib/powerpc-linux-gnu/libFLAC.so.8.2.0
0d03c000-0d03d000 rw-p 0004b000 08:03 14293313 
/usr/lib/powerpc-linux-gnu/libFLAC.so.8.2.0
0d04d000-0d063000 r-xp 00000000 08:03 3556485 
/lib/powerpc-linux-gnu/libnsl-2.13.so
0d063000-0d073000 ---p 00016000 08:03 3556485 
/lib/powerpc-linux-gnu/libnsl-2.13.so
0d073000-0d074000 r--p 00016000 08:03 3556485 
/lib/powerpc-linux-gnu/libnsl-2.13.so
0d074000-0d075000 rw-p 00017000 08:03 3556485 
/lib/powerpc-linux-gnu/libnsl-2.13.so
0d075000-0d077000 rw-p 00000000 00:00 0
0d087000-0d097000 r-xp 00000000 08:03 14291762 
/usr/lib/powerpc-linux-gnu/libXi.so.6.1.0
0d097000-0d0a6000 ---p 00010000 08:03 14291762 
/usr/lib/powerpc-linux-gnu/libXi.so.6.1.0
0d0a6000-0d0a7000 rw-p 0000f000 08:03 14291762 
/usr/lib/powerpc-linux-gnu/libXi.so.6.1.0
0d0b7000-0d0bb000 r-xp 00000000 08:03 3555402 
/lib/powerpc-linux-gnu/libuuid.so.1.3.0
0d0bb000-0d0cb000 ---p 00004000 08:03 3555402 
/lib/powerpc-linux-gnu/libuuid.so.1.3.0
0d0cb000-0d0cc000 r--p 00004000 08:03 3555402 
/lib/powerpc-linux-gnu/libuuid.so.1.3.0
0d0cc000-0d0cd000 rw-p 00005000 08:03 3555402 
/lib/powerpc-linux-gnu/libuuid.so.1.3.0
0d0dd000-0d0e1000 r-xp 00000000 08:03 3555376 
/lib/powerpc-linux-gnu/libattr.so.1.1.0
0d0e1000-0d0f1000 ---p 00004000 08:03 3555376 
/lib/powerpc-linux-gnu/libattr.so.1.1.0
0d0f1000-0d0f2000 r--p 00004000 08:03 3555376 
/lib/powerpc-linux-gnu/libattr.so.1.1.0
0d0f2000-0d0f3000 rw-p 00005000 08:03 3555376 
/lib/powerpc-linux-gnu/libattr.so.1.1.0
0d103000-0d107000 r-xp 00000000 08:03 14293311 
/usr/lib/powerpc-linux-gnu/libasyncns.so.0.3.1
0d107000-0d117000 ---p 00004000 08:03 14293311 
/usr/lib/powerpc-linux-gnu/libasyncns.so.0.3.1
0d117000-0d118000 rw-p 00004000 08:03 14293311 
/usr/lib/powerpc-linux-gnu/libasyncns.so.0.3.1
0d128000-0d192000 r-xp 00000000 08:03 14293317 
/usr/lib/powerpc-linux-gnu/libsndfile.so.1.0.25
0d192000-0d1a2000 ---p 0006a000 08:03 14293317 
/usr/lib/powerpc-linux-gnu/libsndfile.so.1.0.25
0d1a2000-0d1a5000 r--p 0006a000 08:03 14293317 
/usr/lib/powerpc-linux-gnu/libsndfile.so.1.0.25
0d1a5000-0d1a6000 rw-p 0006d000 08:03 14293317 
/usr/lib/powerpc-linux-gnu/libsndfile.so.1.0.25
0d1a6000-0d1aa000 rw-p 00000000 00:00 0
0d1ba000-0d1c2000 r-xp 00000000 08:03 3555802 
/lib/powerpc-linux-gnu/libwrap.so.0.7.6
0d1c2000-0d1d2000 ---p 00008000 08:03 3555802 
/lib/powerpc-linux-gnu/libwrap.so.0.7.6
0d1d2000-0d1d3000 r--p 00008000 08:03 3555802 
/lib/powerpc-linux-gnu/libwrap.so.0.7.6
0d1d3000-0d1d4000 rw-p 00009000 08:03 3555802 
/lib/powerpc-linux-gnu/libwrap.so.0.7.6
0d1e4000-0d1e9000 r-xp 00000000 08:03 14293215 
/usr/lib/powerpc-linux-gnu/libXtst.so.6.1.0
0d1e9000-0d1f9000 ---p 00005000 08:03 14293215 
/usr/lib/powerpc-linux-gnu/libXtst.so.6.1.0
0d1f9000-0d1fa000 rw-p 00005000 08:03 14293215 
/usr/lib/powerpc-linux-gnu/libXtst.so.6.1.0
0d20a000-0d211000 r-xp 00000000 08:03 14292542 
/usr/lib/powerpc-linux-gnu/libSM.so.6.0.1
0d211000-0d220000 ---p 00007000 08:03 14292542 
/usr/lib/powerpc-linux-gnu/libSM.so.6.0.1
0d220000-0d221000 rw-p 00006000 08:03 14292542 
/usr/lib/powerpc-linux-gnu/libSM.so.6.0.1
0d231000-0d247000 r-xp 00000000 08:03 14292540 
/usr/lib/powerpc-linux-gnu/libICE.so.6.3.0
0d247000-0d256000 ---p 00016000 08:03 14292540 
/usr/lib/powerpc-linux-gnu/libICE.so.6.3.0
0d256000-0d257000 rw-p 00015000 08:03 14292540 
/usr/lib/powerpc-linux-gnu/libICE.so.6.3.0
0d257000-0d259000 rw-p 00000000 00:00 0
0d269000-0d26c000 r-xp 00000000 08:03 3555479 
/lib/powerpc-linux-gnu/libgpg-error.so.0.8.0
0d26c000-0d27b000 ---p 00003000 08:03 3555479 
/lib/powerpc-linux-gnu/libgpg-error.so.0.8.0
0d27b000-0d27c000 rw-p 00002000 08:03 3555479 
/lib/powerpc-linux-gnu/libgpg-error.so.0.8.0
0d28c000-0d291000 r-xp 00000000 08:03 14290999 
/usr/lib/powerpc-linux-gnu/libXdmcp.so.6.0.0
0d291000-0d2a0000 ---p 00005000 08:03 14290999 
/usr/lib/powerpc-linux-gnu/libXdmcp.so.6.0.0
0d2a0000-0d2a1000 rw-p 00004000 08:03 14290999 
/usr/lib/powerpc-linux-gnu/libXdmcp.so.6.0.0
0d2b1000-0d2b3000 r-xp 00000000 08:03 14290997 
/usr/lib/powerpc-linux-gnu/libXau.so.6.0.0
0d2b3000-0d2c3000 ---p 00002000 08:03 14290997 
/usr/lib/powerpc-linux-gnu/libXau.so.6.0.0
0d2c3000-0d2c4000 rw-p 00002000 08:03 14290997 
/usr/lib/powerpc-linux-gnu/libXau.so.6.0.0
0d2d4000-0d2f3000 r-xp 00000000 08:03 3555368 
/lib/powerpc-linux-gnu/libtinfo.so.5.9
0d2f3000-0d303000 ---p 0001f000 08:03 3555368 
/lib/powerpc-linux-gnu/libtinfo.so.5.9
0d303000-0d305000 r--p 0001f000 08:03 3555368 
/lib/powerpc-linux-gnu/libtinfo.so.5.9
0d305000-0d306000 rw-p 00021000 08:03 3555368 
/lib/powerpc-linux-gnu/libtinfo.so.5.9
0d316000-0d343000 r-xp 00000000 08:03 3555483 
/lib/powerpc-linux-gnu/libncursesw.so.5.9
0d343000-0d352000 ---p 0002d000 08:03 3555483 
/lib/powerpc-linux-gnu/libncursesw.so.5.9
0d352000-0d353000 r--p 0002c000 08:03 3555483 
/lib/powerpc-linux-gnu/libncursesw.so.5.9
0d353000-0d354000 rw-p 0002d000 08:03 3555483 
/lib/powerpc-linux-gnu/libncursesw.so.5.9
0d364000-0d498000 r-xp 00000000 08:03 3555417 
/lib/powerpc-linux-gnu/libslang.so.2.2.4
0d498000-0d4a8000 ---p 00134000 08:03 3555417 
/lib/powerpc-linux-gnu/libslang.so.2.2.4
0d4a8000-0d4ac000 r--p 00134000 08:03 3555417 
/lib/powerpc-linux-gnu/libslang.so.2.2.4
0d4ac000-0d4bb000 rw-p 00138000 08:03 3555417 
/lib/powerpc-linux-gnu/libslang.so.2.2.4
0d4bb000-0d4f9000 rw-p 00000000 00:00 0
0d509000-0d550000 r-xp 00000000 08:03 3555804 
/lib/powerpc-linux-gnu/libdbus-1.so.3.7.2
0d550000-0d560000 ---p 00047000 08:03 3555804 
/lib/powerpc-linux-gnu/libdbus-1.so.3.7.2
0d560000-0d561000 r--p 00047000 08:03 3555804 
/lib/powerpc-linux-gnu/libdbus-1.so.3.7.2
0d561000-0d562000 rw-p 00048000 08:03 3555804 
/lib/powerpc-linux-gnu/libdbus-1.so.3.7.2
0d572000-0d57b000 r-xp 00000000 08:03 3555850 
/lib/powerpc-linux-gnu/libjson.so.0.1.0
0d57b000-0d58a000 ---p 00009000 08:03 3555850 
/lib/powerpc-linux-gnu/libjson.so.0.1.0
0d58a000-0d58b000 r--p 00008000 08:03 3555850 
/lib/powerpc-linux-gnu/libjson.so.0.1.0
0d58b000-0d58c000 rw-p 00009000 08:03 3555850 
/lib/powerpc-linux-gnu/libjson.so.0.1.0
0d59c000-0d5a0000 r-xp 00000000 08:03 3555335 
/lib/powerpc-linux-gnu/libcap.so.2.22
0d5a0000-0d5af000 ---p 00004000 08:03 3555335 
/lib/powerpc-linux-gnu/libcap.so.2.22
0d5af000-0d5b0000 rw-p 00003000 08:03 3555335 
/lib/powerpc-linux-gnu/libcap.so.2.22
0d5c0000-0d620000 r-xp 00000000 08:03 14386632 
/usr/lib/powerpc-linux-gnu/pulseaudio/libpulsecommon-2.0.so
0d620000-0d62f000 ---p 00060000 08:03 14386632 
/usr/lib/powerpc-linux-gnu/pulseaudio/libpulsecommon-2.0.so
0d62f000-0d631000 r--p 0005f000 08:03 14386632 
/usr/lib/powerpc-linux-gnu/pulseaudio/libpulsecommon-2.0.so
0d631000-0d632000 rw-p 00061000 08:03 14386632 
/usr/lib/powerpc-linux-gnu/pulseaudio/libpulsecommon-2.0.so
0d642000-0d64c000 r-xp 00000000 08:03 14291038 
/usr/lib/powerpc-linux-gnu/libjbig.so.0.0.0
0d64c000-0d65c000 ---p 0000a000 08:03 14291038 
/usr/lib/powerpc-linux-gnu/libjbig.so.0.0.0
0d65c000-0d65f000 rw-p 0000a000 08:03 14291038 
/usr/lib/powerpc-linux-gnu/libjbig.so.0.0.0
0d66f000-0d680000 r-xp 00000000 08:03 14289371 
/usr/lib/powerpc-linux-gnu/libp11-kit.so.0.0.0
0d680000-0d68f000 ---p 00011000 08:03 14289371 
/usr/lib/powerpc-linux-gnu/libp11-kit.so.0.0.0
0d68f000-0d690000 r--p 00010000 08:03 14289371 
/usr/lib/powerpc-linux-gnu/libp11-kit.so.0.0.0
0d690000-0d691000 rw-p 00011000 08:03 14289371 
/usr/lib/powerpc-linux-gnu/libp11-kit.so.0.0.0
0d6a1000-0d6b0000 r-xp 00000000 08:03 14287896 
/usr/lib/powerpc-linux-gnu/libtasn1.so.3.1.16
0d6b0000-0d6c0000 ---p 0000f000 08:03 14287896 
/usr/lib/powerpc-linux-gnu/libtasn1.so.3.1.16
0d6c0000-0d6c1000 r--p 0000f000 08:03 14287896 
/usr/lib/powerpc-linux-gnu/libtasn1.so.3.1.16
0d6c1000-0d6c2000 rw-p 00010000 08:03 14287896 
/usr/lib/powerpc-linux-gnu/libtasn1.so.3.1.16
0d6d2000-0d752000 r-xp 00000000 08:03 3555349 
/lib/powerpc-linux-gnu/libgcrypt.so.11.7.0
0d752000-0d761000 ---p 00080000 08:03 3555349 
/lib/powerpc-linux-gnu/libgcrypt.so.11.7.0
0d761000-0d763000 r--p 0007f000 08:03 3555349 
/lib/powerpc-linux-gnu/libgcrypt.so.11.7.0
0d763000-0d765000 rw-p 00081000 08:03 3555349 
/lib/powerpc-linux-gnu/libgcrypt.so.11.7.0
0d775000-0d7f2000 r-xp 00000000 08:03 14292233 
/usr/lib/powerpc-linux-gnu/liborc-0.4.so.0.16.0
0d7f2000-0d801000 ---p 0007d000 08:03 14292233 
/usr/lib/powerpc-linux-gnu/liborc-0.4.so.0.16.0
0d801000-0d805000 r--p 0007c000 08:03 14292233 
/usr/lib/powerpc-linux-gnu/liborc-0.4.so.0.16.0
0d805000-0d809000 rw-p 00080000 08:03 14292233 
/usr/lib/powerpc-linux-gnu/liborc-0.4.so.0.16.0
0d819000-0d824000 r-xp 00000000 08:03 14291642 
/usr/lib/powerpc-linux-gnu/libdrm.so.2.4.0
0d824000-0d833000 ---p 0000b000 08:03 14291642 
/usr/lib/powerpc-linux-gnu/libdrm.so.2.4.0
0d833000-0d834000 r--p 0000a000 08:03 14291642 
/usr/lib/powerpc-linux-gnu/libdrm.so.2.4.0
0d834000-0d835000 rw-p 0000b000 08:03 14291642 
/usr/lib/powerpc-linux-gnu/libdrm.so.2.4.0
0d845000-0d84a000 r-xp 00000000 08:03 14291651 
/usr/lib/powerpc-linux-gnu/libXxf86vm.so.1.0.0
0d84a000-0d859000 ---p 00005000 08:03 14291651 
/usr/lib/powerpc-linux-gnu/libXxf86vm.so.1.0.0
0d859000-0d85a000 r--p 00004000 08:03 14291651 
/usr/lib/powerpc-linux-gnu/libXxf86vm.so.1.0.0
0d85a000-0d85b000 rw-p 00005000 08:03 14291651 
/usr/lib/powerpc-linux-gnu/libXxf86vm.so.1.0.0
0d86b000-0d887000 r-xp 00000000 08:03 14291001 
/usr/lib/powerpc-linux-gnu/libxcb.so.1.1.0
0d887000-0d897000 ---p 0001c000 08:03 14291001 
/usr/lib/powerpc-linux-gnu/libxcb.so.1.1.0
0d897000-0d898000 r--p 0001c000 08:03 14291001 
/usr/lib/powerpc-linux-gnu/libxcb.so.1.1.0
0d898000-0d899000 rw-p 0001d000 08:03 14291001 
/usr/lib/powerpc-linux-gnu/libxcb.so.1.1.0
0d8a9000-0d8bd000 r-xp 00000000 08:03 14291649 
/usr/lib/powerpc-linux-gnu/libxcb-glx.so.0.0.0
0d8bd000-0d8cc000 ---p 00014000 08:03 14291649 
/usr/lib/powerpc-linux-gnu/libxcb-glx.so.0.0.0
0d8cc000-0d8cd000 r--p 00013000 08:03 14291649 
/usr/lib/powerpc-linux-gnu/libxcb-glx.so.0.0.0
0d8cd000-0d8ce000 rw-p 00014000 08:03 14291649 
/usr/lib/powerpc-linux-gnu/libxcb-glx.so.0.0.0
0d8de000-0d8df000 r-xp 00000000 08:03 14291647 
/usr/lib/powerpc-linux-gnu/libX11-xcb.so.1.0.0
0d8df000-0d8ee000 ---p 00001000 08:03 14291647 
/usr/lib/powerpc-linux-gnu/libX11-xcb.so.1.0.0
0d8ee000-0d8ef000 rw-p 00000000 08:03 14291647 
/usr/lib/powerpc-linux-gnu/libX11-xcb.so.1.0.0
0d8ff000-0d904000 r-xp 00000000 08:03 14291636 
/usr/lib/powerpc-linux-gnu/libXfixes.so.3.1.0
0d904000-0d913000 ---p 00005000 08:03 14291636 
/usr/lib/powerpc-linux-gnu/libXfixes.so.3.1.0
0d913000-0d914000 r--p 00004000 08:03 14291636 
/usr/lib/powerpc-linux-gnu/libXfixes.so.3.1.0
0d914000-0d915000 rw-p 00005000 08:03 14291636 
/usr/lib/powerpc-linux-gnu/libXfixes.so.3.1.0
0d925000-0d927000 r-xp 00000000 08:03 14291638 
/usr/lib/powerpc-linux-gnu/libXdamage.so.1.1.0
0d927000-0d936000 ---p 00002000 08:03 14291638 
/usr/lib/powerpc-linux-gnu/libXdamage.so.1.1.0
0d936000-0d937000 rw-p 00001000 08:03 14291638 
/usr/lib/powerpc-linux-gnu/libXdamage.so.1.1.0
0d947000-0d96d000 r-xp 00000000 08:03 14291645 
/usr/lib/powerpc-linux-gnu/libglapi.so.0.0.0
0d96d000-0d97c000 ---p 00026000 08:03 14291645 
/usr/lib/powerpc-linux-gnu/libglapi.so.0.0.0
0d97c000-0d97f000 rw-p 00025000 08:03 14291645 
/usr/lib/powerpc-linux-gnu/libglapi.so.0.0.0
0d97f000-0d980000 rw-p 00000000 00:00 0
0d990000-0d992000 r-xp 00000000 08:03 14294764 
/usr/lib/powerpc-linux-gnu/libts-0.0.so.0.1.1
0d992000-0d9a2000 ---p 00002000 08:03 14294764 
/usr/lib/powerpc-linux-gnu/libts-0.0.so.0.1.1
0d9a2000-0d9a3000 rw-p 00002000 08:03 14294764 
/usr/lib/powerpc-linux-gnu/libts-0.0.so.0.1.1
0d9b3000-0da79000 r-xp 00000000 08:03 14294636 
/usr/lib/powerpc-linux-gnu/libcaca.so.0.99.18
0da79000-0da88000 ---p 000c6000 08:03 14294636 
/usr/lib/powerpc-linux-gnu/libcaca.so.0.99.18
0da88000-0da8a000 rw-p 000c5000 08:03 14294636 
/usr/lib/powerpc-linux-gnu/libcaca.so.0.99.18
0da8a000-0da8e000 rw-p 00000000 00:00 0
0da9e000-0dab6000 r-xp 00000000 08:03 14294766 
/usr/lib/powerpc-linux-gnu/libdirect-1.2.so.9.0.1
0dab6000-0dac5000 ---p 00018000 08:03 14294766 
/usr/lib/powerpc-linux-gnu/libdirect-1.2.so.9.0.1
0dac5000-0dac7000 rw-p 00017000 08:03 14294766 
/usr/lib/powerpc-linux-gnu/libdirect-1.2.so.9.0.1
0dad7000-0dae0000 r-xp 00000000 08:03 14294768 
/usr/lib/powerpc-linux-gnu/libfusion-1.2.so.9.0.1
0dae0000-0daf0000 ---p 00009000 08:03 14294768 
/usr/lib/powerpc-linux-gnu/libfusion-1.2.so.9.0.1
0daf0000-0daf1000 rw-p 00009000 08:03 14294768 
/usr/lib/powerpc-linux-gnu/libfusion-1.2.so.9.0.1Aborted

Re: [M-dev] ENPT vs PNTS problem

[Gregory S. <wo...@tr...>]

The code that does this in Weland is in Level.cs:291. It should only
be an issue for variable height lines, i.e. platforms.

Gregory


On Sun, Mar 8, 2015 at 5:47 PM, Joshua Orr <jo...@gm...> wrote:
> So, I did export it from Weland, and discovered that the problem was some of
> the lines are flagged as solid in the original level (from the marathon
> infinity map file, level 1), but wetland changes them to not be solid
> anymore.
>
> I suppose some of the exclusion zones somehow excluded some of the flagged
> lines from being solid.  When I use PNTS, the exclusion zones from the map
> file are not used anymore and it just treated the whole line as solid it
> looks like.
>
> I'll have to unflag certain lines from being solid when importing a map that
> have use the ENPT, exclusion zones, etc.
>
> -Josh
>
>
> On Fri, Mar 6, 2015 at 8:13 AM, Gregory Smith <wo...@tr...> wrote:
>>
>> Josh,
>>
>> Neither Aleph One nor Weland uses ENPT when exporting a level, so it
>> probably is something you're doing wrong. You can export a level from Aleph
>> One using .save level and compare it to the one your editor generates, or do
>> likewise from Weland.
>>
>> Gregory
>>
>>
>> On Wed, Mar 4, 2015 at 11:52 PM, Joshua Orr <jo...@gm...> wrote:
>>>
>>> I have a situation where I am outputting a file that has PNTS instead of
>>> the ENPT chunk in the level.  When I do that, Aleph One always seems to put
>>> black non passable walls when platforms open up (like a door).
>>>
>>> I have some test files:
>>> http://ts3.josho.me/testFiles.zip
>>>
>>> In that zip are a PNTS and a ENPT version.  The only difference is one
>>> has PNTS and no indexes list chunk.  The other has the indexes chunk and
>>> ENPT.  It's of the first level in marathon infinity.
>>>
>>> I would like to output to the simpler PNTS and not have to calculate all
>>> the exhalations zones, etc.  So hopefully it's something that I am doing
>>> wrong and can fix, but I don't see how it could be at this point.  Probably
>>> something happening during the calculating of the redundant data that gets
>>> triggered when you use PNTS?
>>>
>>> Anyone have any ideas?
>>>
>>> -Josh
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>> for all
>>> things parallel software development, from weekly thought leadership
>>> blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Marathon-devel mailing list
>>> Mar...@li...
>>> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for
>> all
>> things parallel software development, from weekly thought leadership blogs
>> to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Marathon-devel mailing list
>> Mar...@li...
>> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>

Re: [M-dev] Alephone crash on PPC linux

[Gregory S. <wo...@tr...>]

Can you recompile with symbols, then post (or gist) a complete
backtrace? I no longer have a PPC machine running.

CXXFLAGS="-g" ./configure

Gregory


On Sun, Mar 8, 2015 at 5:09 AM, David Howe <how...@gm...> wrote:
> Hello
>
> Apologies in advance if this is posted to the wrong list.
>
> I've just built Alephone from the current tarball, installed some
> Marathon files (as you do) and this is what happens -
>
> david@G5:~$ /usr/local/bin/alephone
> Aleph One Linux 2014-01-04 1.1
> http://marathon.sourceforge.net/
>
> Original code by Bungie Software <http://www.bungie.com/>
> Additional work by Loren Petrich, Chris Pruett, Rhys Hill et al.
> TCP/IP networking by Woody Zenfell
> Expat XML library by James Clark
> SDL port by Christian Bauer <Chr...@un...>
>
> This is free software with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> For details, see the file COPYING.
>
> Built with network play enabled.
>
> Built with Lua scripting enabled.
> GL_VENDOR: Mesa Project
> GL_RENDERER: Software Rasterizer
> GL_VERSION: 2.1 Mesa 8.0.5
> *** glibc detected *** /usr/local/bin/alephone: malloc(): memory
> corruption: 0x1108a828 ***
>
>  >>>>then a whole lot of backtrace and memory map info which ends with
>
> 0d833000-0d834000 r--p 0000a000 08:03 14291642
> /usr/lib/powerpc-linux-gnu/libdrm.so.2.4.0Aborted
>
> Obviously this is on a G5 ppc machine with a current Debian 7.7 build.
>
> Any thoughts?
>
> David
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel

Re: [M-dev] ENPT vs PNTS problem

[Joshua O. <jo...@gm...>]

So, I did export it from Weland, and discovered that the problem was some
of the lines are flagged as solid in the original level (from the marathon
infinity map file, level 1), but wetland changes them to not be solid
anymore.

I suppose some of the exclusion zones somehow excluded some of the flagged
lines from being solid.  When I use PNTS, the exclusion zones from the map
file are not used anymore and it just treated the whole line as solid it
looks like.

I'll have to unflag certain lines from being solid when importing a map
that have use the ENPT, exclusion zones, etc.

-Josh


On Fri, Mar 6, 2015 at 8:13 AM, Gregory Smith <wo...@tr...> wrote:

> Josh,
>
> Neither Aleph One nor Weland uses ENPT when exporting a level, so it
> probably is something you're doing wrong. You can export a level from Aleph
> One using .save level and compare it to the one your editor generates, or
> do likewise from Weland.
>
> Gregory
>
>
> On Wed, Mar 4, 2015 at 11:52 PM, Joshua Orr <jo...@gm...> wrote:
>
>> I have a situation where I am outputting a file that has PNTS instead of
>> the ENPT chunk in the level.  When I do that, Aleph One always seems to put
>> black non passable walls when platforms open up (like a door).
>>
>> I have some test files:
>> http://ts3.josho.me/testFiles.zip
>>
>> In that zip are a PNTS and a ENPT version.  The only difference is one
>> has PNTS and no indexes list chunk.  The other has the indexes chunk and
>> ENPT.  It's of the first level in marathon infinity.
>>
>> I would like to output to the simpler PNTS and not have to calculate all
>> the exhalations zones, etc.  So hopefully it's something that I am doing
>> wrong and can fix, but I don't see how it could be at this point.  Probably
>> something happening during the calculating of the redundant data that gets
>> triggered when you use PNTS?
>>
>> Anyone have any ideas?
>>
>> -Josh
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Marathon-devel mailing list
>> Mar...@li...
>> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>
>

[M-dev] Alephone crash on PPC linux

[David H. <how...@gm...>]

Hello

Apologies in advance if this is posted to the wrong list.

I've just built Alephone from the current tarball, installed some 
Marathon files (as you do) and this is what happens -

david@G5:~$ /usr/local/bin/alephone
Aleph One Linux 2014-01-04 1.1
http://marathon.sourceforge.net/

Original code by Bungie Software <http://www.bungie.com/>
Additional work by Loren Petrich, Chris Pruett, Rhys Hill et al.
TCP/IP networking by Woody Zenfell
Expat XML library by James Clark
SDL port by Christian Bauer <Chr...@un...>

This is free software with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
For details, see the file COPYING.

Built with network play enabled.

Built with Lua scripting enabled.
GL_VENDOR: Mesa Project
GL_RENDERER: Software Rasterizer
GL_VERSION: 2.1 Mesa 8.0.5
*** glibc detected *** /usr/local/bin/alephone: malloc(): memory 
corruption: 0x1108a828 ***

 >>>>then a whole lot of backtrace and memory map info which ends with

0d833000-0d834000 r--p 0000a000 08:03 14291642
/usr/lib/powerpc-linux-gnu/libdrm.so.2.4.0Aborted

Obviously this is on a G5 ppc machine with a current Debian 7.7 build.

Any thoughts?

David

Re: [M-dev] ENPT vs PNTS problem

[Josh O. <jo...@gm...>]

Good to know that Weland uses PNTS and it works in the engine, I'll take a look and compare.

I do put the level entry headers right after main header instead of end of file, so perhaps that is it. Also, the level and main file headers are also not exactly the same so could be doing something wrong there.  Can't imagine the PNTS are off since they are so simple and the level geometry seems to be fine, but I'll double check them just in case.

-Josh

> On Mar 6, 2015, at 8:13 AM, Gregory Smith <wo...@tr...> wrote:
> 
> Josh,
> 
> Neither Aleph One nor Weland uses ENPT when exporting a level, so it probably is something you're doing wrong. You can export a level from Aleph One using .save level and compare it to the one your editor generates, or do likewise from Weland.
> 
> Gregory
> 
> 
>> On Wed, Mar 4, 2015 at 11:52 PM, Joshua Orr <jo...@gm...> wrote:
>> I have a situation where I am outputting a file that has PNTS instead of the ENPT chunk in the level.  When I do that, Aleph One always seems to put black non passable walls when platforms open up (like a door).
>> 
>> I have some test files:
>> http://ts3.josho.me/testFiles.zip
>> 
>> In that zip are a PNTS and a ENPT version.  The only difference is one has PNTS and no indexes list chunk.  The other has the indexes chunk and ENPT.  It's of the first level in marathon infinity.
>> 
>> I would like to output to the simpler PNTS and not have to calculate all the exhalations zones, etc.  So hopefully it's something that I am doing wrong and can fix, but I don't see how it could be at this point.  Probably something happening during the calculating of the redundant data that gets triggered when you use PNTS?
>> 
>> Anyone have any ideas?
>> 
>> -Josh
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Marathon-devel mailing list
>> Mar...@li...
>> https://lists.sourceforge.net/lists/listinfo/marathon-devel
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel

Re: [M-dev] ENPT vs PNTS problem

[Gregory S. <wo...@tr...>]

Josh,

Neither Aleph One nor Weland uses ENPT when exporting a level, so it
probably is something you're doing wrong. You can export a level from Aleph
One using .save level and compare it to the one your editor generates, or
do likewise from Weland.

Gregory


On Wed, Mar 4, 2015 at 11:52 PM, Joshua Orr <jo...@gm...> wrote:

> I have a situation where I am outputting a file that has PNTS instead of
> the ENPT chunk in the level.  When I do that, Aleph One always seems to put
> black non passable walls when platforms open up (like a door).
>
> I have some test files:
> http://ts3.josho.me/testFiles.zip
>
> In that zip are a PNTS and a ENPT version.  The only difference is one has
> PNTS and no indexes list chunk.  The other has the indexes chunk and ENPT.
> It's of the first level in marathon infinity.
>
> I would like to output to the simpler PNTS and not have to calculate all
> the exhalations zones, etc.  So hopefully it's something that I am doing
> wrong and can fix, but I don't see how it could be at this point.  Probably
> something happening during the calculating of the redundant data that gets
> triggered when you use PNTS?
>
> Anyone have any ideas?
>
> -Josh
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>
>

[M-dev] ENPT vs PNTS problem

[Joshua O. <jo...@gm...>]

I have a situation where I am outputting a file that has PNTS instead of
the ENPT chunk in the level.  When I do that, Aleph One always seems to put
black non passable walls when platforms open up (like a door).

I have some test files:
http://ts3.josho.me/testFiles.zip

In that zip are a PNTS and a ENPT version.  The only difference is one has
PNTS and no indexes list chunk.  The other has the indexes chunk and ENPT.
It's of the first level in marathon infinity.

I would like to output to the simpler PNTS and not have to calculate all
the exhalations zones, etc.  So hopefully it's something that I am doing
wrong and can fix, but I don't see how it could be at this point.  Probably
something happening during the calculating of the redundant data that gets
triggered when you use PNTS?

Anyone have any ideas?

-Josh

Re: [M-dev] _panel_is_platform_switch question

[Joshua O. <jo...@gm...>]

Thank you, that helped.  I am in the middle of adding the ability for my
new editor to save back into the map file.  Your Leela comment made my day!
:D

-Josh


On Sun, Mar 1, 2015 at 7:07 PM, Jeremiah Morris <jm...@wh...> wrote:

> Correct -- devices.cpp always finds the platform index by going through
> the polygon:
>
> get_polygon_data(side->control_panel_permutation)->permutation
>
> Like many others in the code, that comment was rewritten by Leela to
> mislead the Pfhor.
>
>
> On Mar 1, 2015, at 8:54 PM, Joshua Orr <jo...@gm...> wrote:
>
> In the map.h header file, control panel type class of
> "_panel_is_platform_switch" says it's supposed to be the platform:
>
> _panel_is_platform_switch, // platform index in .permutation
>
> But it appears that it's really supposed to be the polygon index that the
> platform is attached to, correct?
>
> -Josh
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now.
> http://goparallel.sourceforge.net/_______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel
>
>

Re: [M-dev] _panel_is_platform_switch question

[Jeremiah M. <jm...@wh...>]

Correct -- devices.cpp always finds the platform index by going through the polygon:

get_polygon_data(side->control_panel_permutation)->permutation

Like many others in the code, that comment was rewritten by Leela to mislead the Pfhor.


> On Mar 1, 2015, at 8:54 PM, Joshua Orr <jo...@gm...> wrote:
> 
> In the map.h header file, control panel type class of "_panel_is_platform_switch" says it's supposed to be the platform:
> 
> _panel_is_platform_switch, // platform index in .permutation
> 
> But it appears that it's really supposed to be the polygon index that the platform is attached to, correct?
> 
> -Josh
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/_______________________________________________
> Marathon-devel mailing list
> Mar...@li...
> https://lists.sourceforge.net/lists/listinfo/marathon-devel