Jump to content
Double Fine Action Forums


DFA Backers
  • Content Count

  • Joined

  • Last visited

About Screwtape

  • Rank
    Double Action Newbie


  • Display Backer Tags
  1. After downloading all the AF2014 games, this was the first I tried out. As expected, the visuals are utterly gorgeous and deliciously noir. Mad props to all the modellers, texture artists, and VFX people on the team. As for gameplay, I got slightly stuck once I picked up the photo (but eventually recovered through trial and error). I got very stuck when I had to get the key; this was the first puzzle where you had to get memories from two different places and use them in the same place in order to advance. I can understand why maybe you wouldn't want the game to be completely linear, but even normal adventure games have a reputation for requiring crazy dream logic, and Mnemonic is starts with crazy dream logic—as a player, the linearity of the puzzles was my lifeline in figuring out what the heck was going on. The interface, particularly for dealing with the inventory, was a bit clunky because the inventory was 'slippery'.. I'd get out an inventory item and then walk up to where I wanted to use it, and it would slip away before I got it in place. Then I'd bring it up again and left-click to use it, and nothing would happen, and while I started at the screen in confusion the item would slip away again. Eventually I'd remember to bring it up, hold right-click and *then* left-click, and get the "I wish that worked here, but it doesn't" message, and have to think of something else. I wish the normal "examine" mode (what happens when you hold right-mouse without an inventory object) were treated as an inventory item, like a magnifying glass or something. Then I could just mouse-wheel among all the inventory items whenever, right-click to hold them up, and left-click to use them. Everything would be consistent.
  2. As one of the people that complained about the lack of a DRM-free version of Act 1, thank you very much! I will very likely play the heck out of this, this weekend.
  3. OK, I got the segfault people have been discussing, so (before I looked at the forum and realised it was a common problem) I deleted the whole game from Steam and re-installed it, and now I'm not getting a segfault at all, I'm getting: $ ./run.sh mkdir: cannot create directory ‘lib’: File exists ./BrokenAge: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory It turns out this is because "run.sh" tries to make symlinks in the lib directory and screws things up: it creates a symlink named "lib/libSDL2-2.0.so.0" which links to "./lib/libSDL2-2.0.so.0.0.0", which means that applications wind up looking for "lib/./lib/libSDL2-2.0.so.0.0.0" which obviously doesn't exist. This fixes it: --- run.sh-orig 2014-01-27 13:44:05.339009057 +1100 +++ run.sh 2014-01-27 13:48:52.407792603 +1100 @@ -5,10 +5,10 @@ fi if [ ! -f ./lib/libSDL2.so ]; then - ln -s ./lib/libSDL2-2.0.so.0.0.0 ./lib/libSDL2.so + ln -sf libSDL2-2.0.so.0.0.0 ./lib/libSDL2.so fi if [ ! -f ./lib/libSDL2-2.0.so.0 ]; then - ln -s ./lib/libSDL2-2.0.so.0.0.0 ./lib/libSDL2-2.0.so.0 + ln -sf libSDL2-2.0.so.0.0.0 ./lib/libSDL2-2.0.so.0 fi LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:./lib ./BrokenAge $1 \ No newline at end of file As for the segfault, just in case this helps: $ LD_LIBRARY_PATH=$PWD/lib gdb ./BrokenAge [...] [New Thread 0xf779cb40 (LWP 29340)] [New Thread 0xf255db40 (LWP 29341)] [Thread 0xf255db40 (LWP 29341) exited] [New Thread 0xf255db40 (LWP 29342)] [New Thread 0xf655eb40 (LWP 29343)] Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x082d5f8f in MOAILuaClass::InitLuaFactoryClass (this=0x89fff78, data=..., state=...) at /dfp/burs/dfp-dfa-rc/Common/Code/Moai/src/moaicore/MOAILuaObject.cpp:856 #2 0x08514f2a in MOAILuaFactoryClass::Register (this=0x89fff78) at /dfp/burs/dfp-dfa-rc/Common/Code/Moai/src/moaicore/MOAILuaObject-impl.h:73 #3 0x08513a80 in MOAICoroutine::RegisterLuaType () at /dfp/burs/dfp-dfa-rc/Common/Code/Moai/src/moaicore/MOAICoroutine.h:55 #4 0x0851349c in moaicore::InitGlobals (globals=0x8a21238) at /dfp/burs/dfp-dfa-rc/Common/Code/Moai/src/moaicore/moaicore.cpp:109 #5 0x083d8de6 in AKUCreateContext () at /dfp/burs/dfp-dfa-rc/Common/Code/Moai/src/aku/AKU.cpp:143 #6 0x082b18c6 in GameRefreshContext (argc=4, argv=0xffffd6d0) at /dfp/burs/dfp-dfa-rc/Dfa/Code/Host-SDL/Src/SDLHost.cpp:1905 #7 0x082b17ca in GameHost (argc=4, argv_=0xffffd7e4) at /dfp/burs/dfp-dfa-rc/Dfa/Code/Host-SDL/Src/SDLHost.cpp:1772 #8 0x082b416f in SteamMain (argc=1, argv=0xffffd7e4) at /dfp/burs/dfp-dfa-rc/Dfa/Code/Host-SDL/Src/main.cpp:142 #9 0x082b4192 in main (argc=1, argv=0xffffd7e4) at /dfp/burs/dfp-dfa-rc/Dfa/Code/Host-SDL/Src/main.cpp:212 (gdb) up #1 0x082d5f8f in MOAILuaClass::InitLuaFactoryClass (this=0x89fff78, data=..., state=...) at /dfp/burs/dfp-dfa-rc/Common/Code/Moai/src/moaicore/MOAILuaObject.cpp:856 856 /dfp/burs/dfp-dfa-rc/Common/Code/Moai/src/moaicore/MOAILuaObject.cpp: No such file or directory. (gdb) info args this = 0x89fff78 data = @0xffffd598: { = { = {_vptr.RTTIBase = 0x89b1ee8, mRTTI = 0x87b61c4 , mThis = 0xfffffffe}, mCanary = 0xfffffffe}, _vptr.MOAILuaObject = 0x89b1ee8, mContain = { mRef = 142303684}, mMemberTable = {mRef = -2, mOwnsRef = 254, mWeak = 255, static STRONG_REF = false, static WEAK_REF = true}, mUserdata = { mRef = -11008, mOwnsRef = 254, mWeak = 255, static STRONG_REF = false, static WEAK_REF = true}} state = @0xffffd524: { _vptr.MOAILuaState = 0x87509e0 , mState = 0x89f0448} (gdb) info locals top = 0
  4. Sold: yes. Available?: no. You can buy it on Steam now but the game won't install yet. Ah. The "product release" announcement on the Steam store says "ACT 1 IS AVAILABLE NOW, AND THE ACT 2 CONCLUSION WILL ARRIVE AS A FREE UPDATE LATER THIS YEAR", but in other, more authoritative places it's exactly as you describe. Anyway, if the DRM-free version was going to be available on January 28th, instead of in 6 months' time with Act 2, I would be 100% OK with that. In that sense, sure, Broken Age isn't a "finished game". On the other hand, after January 28th it very definitely isn't a "backer-exclusive beta", either, so appealing to the authority of the Kickstarter page isn't very helpful: the Kickstarter page just doesn't cover this scenario at all. Broken Age Act 1 might not be the finished game, but it's a finished game, in that Double Fine feels it's complete and polished enough to release to the general public. My point is: I was led to believe I'd be playing a DRM-free game at the same time my non-backer friends were playing the game on Steam, and I'm disappointed that's not the case.
  5. The point is, Act 1 is being sold to the general public, so this is not the "backer-exclusive Steam beta" that the Kickstarter page talks about. I'm fine with the Kickstarter page, I wouldn't have backed if I wasn't, but this is a different situation.
  6. Nope. Revolution made a special DRM-free Linux build available on their own site in mid-December, rather than via Steam or GOG. I played the game through to completion under Linux without Steam, so I'm pretty sure that's the case.
  7. I agree that all the backers crying 'betrayal' are overreacting. It's not like Double Fine is going to force you to buy a lifetime subscription to SecuROM or anything. That said, when I first backed Broken Age nearly a year ago, I was perfectly happy with 'Steam-only beta, DRM-free release' because I assumed the beta would be a couple of weeks or a month at most, and then I could play the game DRM-free when it was fresh and new and people were talking about it. Now apparently the story is that Act 1 is Steam-only, beta and final, and the DRM-free release is going to be six months away. I've been watching the documentary episodes and reading the updates and feeling the love, and now I get to choose between shutting myself in a box for six months to avoid spoilers, or grabbing that Steam key and having fun while feeling just a bit dirty inside. That's not betrayal, but it is... disappointing.
  8. I'm sure you've already seen it, Oliver, but recently there was a blog-post doing the rounds reporting on different vendors' support for OpenGL ES 3.0; to summarise, desktop GPUs and drivers are reasonable, mobile GPUs and drivers are terrible. OpenGL ES 2.0 is more mature and I'm sure more reliably implemented than 3.0 seems to be, but have you had similar issues with unexpected bugginess, as opposed to the predictable differences in raw power?
  9. This seem to be the Linux Thread, so apologies for necromancy. When the Humble Double Fine bundle came out, Brütal Legend didn't work reliably on my system: the Double Fine logo didn't appear, the intro/main-menu appeared, and the first few seconds of gameplay worked but it would crash with a segfault soon afterwards (using Debian Testing and Intel HD4000 graphics). Just this week I upgraded to Kernel 3.9, Mesa 9.1 and the latest version of the xserver-xorg-video-intel, and now Brütal Legend runs. Not perfectly, it must be said - it's usually fine with just Eddie on-screen, but when Lars or his sister are around the framerate tanks, and there's occasional graphical glitches... still, I got at least as far as starting the Ironheade Army and spent a while roaming the countryside and admiring the scenery, so it's a whole lot better than it was. And such a delicious soundtrack!
  10. I logged out of the normal, composited mode of GNOME 3 and logged back in with "GNOME Classic" mode which isn't composited. It turns out that yes, things have indeed changed! - Stacking now seems to work perfectly - intro movie, music, main menu, etc. even setting resolutions and everything... right up to the point where I pick a save file and enter my name, then it crashes. - Costume Quest has pretty much the same behaviour. I pick a save-file, it draws a nice cartoony scene of a kid standing in the middle of the road in a suburban neighbourhood, and then it crashes. - Brutal Legend, too: now the 'Double Fine' logo movie plays, and I can tweak all the options in the menu quite nicely, but I still crash after running around a little bit in the first room. Now that I look a little closer, I see that at least the Costume Quest binary isn't stripped, which means that getting a gdb backtrace might actually be useful to the porters: Program received signal SIGSEGV, Segmentation fault. [switching to Thread 0xe8590b40 (LWP 21446)] 0x08a9fd47 in ParticleVertex::Fill(ParticleSystemData const*, ParticleState const*, float const*, unsigned int, vec3 const&, float const&, mat4 const&, ParticleVertex*) () (gdb) bt #0 0x08a9fd47 in ParticleVertex::Fill(ParticleSystemData const*, ParticleState const*, float const*, unsigned int, vec3 const&, float const&, mat4 const&, ParticleVertex*) () #1 0x08a7f85f in ParticleSnapshot::_RenderParticles(RenderContext*, TaskDispatcher*, mat4 const&) () #2 0x08a7fe07 in ParticleSnapshot::Render(RenderContext*, TaskDispatcher*, mat4 const&) () #3 0x08a1d7d2 in SceneFrame::_RenderShadedSnapshots(RenderContext*, RenderMessagePump*, RenderSnapshot**, unsigned int, GeomFilter, char const*) () #4 0x08a22b50 in SceneFrame::_RenderShadedPass(RenderContext*, RenderMessagePump*) () #5 0x08a2563f in SceneFrame::RenderShaded(RenderContext*, RenderMessagePump*) () #6 0x08a52779 in SceneGraph::_RenderThreadMainLoop(Thread*) () #7 0x084aedb6 in Thread::Run() () #8 0x084af382 in ThreadImpl::_StartFunc(void*) () #9 0xf7b2da0d in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #10 0xf793fe3e in clone () from /lib/i386-linux-gnu/libc.so.6 If there's any other information I can supply that would be helpful, please let me know!
  11. I get a variety of weird things. So far, I've had: - game creates a black window that fills the screen; I can hear menu-type music playing in the background but nothing ever appears, and my mouse-cursor is still visible. - game switches my desktop resolution to 1280x1024 (of all things), then crashes - most entertainingly, once the game just created a 1280x1024 window in the *middle* of my desktop, and another 1280x1024 black window at the top-left. Because the two windows were not exactly on top of one another, I could see a blue border at the edges of the 'middle' window, but the 'top-left' window obscured everything else. Unfortunately, the game had grabbed my keyboard and mouse input, so I couldn't alt-tab away or try and move the 'top-left' window completely out of the way. The other Buddha-engine games (Brutal Legend, Stacking) have similar results, and I haven't tried Psychonauts. This is all under GNOME 3, by the way. I'm going to try again under a non-compositing window manager and see if that makes any difference... if not, I'm kinda stuck.
  12. The Linux graphics stack is... complicated. Parts of it are in the kernel, libdrm, Mesa, the Xorg core and the Xorg drivers, and I have no idea where the GL extensions list is supplied. If you're running Debian on AMD64 and have enough i386 libs installed that Costume Quest can start, I assume you have multiarch configured already, so you should be able to just replace your 64-bit glxinfo with a 32-bit one to see what a 32-bit app sees. sudo apt-get install mesa-utils:i386 Of course, you can install "mesa-utils:amd64" afterward to replace the 32-bit version with the 64-bit version.
  13. I'm using Intel Ivy Bridge hardware on Debian Testing, and I believe that's pretty similar to Sandy Bridge - it certainly should be using the same drivers. You can check what extensions your drivers support with the "glxinfo" command-line tool. It produces bucket-loads of output, though, so pipe the result to 'less' or 'grep' or something. For what it's worth, on my machine glxinfo says (among other things): server glx vendor string: SGI server glx version string: 1.4 client glx vendor string: Mesa Project and SGI client glx version string: 1.4 GLX version: 1.4 OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop OpenGL version string: 3.0 Mesa 8.0.5 OpenGL shading language version string: 1.30 OpenGL extensions: (lots of output skipped) GL_ARB_depth_buffer_float, GL_ARB_half_float_vertex, ...so I definitely do have ARB_half_float_vertex support (Costume Quest still doesn't actually work for me, but it's not because of missing GL extensions). If you have the same versions listed under "OpenGL version string" and you *don't* have those extensions listed, maybe it's a limitation of the hardware, or maybe it's something they haven't implemented yet (there have been two Intel driver releases since the version in Debian Testing, hopefully the new versions will be packaged over the next few weeks now that Wheezy has been released). If glxinfo says you *do* have those extensions and the game says you *don't*.. well that's going to be very interesting to track down. It might indeed be something to do with not having some 32-bit library installed so it's falling back to software rendering or something (glxinfo won't tell you that, because it's a 64-bit app and can find the 64-bit drivers just fine).
  14. Confirming that a new twelfth episode, titled 'Episode 11', is now downloading in my browser (1.2GB).
  15. I'd heard there was a company-wide meeting after Amnesia Fortight was over, in which each team got to demonstrate their game to the rest of the company. I wanted to see that, and hoped there would be an Episode 11 to give some closure to the whole story which, right now kind of ends right before Opening Night. Anyway, a couple of days ago 2PP did an Ask Me Anything on Reddit, and in one answer Paul Levering said "We're still working on Amnesia Fortnight content" and later "We're currently working on a ton of AF stuff, and there will be better ways to experience that content. The whole thing was a big crazy experiment that turned out extremely well, so you'll have to forgive us for the bugs and bit of lag while we try to smooth the experience over." So, I remain hopeful.
  • Create New...