Ykkrosh

Works for me now - thanks

We're not currently planning that - it's just something that someone suggested, and so I started this forum topic to see if anyone had compelling concrete reasons to switch (but I haven't seen any so far, but I'm happy to wait ) Be aware that we have some patches in our version of Premake, and I don't think they were all sent/accepted upstream into standard Premake. You might experience some obvious or subtle errors, or missing features, when using the standard version, so it's not really recommended.

The messages are fairly obvious, so there's no need to translate - it's just failing to initialise the high-res timer correctly. Sounds like something for Jan (again )

The OpenAL shutdown discussion should probably move to this other thread, since it might be complex and this one is getting a bit cluttered. (I get the same problem so I've posted some debugger details in there, but I haven't tried working out what the problem actually is, since Jan probably would have a much better idea )

From the end of this post: If I start the game and then exit from the menu screen: vsrc_reclaim is first called from: #0 vsrc_reclaim (vs=0x971eb18) at ../../../source/lib/res/sound/snd_mgr.cpp:1613 #1 0x08495acf in VSrc_dtor (vs=0x971eb18) at ../../../source/lib/res/sound/snd_mgr.cpp:1207 #2 0x0848ad65 in h_free_idx (idx=62, hd=0x971eb00) at ../../../source/lib/res/h_mgr.cpp:609 #3 0x0848b06f in h_free (h=@0x987ea4c, type=0x859aac0) at ../../../source/lib/res/h_mgr.cpp:656 #4 0x08495090 in snd_free (hvs=@0x987ea4c) at ../../../source/lib/res/sound/snd_mgr.cpp:1322 #5 0x082e270f in JSI_Sound::Free (this=0x987ea00) at ../../../source/sound/JSI_Sound.cpp:164 #6 0x082e274e in ~JSI_Sound (this=0x987ea00) at ../../../source/sound/JSI_Sound.cpp:51 #7 0x082e3c2a in CJSObject<JSI_Sound, false>::DefaultFinalize (cx=0x8e69460, obj=0x986d388) at ../../../source/scripting/ScriptableObject.h:423 #8 0xb7a5fe42 in js_FinalizeObject () from /usr/lib/libjs.so #9 0xb7a44ed5 in js_GC () from /usr/lib/libjs.so #10 0xb7a2699c in js_DestroyContext () from /usr/lib/libjs.so #11 0xb7a1ee22 in JS_DestroyContext () from /usr/lib/libjs.so #12 0x082eebe8 in ~ScriptingHost (this=0x8e68370) at ../../../source/scripting/ScriptingHost.cpp:92 #13 0x08278527 in Shutdown (flags=0) at ../../../source/ps/GameSetup/GameSetup.cpp:805 #14 0x081dbe71 in RunGameOrAtlas (argc=1, argv=0xbfb7b894) at ../../../source/main.cpp:402 #15 0x081dbef1 in main (argc=1, argv=0xbfb7b894) at ../../../source/main.cpp:414 with *vs = {hvs = 270582941259, hsd = 274877908556, pos = {0, 0, 0}, gain = 1, pitch = 1, loop = 1 '\001', relative = 1 '\001', flags = 1, al_src = 160004984, static_pri = 0, cur_pri = 0, fade = {start_time = 0, type = FT_NONE, length = 0, initial_val = 0, final_val = 0}} It calls vsrc_deque_finished_bufs, which finds num_processed == 0 and so it doesn't do anything else. vsrc_reclaim isn't called again. snd_shutdown is called, and al_buf_free fails. This is with OpenAL Soft 1.7.411 on Gentoo, with ALSA.

As far as I'm aware the server is fine, and I can download that file with no problems, so it seems quite possible that it's a proxy/firewall problem. Not sure why it's failing on this file but working on some earlier ones, though . Also, I can't think of anything I could do on the server to make it work better (other than maybe setting up HTTPS access, which seems like a significant pain), so if it works for you at home then I'd be tempted to blame the firewall and ignore the problem

Thanks Hmm, is there some way we could modify the wiki to make that note more noticable? I think you have to register on Trac, and then there should be a 'new ticket' button to report issues. Yep - the idea is that for almost all external libraries we use, Linux/OS X users should install standard system-wide versions of the libraries. (That ensures they're up to date with e.g. security fixes, and the sharing saves disk space and memory, and they're much more likely to build successfully from the standard packages, etc). The 'libraries' directory is (mostly) provided just for Windows users, and includes the headers and precompiled Win32 .lib files, because Windows doesn't have an easy way to install system-wide libraries and we have to provide them all ourselves.So I think we don't need to make any changes, and if you stick with the system-wide version of DevIL then it should all work fine (Actually, I'm ignoring that we have a tweaked version of DevIL's source, which fixes a few bugs and does much better (though not great) DXTC compression. The bug-fixes really ought to be propagated upstream (if they're not fixed in the standard version already), and we ought to use something like NVIDIA's new open source library for DXTC compression. None of that matters unless you're using the game's Texture Converter tool to create DDS files, though.)

Hmm, I assume that's what you see when you run update-workspaces.sh? It looks like warnings from compiling the Lua interpreter that's embedded in Premake. It's not used as part of the game itself, so I probably wouldn't care much about the warnings if update-workspaces still runs correctly. (They're a bit ugly, though...)

I've added -Wl,--no-undefined and the extra links to make that work. I haven't changed the wx thing yet - I don't understand why it fails when it works fine for me (and I don't think anyone else has reported the same problem?), so it's hard to know what fix is correct and to test it, and also I can't figure out how to make Premake put the wx links at the end . Anyone have any ideas here?

Oops - fixed that now. Thanks!

Committed your fixed version to SVN. Thanks! We're more active here than on Trac, though posting patches to Trac is probably a better idea since it reduces the chance of them slipping through cracks.

Hmm, yeah, the entity management and aura code is sometimes a little unreliable. I don't know what the exact problem is, but that area of the code will probably have to be reviewed and fixed at some point in the future, to hopefully stop the random crashes

Yep, go into there and then run "./test_dbg" for the automated tests, or "./pyrogenesis_dbg" for the game, or "./pyrogenesis_dbg -editor" for the map editor.

The best we have right now is the list of tickets on Trac. It's a bit rough and inconsistent - I think there's a lot of scope for improving it to make it more useful for tracking progress and assigning tasks. It would probably be good to discuss this with MrChocolateBear, who joined us recently to help with this kind of thing

Hmm, that's not a problem I've ever seen. Since it seems to be complaining about the download, perhaps you could try the offline installer instead (near the bottom of the download page)?

I think the requirements for the build system include: * Needs to work on Windows, Linux, and OS X. * Needs to generate Visual Studio (2005, 2008) project files for Windows. * Needs to be portable to the more common Linux distributions. * Needs to be efficient - clean builds and incremental builds shouldn't be much slower than the current make system on Linux and the VC++ build system on Windows, since (at least in my opinion) long build times are really painful and must be minimised. * Needs to handle precompiled headers (for GCC and VC++). * Needs to be relatively easy to maintain (adding source files, adding new project libraries, adding new external libraries). * Possibly other things that I can't think of right now. I'm not familiar with SCons, but it looks like it should be able to handle those things; the only one I'm particularly unsure about is performance, since the only data I know is this article indicating it was awfully slow many years ago. I'm not familiar with CMake either, but it looks like it should handle those things too, but I have no idea about its performance. There's also the option of extending Premake to handle whatever new features are needed. (We use a slightly patched copy of an old version, and I'd be happy with patching its C code further - I don't think there's much value in trying to maintain a clean copy or tracking new upstream versions, since all we need is a version that works for our one specific project). My natural preference is for that conservative option, since it avoids the risk of switching to a completely new system and finding a load of new problems and wasting time catching up to the state we already had - I think there would have to be really compelling reasons to switch, in terms of providing features that would be impossible or infeasible to implement in our current system. So I suppose an important question is how complex it would be to do .app-bundling and static linking for OS X, just by extending the Lua or C code in Premake. (Unfortunately I have no idea how to answer that question!)

I'm copying this from Trac #257 since it seems like a topic that needs discussion, and the forum is a more convenient medium for discussions:

You can blame the "ogl_tex.cpp(697): Performance warning: your graphics card does not support compressed textures" message on the graphics drivers, and the Continue/Break/etc message is a consequence of that. It might be possible to avoid the warning by enabling S3TC as in http://dri.freedesktop.org/wiki/S3TC (e.g. with the x11-libs/libtxcdxtn package on Gentoo) - otherwise the game will decompress its textures and use a load more RAM than it ought to (hence the warning).

You have a non-threadsafe version of SpiderMonkey, and it needs to be recompiled with the threadsafety feature. What OS/distro are you using? Some come with the right version as standard, but probably not all. Gentoo makes it configurable with USE=threadsafe. It might be necessary to compile it yourself to get the right version.

I've uploaded this version (and added language links in the corner). Hopefully I didn't make too many mistakes, but I can't easily check it myself . Let me know if there are any problems, or if any of the remaining English text should be translated too. Thanks for this!

Whoops, there was a "file[DBG_FILE_LEN]=0;" which quite possibly triggered that stack-smashing error. Fixed in SVN now.

That's great! I'll add it to the site later today

You need to register on Trac, then create a new ticket with a brief description of what caused the crash, and attach the files there. Or you could probably attach the files in a forum post here, which might be easier . (The .dmp file is useful since we (or anyone with Visual Studio) can open it in a debugger and hopefully see where the problem is occurring.)

Just out of interest (since it won't make much of a difference in terms of the game being properly playable): What does "glxinfo | grep renderer" say? Hmm, looks a bit like game is trying to print a stack trace for the your-graphics-card-is-too-slow warning, and the stack is getting corrupted while trying to do that. I have no idea why it wouldn't work, though... Could you perhaps try modifying source/lib/sysdep/os/linux/ldbg.cpp around line 127 (in debug_DumpStack, just before the "return INFO::OK" line) and add printf(">>>\n%ls<<<\n", buf);and then compile and run and then (hopefully) it'll print a new message before the "*** stack smashing detected ***" which you could post here. It looks like 915 is GMA900, 945 is GMA950, so they're different hardware (though on Linux the i915 drivers are used for both).

I can run the game (very slowly) on an Intel 945GM, but don't know about 915. That backtrace doesn't look very informative - could you try running it in gdb to see where it says it's failing? ("gdb ./pyrogenesis_dbg", then "r", then wait until it dies, then "bt", then "q")