Forum Replies Created

Viewing 15 posts - 1 through 15 (of 42 total)
  • Author
  • in reply to: Compiling error: can’t find sdl_mixer #13177


    you need to let configure know where sdl-mixer is installed, since it is not in the ‘default location’.

    export CPPFLAGS=-I/sw/include
    export LDFLAGS=-L/sw/lib

    If that still doesn’t work, also try ‘export CFLAGS=-I/sw/include’; I don’t remeber if it was CFLAGS or CPPFLAGS that did the trick for me.

    in reply to: missing CVS files #12944


    that did it. there were still some problems wint the tanks xml file, but I was able to comment out the offending lines… it looks like there’s still some files missing after make install.

    In any case, I’d say performance is barely noticibly better, while visuals are much better. To me this means there’s still a lot of optimizing that can be done, but the game is playable on my system (1ghz powerbook, 1gb ram, geforce 4200 64mb) with my preferences (all visuals, simultaneous shooting, 23 bots & me).

    Two issues are readily apparent: the bombs of a funky bomb have square shaped visual artifacts around them, and the animation stutters at the peak of a missle’s trajectory… related to this, the smoke trails don’t seem to be exactly inline with the fire trails, and seem to switch sides after the projectile reaches its peak.

    in reply to: missing CVS files #12942


    Not sure about this one.

    Make sure you always use the option to get any new directories.

    doh. i knew that.

    If this is not the issue then it may be because the linux version is lagging behind the windows one. In this case run scripts/

    Let me know what performance is like as I have updated the version of ODE (physics engine) and changed a lot of the explosion effects.

    I’d love to… everything builds now, but when attempting to run a game I get:

    The Scorched3d process terminated unexpectedly.
    XMLNode : Parse Error, File:/usr/local/games/scorched3d/share/data/accessories.xml Line:963 Col:1 Node:accessory Error:Failed to parse int value

    I see no problems with the accessories.xml file near line 963, so I have no idea about this one. This happens no matter the (local) game type.

    in reply to: Building from CVS #11894


    using the supplied and .patch files worked (of course)…. still, I wonder why wxgtk- did not.

    in reply to: Building from CVS #11893


    ok, so after getting wx- .info and .patch files from fink’s cvs, rebuilding wxgtk and rebuilding scorched3d, i get the following link error:

    ld: undefined symbols:

    c++filt unmangles this to:

    wxAddProcessCallbackForPid(wxEndProcessData*, int)

    So i grepped the wx includes and found it declared in /sw/include/wx/unix/execute.h. The I used nm to grep the libraries and found it as a symbol in /sw/lib/libwx_gtkd-, but not in libwx_gtkd_gl- So whatever.

    I’ve coppied the osx/wxgtk* files to /sw/fink/dists/stable/main/finkinfo/x11 and am trying again (although I do think scorched3d should build against the wxgtk-

    in reply to: Building from CVS #11891


    > wx-config –libs
    -L/sw/lib -L/sw/lib -L/usr/X11R6/lib -lwx_gtk2d_html-2.5 -lwx_gtk2d_adv-2.5 -lwx_gtk2d_core-2.5 -lwx_based_xml-2.5 -lwx_based_net-2.5 -lwx_based-2.5

    Looking at the osx/ file I see that scorched3d uses wx version 2.4 while I have 2.5 installed. Looking at the wxWindows website I see that the 2.5 branch is a development branch. Why this is the one provided by fink is beyond me. Actually, why there is no 2.4 version in stable is beyond me (2.5 comes from unstable).

    So, I’ll have to converse with the fink guys about this, as you should not be developing toward an unstable library.

    in reply to: Building from CVS #11889


    Are you sure the configure script is picking up wxGTK and not the python version?

    No, but I also don’t know why this would matter, how to look for it, or how to change it. ./ reports these lines about wx:

    checking for wx-config… /sw/bin/wx-config
    checking for wxWindows version >= 2.4.0… yes (version 2.5.1)

    in reply to: Building from CVS #11887


    This code has been like this for a while, which wx windows package are you trying to compile?

    uh… I have wxgtk (and wxgtk-shlibs and wxpython-py23) via fink installed.

    Unless you want to compile version 38 (which is incompatable with version 37) you may want to just download the source code tar file or use the CVS label Release-37-2.

    this Release-37-2 gives me the errors I posted previously, which I’m still getting with HEAD

    I don’t really care about versions: i just play against bots. I like to stay current for feature, bug, and performance reasons.

    in reply to: Mac OS Help #10864


    In GTK you can’t have a dialog displayed without first initializing the whole gtk library. By the time we try and run the actual game part gtk has been shut down. This solves issues caused by tring to run SDL and GTK at the same time. As GTK has been shut down no more windows can be created.

    However, for version 37 I have fixed this another way. The launcher dialog captures all messages to stdout and pops up a windows with this info in it if the program exits with an error code.

    So I suppose the quick answers are, yes I can fix it and it is already fixed in v 37.

    this brings up an interesting thought… why not do the dialog in SDL? I’m not sure of what all terms to use, but aside from LucasArts games and scorched, I can think of no other games that have a OS-native-GUI menu before the game goes full screen. With all the problems between wxgtk & OS X, it would be a welcomed change.

    in reply to: Mac OS X 10.3.2 Illegal instruction #10869


    FYI, I cleaned my wxgtk fink files and rebuilt from scratch, so threads are enabled in wxgtk… I suppose there’s one place I could start…

    yeah… adding –enable-threads=no to fixed up that Illegal Instruction real good. Its a shame wxgtk is so broken.

    in reply to: Mac OS X 10.3.2 Illegal instruction #10868


    I’d agree with what the fink developers told you…. I think this is a gcc issue, and not a scorched3d one.

    quite right. I realize scorched3d is not the problem… but it does expose the problem, so I plan to use it to fix the problem.

    I guess what I’m looking for is any experiences by the scorched3d community with scorched3d and gcc3.3 or Xcode, as well as a list of packages from fink that scorched3d relies upon.

    The last course of action I’m willing to take is to install gcc3.1 and recompile everything. Before then I’d like to find out where this instruction is comming from, patch the source and contribute back to the community. As fun as scorched3d is — and as sadistic as this may sound — I enjoy debugging more.

    Anyways, here’s a snippet from the crash report, generated by OS X:

    Exception: EXC_BAD_ACCESS (0x0001)
    Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbf7fffe0

    Thread 0 Crashed:
    0 libwx_gtkd-2.4.0.dylib 0x06f16cdc 0x6cdc000 + 0x23acdc
    1 libwx_gtkd-2.4.0.dylib 0x06df0354 wxEvtHandler::ProcessEvent(wxEvent&) + 0x2c
    2 libwx_gtkd-2.4.0.dylib 0x06df0544 wxEvtHandler::ProcessEvent(wxEvent&) + 0x21c
    [repeats 505 more times]

    FYI, I cleaned my wxgtk fink files and rebuilt from scratch, so threads are enabled in wxgtk… I suppose there’s one place I could start…

    in reply to: Release schedule #10840


    Truly, your releases should be mandated by a set of predetermined features/bug fixes, not by any time table. Besides, there’s always cvs for those who just can’t wait.

    in reply to: main menu Busywaiting on unix platforms? (CVS) #10806


    The wxgtk.* files are still necessary…

    Try to compile scorched without patched wxgtk and it will fail…. The bug hasn’t ever been fixed, and I’m unsure if it ever will be.

    uh… I did… and indeed it does work. When was the last time you tried to build scorched3d against the latest wxgtk from fink? the Version: line in scorched/osx/ is, whereas the latest from fink is The two patch files are idententical.

    Of course, most OSX users of scorched will never need to know about this stuff, since I’m supplying libs with the scorched package nowadays.

    Its a real shame I never fall into these sorts of categories. I’d say I’d try harder, but that would be a lie.

    BTW, thankee for responding and helping out, gooch.

    I have but one regret, that I have but one life to give my scorched3d.

    ..I’ll try to remove my tongue from my cheek now.

    in reply to: main menu Busywaiting on unix platforms? (CVS) #10802


    Cool, got the trace. I may have an answer (or perhaps not)
    Could you try re-compiling wxWindows with no thread support.
    I think running configure with the –enable-threads=no command
    ./configure –enable-threads=no
    Then recompiling etc…

    ok… since wxgtk comes from fink, I had to add ‘–enable-threads=no’ to the file, as this is the only way I know to set custom configure options on fink packages… in general I’d rather not do this (btw, I don’t think the wxgtk.* files in the osx directory are necessary anymore), but I’m willing to make exceptions in the name of QA.

    so… after a ‘fink rebuild wxgtk’ and ‘make’ + ‘make install’ on scorched, everything appears to be running a lot better, almost if not exactly as good as when closing the main menu real quick before the game goes full screen (I did have Spin Control, Activity Monitor and iTunes running).

    I hope you can get things to work fine w/o having to disable wxgtk threads.

    in reply to: main menu Busywaiting on unix platforms? (CVS) #10800


    Just a small note to say I am looking at this, not ignoring you
    A stack trace would be good, thanks.

    I figured as much. I’ll email you the trace ASAP. I’ll also see about creating an Xcode project for this and see what I can find out… any pointers/caveats I should be aware of from your expierence with MSVC?

    I have just checked fedora core 1 and it does not have the problem either. Is it just mac os?

    It looks like it. I’ve been dying to try scorched3d out on OpenBSD 3.4. I just got that machine running last weekend, and am in the process of configuring & updating it, which takes a while over a modem. I’ll let you know whether or not I see this bug there.

    …I was wondering how you got those 100+ fsp gcamp… i’ve been lucky to squeak out a consistent 15.

    I think my geForce 4 is to thank for that , err and my well optimized code of course

    hmm…. i guess I’ll have to kick the wife off the windows machine for an evening… what sort of cpu do you have?

Viewing 15 posts - 1 through 15 (of 42 total)