Comment on attachment 2525[details]
glxinfo on failed system
Ubuntu 10.10 64bit
Should be an easy fix, most likely the code just requires some obscure extension which can be worked around.(especially seeing as it works on windows afaik)
(In reply to comment #3)
> (From update of attachment 2525[details])
> Ubuntu 10.10 64bit
> Should be an easy fix, most likely the code just requires some obscure
> extension which can be worked around.(especially seeing as it works on windows
> afaik)
I'd think it runs through DirectX in Windows, since it was first released for the Xbox 360. Anyway, do you have access to Windows on the same machine to test it?
I get almost the same error on Fedora 64 bit and Nvidia binary drivers for a 8600 GT GPU (I'm able to run any other OpenGL game).
[urfe@localhost braid]$ ./braid
Game Startup Error: Unable to set up graphics.
Reason: Failed to initialize OpenGL display.
To help fix this problem make sure you are running the newest version of your video drivers.
Lastly, you could try running this game with the -windowed command-line option.
Just to let you know. I have updated all Xorg packages from the X Updates PPA (where, by the way, the Intel driver is at version 2.13.901-2ubuntu2~xup~maverick) and I still see this error.
I get the same error here on 64bit arch-linux with an intel graphics card (lib32-intel-dri etc from multilib repo)
Running ltrace on the binary revealed that the unsupported extension is:
GL_EXT_texture_compression_s3tc
Changing this to be optional or using one of the supported texture compressions should be easy, as texture compression doesn't give you any functionality besides reduced vram usage AFAIK.
(In reply to comment #10)
> I get the same error here on 64bit arch-linux with an intel graphics card
> (lib32-intel-dri etc from multilib repo)
>
> Running ltrace on the binary revealed that the unsupported extension is:
>
> GL_EXT_texture_compression_s3tc
>
> Changing this to be optional or using one of the supported texture compressions
> should be easy, as texture compression doesn't give you any functionality
> besides reduced vram usage AFAIK.
Funny, I just decided to do the same thing.
And yeah, GL_EXT_texture_compression_s3tc is missing:
strstr("GL_ARB_copy_buffer GL_ARB_depth_"..., "GL_EXT_texture_compression_s3tc") = NULL
_Znaj(256, 3, 3, 8, 27) = 0xa37d298
vsnprintf("!!! Missing OpenGL extensions EX"..., 256, "!!! Missing OpenGL extensions EX"..., 0xbfe81228) = 60
The work around involves decompressing all the textures, hopefully Ryan already has the uncompressed source.
I did some Googling, and apparently GL_EXT_texture_compression_s3tc is disabled on the open source drivers because it is covered by a patent and requires a licence.
But if you live in a country were the patent doesn't apply you can enable it using driconf (apt-get install driconf) under the Image Quality tab.
(In reply to comment #13)
> I did some Googling, and apparently GL_EXT_texture_compression_s3tc is disabled
> on the open source drivers because it is covered by a patent and requires a
> licence.
>
> But if you live in a country were the patent doesn't apply you can enable it
> using driconf (apt-get install driconf) under the Image Quality tab.
Thank you Scott! I just want to confirm that this was indeed the issue. I've enabled the option in driconf and now Braid runs flawlessly. I've given this solution to others in ubuntu forums and blogged about it (giving you credit for the solution) so it doesn't get burried here.
I hope they will eventually release an update that uses an alternate compression for the textures instead of this patented algorithm.
Thanks
KaKaRoTo
It didn't work for me (32 bit Ubuntu 10.10, Intel 945GM).
I used driconf and changed the relevant setting, and indeed the game started - except that all I saw was my mouse and a black screen. Nothing happened for several minutes, and I was forced to ctrl-alt-backspace out of X. But maybe that's a second, separate error?
Oh, yeah, I guess I have a different error now:
i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4)
i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4)
i915_program_error: Exceeded max ALU instructions (83 out of 64)
Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 137 (DRI2)
Minor opcode of failed request: 8 ()
Resource id in failed request: 0x460000f
Serial number of failed request: 150
Current serial number in output stream: 150
(In reply to comment #16)
> Oh, yeah, I guess I have a different error now:
>
> i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4)
> i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4)
> i915_program_error: Exceeded max ALU instructions (83 out of 64)
> Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
> Major opcode of failed request: 137 (DRI2)
> Minor opcode of failed request: 8 ()
> Resource id in failed request: 0x460000f
> Serial number of failed request: 150
> Current serial number in output stream: 150
Sounds like the pixel shader is too complex for your video card.
Perhaps you should file a separate bug.
(In reply to comment #16)
> Oh, yeah, I guess I have a different error now:
>
> i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4)
> i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4)
> i915_program_error: Exceeded max ALU instructions (83 out of 64)
> Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
> Major opcode of failed request: 137 (DRI2)
> Minor opcode of failed request: 8 ()
> Resource id in failed request: 0x460000f
> Serial number of failed request: 150
> Current serial number in output stream: 150
Yeah, it's a different issue, I suggest you open a new bug report for that one.
> I hope they will eventually release an update that uses an alternate
> compression for the textures instead of this patented algorithm.
Fwiw, the reason that s3tc gets used is because it stays compressed in video RAM, and the GPU knows how to access the compressed data as-needed. Every modern game uses it.
It's not the same thing as switching out gzip for bzip2, or something.
--ryan.
That's interesting. The Windows version under Wine runs fine without GL_EXT_texture_compression_s3tc. I seem to recall that it used a custom texture compression scheme (which was probably better suited to the kind of images in the game too).
Also, enabling s3tc just crashed the GPU and made me have to reboot. I don't think the open source drivers for the Radeon 4650 even support it yet.
It fails for me on a Radeon 4870, using KMS, with Mesa 7.9 and xf86-video-ati 6.13.2, which is hardly old by any standards: it has shader support and advertises OpenGL 2.1, but apparently that's not whizzy enough, even though advertising this is so bleeding-edge by Linux free driver standards that barely two months ago no released version of Mesa could do it.
GL_EXT_texture_compression_s3tc is of course not advertised: if I force it on, I get a slightly-scrambled-looking startup screen, then a black screen with a flash of garbage at the top (looking oddly like someone had tried to emit tiled data on an untiled display: currently it looks like tiling is turned off for me, though I'm not sure why), then the monitor signal is permanently lost until reboot and braid becomes nonresponsive to anything but kill -9.
(I couldn't try it with fglrx, as that coredumps the X server whenever it's installed. I don't think it supports anything as new as the 4870 anyway.)
What was this *tested* on? It fails for Intel users. It fails for ATI users. It fails for nvidia binary driver users. Does *any* Linux driver at all support s3tc?
(And why wasn't this huge restriction advertised in the Humble Indie Bundle 2 before we paid for it? I have had half a dozen video cards over the years. Not a single one has ever advertised this extension, so you'd think its presence would be a significant thing to need to check for. I'm feeling a bit ripped off now. The original Bundle worked perfectly, but at least two things in Bundle 2 require s3tc...)
It works on my laptop (graphics hw is GM45), despite it being amd64. There is some flickeriness in some places; transparency problems?
It fails on my desktop box (Radeon X300, and stuck with that with its current motherboard), though I "installed" libtxc-dxtn0 from debian-multimedia (had to extract from the .deb; i386 code on an amd64 system). The window is displayed for several seconds, remaining black, then the game exits. No obvious reason as to why.
> (And why wasn't this huge restriction advertised in the Humble Indie Bundle 2
> before we paid for it? I have had half a dozen video cards over the years. Not
> a single one has ever advertised this extension, so you'd think its presence
> would be a significant thing to need to check for. I'm feeling a bit ripped off
> now. The original Bundle worked perfectly, but at least two things in Bundle 2
> require s3tc...)
This restriction was not known (I do not speak for them). I have tested it on an nvidia 9800 running ubuntu 10.10 and the standard drivers for such, and it works fine. Your card supports GL_EXT_texture_compression_s3tc. MOST cards in the past ten years support it. The extension is disabled in opensource drivers due to patent issues (Or something along those lines). It should work fine in windows using the exact same extension. The problem you are experiencing must be related to something else (since you enabled it in driconf). This restriction in the drivers was not expected. Your card supports the extension just fine; this is not a hardware restriction.
OK, so that's a driver bug, then. Not unsurprising, I'll report it to the Mesa people.
(Sorry for my snippiness, but I just spent $40 on the Bundle only to find that the only game out of the whole lot which worked was Osmos, which I already owned! At least this one is an apparent driver problem, which is always going to be hard to detect at testing time...)
(In reply to comment #21)
> It fails for me on a Radeon 4870, using KMS, with Mesa 7.9 and xf86-video-ati
> 6.13.2, which is hardly old by any standards: it has shader support and
> advertises OpenGL 2.1, but apparently that's not whizzy enough, even though
> advertising this is so bleeding-edge by Linux free driver standards that barely
> two months ago no released version of Mesa could do it.
>
> GL_EXT_texture_compression_s3tc is of course not advertised: if I force it on,
> I get a slightly-scrambled-looking startup screen, then a black screen with a
> flash of garbage at the top (looking oddly like someone had tried to emit tiled
> data on an untiled display: currently it looks like tiling is turned off for
> me, though I'm not sure why), then the monitor signal is permanently lost until
> reboot and braid becomes nonresponsive to anything but kill -9.
>
> (I couldn't try it with fglrx, as that coredumps the X server whenever it's
> installed. I don't think it supports anything as new as the 4870 anyway.)
>
> What was this *tested* on? It fails for Intel users. It fails for ATI users. It
> fails for nvidia binary driver users. Does *any* Linux driver at all support
> s3tc?
>
> (And why wasn't this huge restriction advertised in the Humble Indie Bundle 2
> before we paid for it? I have had half a dozen video cards over the years. Not
> a single one has ever advertised this extension, so you'd think its presence
> would be a significant thing to need to check for. I'm feeling a bit ripped off
> now. The original Bundle worked perfectly, but at least two things in Bundle 2
> require s3tc...)
It works for me on an Intel card. And I don't see how you would expect them to advertise this for the first linux release, they don't know yet about all the possible issues. give it time.
And when I read your post about being ripped off, I just facepalmed and couldn't believe someone would actually say something like that... how much did you even pay for it? 1$? You're getting 5 games for what amounts to a *donation*, so I don't think you can even complain about the price, or the content, or even have the right to talk about being "ripped off".
No, I paid $40 because I don't believe in ripping people off and I think development deserves reward. (I also kept it anonymous until challenged about it.)
I just have this strange belief that software should work and was looking forward to a nice pile of gameplaying after a hard day, instead of which I got three games that fail in different ways (one a driver bug, one a silly one-character typo in a filename generator which can't be fixed because the game is closed-source, one an undeclared dependency which is only diagnosable via strace because the thing is dlopen()ed: without it, you just get a coredmup) and one game that worked but that I already owned.
Pardon me for being a bit tetchy. It is true that this one is the hardest thing for the developers to detect at testing time. That's why I reported it as a probable bug in the first place. (Also, I know the Icculus guys care about bug reports.)
Also: read what I said. I was *feeling* a bit ripped-off (understandable, I think). That's different from thinking I actually *have* been ripped-off: obviously not, this is a series of unfortunate bugs, not a conspiracy, and nobody *wants* me to not have a game after I paid for it.
But, still, with a failure rate of 100% in this Bundle for me (Osmos works, but only because I hacked its included font by hand, as recent FreeTypes reject it as part of a security fix) I can sort of understand why Linux games haven't taken off much with the general public. (The previous Bundle had a success rate of 100% for me.)
You answer fast! Here is what I originally wrote before you responded :
(In reply to comment #25)
> OK, so that's a driver bug, then. Not unsurprising, I'll report it to the Mesa
> people.
>
> (Sorry for my snippiness, but I just spent $40 on the Bundle only to find that
> the only game out of the whole lot which worked was Osmos, which I already
> owned! At least this one is an apparent driver problem, which is always going
> to be hard to detect at testing time...)
Just saw this comment, sorry for my 'snippiness' against you too, the "being
ripped off" triggered it. My point is that you can't be 'ripped off' in a
'pay-what-you-want' system.
Sorry to others for spamming their inbox with these messages.
If you have a bug with the game after enabling s3tc, then I suggest you report
a bug (different to this one) so it can get fixed.
(In reply to comment #27)
> No, I paid $40 because I don't believe in ripping people off and I think
> development deserves reward. (I also kept it anonymous until challenged about
> it.)
>
> I just have this strange belief that software should work and was looking
> forward to a nice pile of gameplaying after a hard day, instead of which I got
> three games that fail in different ways (one a driver bug, one a silly
> one-character typo in a filename generator which can't be fixed because the
> game is closed-source, one an undeclared dependency which is only diagnosable
> via strace because the thing is dlopen()ed: without it, you just get a
> coredmup) and one game that worked but that I already owned.
>
> Pardon me for being a bit tetchy. It is true that this one is the hardest thing
> for the developers to detect at testing time. That's why I reported it as a
> probable bug in the first place. (Also, I know the Icculus guys care about bug
> reports.)
Well, I agree with you, and I understand your frustration, but if I may just say this : "Testing can never prove that a software is bug-free, it can only prove that it has bugs" (some similar quote I heard a while ago)
(In reply to comment #28)
> Also: read what I said. I was *feeling* a bit ripped-off (understandable, I
> think). That's different from thinking I actually *have* been ripped-off:
> obviously not, this is a series of unfortunate bugs, not a conspiracy, and
> nobody *wants* me to not have a game after I paid for it.
>
> But, still, with a failure rate of 100% in this Bundle for me (Osmos works, but
> only because I hacked its included font by hand, as recent FreeTypes reject it
> as part of a security fix) I can sort of understand why Linux games haven't
> taken off much with the general public. (The previous Bundle had a success rate
> of 100% for me.)
You beat me to another submit click :) I personally bought both bundles, but didn't really play any of those games, only World of Goo for the first one, and in this bundle, well, I had already bought Braid on PSN and finished it a dozen times :)
And no worries, when I first saw your message (this morning while waking up), I thought it was one of those n00bs who just want to cry and blame the world and request everything be given to them on a silver platter. After reading your second post, I realized that I misunderstood the first post. No worries. I hope we can all get these games fixed somehow, reporting bugs is the first step, and hopefully, if they make it open source like they did for the first bundle, then maybe we can start submitting patches too :)
Good luck.
(In reply to comment #20)
> That's interesting. The Windows version under Wine runs fine without
> GL_EXT_texture_compression_s3tc. I seem to recall that it used a custom texture
> compression scheme (which was probably better suited to the kind of images in
> the game too).
The Windows version uses DXT5 textures, too (this is called "s3tc" format in OpenGL). My guess is that Wine is noticing that the game wants to use S3TC but the Linux GL doesn't support it, and uncompresses the textures on the CPU, uploading them as uncompressed RGBA textures instead.
We could certainly do this ourselves in Braid, but it seems crazy to work around functionality that OpenGL drivers could, but willfully refuse to, provide. Also, if the primary concern is patent infringement, it's pure insanity to decompress S3TC data and then expect every application to infringe the patent instead.
Also: my techie soul is offended by the inefficiency of this approach. :)
That being said, if S3TC is the _only_ thing stopping the game from running, I'll probably work around it in a future build...but it looks like we're hitting shader issues in the drivers, too.
--ryan.
Created attachment 2527[details]
Braid with s3tc textures missing.
This is a screenshot of the opening screen of the game without any of the S3TC textures. If the blacked out parts are scrambled-looking on your system, the S3TC support is busted.
(In the house, the puzzles on the walls are s3tc along with other things. In the levels, most things are NOT, if they aren't characters/monsters.)
--ryan.
Yep, that's exactly what I see (before a pulse of noise at screen top and everything going dark forever, which really does sound like a driver/KMS bug: I'll upgrade everything to stable-latest and report it this weekend when I'm not recovering from flu anymore).
It does sound like rather crucial parts of the game are s3tc-compressed...
Ryan,
Is it possible the drivers on some Intel hardware are not actually programmed to support s3tc properly for that hardware. And since they had it disabled anyway, they did not bother to make it work on that specific hardware? The game appears to run fine on my Intel hardware once I force it to be enabled. However, it appears some people have not had the luck I have.
(In reply to comment #21)
> What was this *tested* on? It fails for Intel users. It fails for ATI users. It
> fails for nvidia binary driver users. Does *any* Linux driver at all support
> s3tc?
Works fine on nvidia binary drivers here, which have had s3tc support since,
say, the first release ever.
I want to be clear about this: s3tc isn't some new, zany technology. This is
sort of like getting mad at a website for having .gif files because your web
browser is overly-concerned about Unisys's patent.
> (And why wasn't this huge restriction advertised in the Humble Indie Bundle 2
> before we paid for it? I have had half a dozen video cards over the years. Not
> a single one has ever advertised this extension, so you'd think its presence
> would be a significant thing to need to check for. I'm feeling a bit ripped off
> now. The original Bundle worked perfectly, but at least two things in Bundle 2
> require s3tc...)
That's because it's silly to not support an extension that has been available
in even the worst 3D hardware of the past 10 years.
"You need reasonable graphic drivers" isn't what I would define as fine print.
If you genuinely feel like you were cheated, I will personally refund your
Humble Bundle donation out of my own pocket, and you have my apologies. But
otherwise, your outrage is better directed at your driver developers, who I
have no doubt are improving things now that Braid is available as a new test
case for them.
--ryan.
> But, still, with a failure rate of 100% in this Bundle for me (Osmos works, but
> only because I hacked its included font by hand, as recent FreeTypes reject it
> as part of a security fix) I can sort of understand why Linux games haven't
> taken off much with the general public. (The previous Bundle had a success rate
> of 100% for me.)
I'll ping you by private mail, perhaps I can nag some of the other developers for updates on your behalf.
--ryan.
Sorry, Ryan, I shouldn't have exploded at you. I didn't realise until after reporting this bug that this was actually the first release of Linux Braid *ever*, so bugs were more to be expected than otherwise. (The other games in the set have been out for many months, so I assumed the same was true of this one.)
This was just the last game I tried and (get this) the *only one* with an accessible bug-reporting mechanism that I could find. The 100% failure rate (for those games I didn't already own) just narked me off a bit, is all. I'm sure the support for this one, at least, will improve, though I don't hold out much hope for the others (one of them uses the Flash Player, for goodness' sake, small surprise all I see is a black screen given what awful code *that* is known to contain).
(In reply to comment #36)
> Sorry, Ryan, I shouldn't have exploded at you. I didn't realise until after
> reporting this bug that this was actually the first release of Linux Braid
> *ever*, so bugs were more to be expected than otherwise. (The other games in
> the set have been out for many months, so I assumed the same was true of this
> one.)
>
> This was just the last game I tried and (get this) the *only one* with an
> accessible bug-reporting mechanism that I could find. The 100% failure rate
> (for those games I didn't already own) just narked me off a bit, is all. I'm
> sure the support for this one, at least, will improve, though I don't hold out
> much hope for the others (one of them uses the Flash Player, for goodness'
> sake, small surprise all I see is a black screen given what awful code *that*
> is known to contain).
Actually, from http://blog.wolfire.com/2010/12/Humble-Indie-Bundle-2---IT-S-ALIVE
It says "If you haven't heard of Revenge of the Titans before, it's because it is being launched directly into the bundle. Another cool Humble Bundle exclusive is that Braid and Cortex Command are available on Linux for the first time inside of the bundle."
So actually, three of the games are being released for the first time (2 of them being first linux release), so it's not just Braid that's just been released for Linux :) That might explain why you're having trouble with other games too, they still need some polishing.
@Ryan C. Gordon: Thanks for the responsiveness and for this bugzilla. We appreciate the work you've done on porting Braid, and the continued support :)
Created attachment 2528[details]
Works? Or is there something wrong????
$ braid/braid -windowed
i915_program_error: Exceeded max nr indirect texture lookups
i915_program_error: Exceeded max nr indirect texture lookups
i915_program_error: Exceeded max ALU instructions
After ~5 minutes, I got this!
(In reply to comment #11)
> Same error with an Intel Core i3 (integrated graphics on-processor-die) and
> up-to-date Debian Sid (xserver-xorg-video-intel, Version: 2:2.13.0-4).
Fixed by installing libtxc-dxtn0 from debian-multimedia. Didn't even have to use driconf or restart X, the driver picked up the change.
for 64 bits users who have s3tc on glxinfo but the game give this bug: install the 32 bit version of ur driver(lib32-nvidia-utils for me on arch linux)
(In reply to comment #20)
> Also, enabling s3tc just crashed the GPU and made me have to reboot. I don't
> think the open source drivers for the Radeon 4650 even support it yet.
I have reported the Radeon GPU lockup to DRI upstream. Anyone who also experiences this, please chime in with your details in the bug report: https://bugs.freedesktop.org/show_bug.cgi?id=32447
Btw: the driver resets the GPU after 10 seconds, after which you can switch to a text console and kill braid to rescue your graphics card. :)
Btw, according to this...
http://dri.freedesktop.org/wiki/S3TC
...enabling the extension with driconf--but without installing the libtxc_dxtn package--will tell games that you have support, and then intentionally do the wrong thing (which explains Attachment #2528[details]).
--ryan.
> ...enabling the extension with driconf--but without installing the libtxc_dxtn
> package--will tell games that you have support, and then intentionally do the
> wrong thing (which explains Attachment #2528[details]).
...actually, it doesn't. Tim should be a DXT5 texture, too, but he's rendering okay. That might just be a bug in the drivers.
--ryan.
A minor note: I wasn't aware of the existence of libtxc_dxtn, and didn't have it installed (a lot of distros don't carry it because of its patented status). Its homepage appears to have vanished, but there is a git tree at git://github.com/nobled/libtxc_dxtn.git which appears to be the right thing.
However, even with this installed and GL_EXT_texture_compression_s3tc and GL_S3_s3tc both being advertised by the drivers, Braid still tells me "Missing required OpenGL extension."
I tried using driconf to force on s3tc support as well (which would, you'd have thought, now do nothing). It has a considerable effect.
One of two things happen, with a probability of apparently about 50% (with non-Gallium Mesa 7.9, latest as of now). Possibility 1:
For two seconds I see the startup screen, s3tc parts and all. But before the opening chord has finished, the game coredumps, and I see a stream of at least hundreds of
unsupported texture format in setup_hardware_state
failed to validate texture for unit 0.
unsupported texture format in setup_hardware_state
failed to validate texture for unit 0.
unsupported texture format in setup_hardware_state
failed to validate texture for unit 0.
unsupported texture format in setup_hardware_state
failed to validate texture for unit 0.
with this coredump, which, again, looks like a bug in the drivers. I'll report this one upstream if you agree.
#0 radeonEmitVec4 (out=0xd1c50b60, data=0xa35d978, stride=28, count=324) at radeon_dma.c:69
#1 0xf4165eaa in r700SetupStreams (ctx=0xa005ff0, arrays=0xa04aadc, prim=0xffd6497c, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=323) at r700_render.c:688
#2 r700TryDrawPrims (ctx=0xa005ff0, arrays=0xa04aadc, prim=0xffd6497c, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=323) at r700_render.c:929
#3 r700DrawPrims (ctx=0xa005ff0, arrays=0xa04aadc, prim=0xffd6497c, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=323) at r700_render.c:1005
#4 0xf4256c23 in vbo_exec_DrawArrays (mode=7, start=0, count=324) at vbo/vbo_exec_array.c:526
#5 0xf424d317 in neutral_DrawArrays (mode=7, start=0, count=324) at main/vtxfmt_tmp.h:327
#6 0x081974cb in Display_System_OGL::immediate_flush() ()
#7 0x080cdfd1 in draw_intro_notification(float, char*, char*) ()
#8 0x080cf9e4 in draw_overlays_for_gameplay() ()
#9 0x080d0c2a in draw_world_view() ()
#10 0x080eaed1 in draw_game_mode() ()
#11 0x080eda1e in app_main(int, char**) ()
#12 0x0815223e in main ()
Possibility 2, I see a pattern of noise on the screen for about five seconds, then blackness bar a cursor for five seconds, then noise again, repeated endlessly: the machine becomes noisier than I have ever heard it as the GPU fan (?) spins up to maximum (the CPU is unloaded, so that can't be it). Kill -9ing all braids from another session (via ssh) leads to a pattern of garbage at the top of the screen identical to the pattern I reported earlier (thus, that pattern was probably produced when the game crashed). chvt 1; chvt 7 gets us back to a working system, with a dozen or so
unsupported texture format in setup_hardware_state
failed to validate texture for unit 0.
visible.
> with this coredump, which, again, looks like a bug in the drivers. I'll report
> this one upstream if you agree.
I agree, that sounds like a driver bug.
I should be releasing a build of Braid that doesn't need s3tc soon, which might solve this problem, too.
--ryan.
(In reply to comment #43)
> > ...enabling the extension with driconf--but without installing the libtxc_dxtn
> > package--will tell games that you have support, and then intentionally do the
> > wrong thing (which explains Attachment #2528[details] [details]).
>
> ...actually, it doesn't. Tim should be a DXT5 texture, too, but he's rendering
> okay. That might just be a bug in the drivers.
>
> --ryan.
It looks like the extension includes support for taking the compressed texture and sending it to the hardware still compressed, which will work. It also includes support for asking for conversions, which would break, but Braid (probably) doesn't do this.
It looks to me like broken image has the right color channels, but all 100% in the alpha channels for those textures. I've also got the same problem, and walking around by the title screen so that it shows some of the tan/red/brown layers at different depths which look right except that they have right-angle corners, which you can see clearly because they move separately from the other layers. I've also noticed that I'm using UXA (search Xorg.0.log) and people have reported bugs with UXA, transparency, and intel. Might want to ask if people getting that image are using UXA. I think the whole s3tc thing might even be a distractor here: IIRC, you said the layers I'm seeing with inappropriate hard edges aren't compressed. I'm going to try messing with my xorg.conf and see if that helps.
There's a new build of Braid on humblebundle.com which will work without s3tc support in your drivers (we uncompress the textures inside braid and upload them as uncompressed RGBA data if we don't see s3tc support available).
There's also a 64-bit binary included now, too, if that's your thing.
Download is available with your existing humblebundle purchase key, just go redownload it (filename should be braid-linux-build2.run.bin).
Enjoy!
--ryan.
(In reply to comment #48)
> There's a new build of Braid on humblebundle.com which will work without s3tc
> support in your drivers (we uncompress the textures inside braid and upload
> them as uncompressed RGBA data if we don't see s3tc support available).
>
> There's also a 64-bit binary included now, too, if that's your thing.
>
> Download is available with your existing humblebundle purchase key, just go
> redownload it (filename should be braid-linux-build2.run.bin).
>
> Enjoy!
>
> --ryan.
Good job, thanks! And congratulations for great support!
Just a question though, how about those drivers that say they support S3TC but end up crashing or showing wrong data? Could there be a -no_s3tc command line option to force it to uncompress the textures?
Also completely unrelated (should I open a separate 'bug' report?) why isn't the official README file (from the windows build) provided with the linux version? The windows README gives a few interesting command line options that might be useful to users (like how to set the language, no post processing, etc..)
Thanks.
KaKaRoTo
Created attachment 2525 [details] glxinfo on failed system
Comment on attachment 2525 [details] glxinfo on failed system Ubuntu 10.10 64bit Should be an easy fix, most likely the code just requires some obscure extension which can be worked around.(especially seeing as it works on windows afaik)
> I hope they will eventually release an update that uses an alternate > compression for the textures instead of this patented algorithm. Fwiw, the reason that s3tc gets used is because it stays compressed in video RAM, and the GPU knows how to access the compressed data as-needed. Every modern game uses it. It's not the same thing as switching out gzip for bzip2, or something. --ryan.
> (And why wasn't this huge restriction advertised in the Humble Indie Bundle 2 > before we paid for it? I have had half a dozen video cards over the years. Not > a single one has ever advertised this extension, so you'd think its presence > would be a significant thing to need to check for. I'm feeling a bit ripped off > now. The original Bundle worked perfectly, but at least two things in Bundle 2 > require s3tc...) This restriction was not known (I do not speak for them). I have tested it on an nvidia 9800 running ubuntu 10.10 and the standard drivers for such, and it works fine. Your card supports GL_EXT_texture_compression_s3tc. MOST cards in the past ten years support it. The extension is disabled in opensource drivers due to patent issues (Or something along those lines). It should work fine in windows using the exact same extension. The problem you are experiencing must be related to something else (since you enabled it in driconf). This restriction in the drivers was not expected. Your card supports the extension just fine; this is not a hardware restriction.
Created attachment 2527 [details] Braid with s3tc textures missing. This is a screenshot of the opening screen of the game without any of the S3TC textures. If the blacked out parts are scrambled-looking on your system, the S3TC support is busted. (In the house, the puzzles on the walls are s3tc along with other things. In the levels, most things are NOT, if they aren't characters/monsters.) --ryan.
> But, still, with a failure rate of 100% in this Bundle for me (Osmos works, but > only because I hacked its included font by hand, as recent FreeTypes reject it > as part of a security fix) I can sort of understand why Linux games haven't > taken off much with the general public. (The previous Bundle had a success rate > of 100% for me.) I'll ping you by private mail, perhaps I can nag some of the other developers for updates on your behalf. --ryan.
Created attachment 2528 [details] Works? Or is there something wrong???? $ braid/braid -windowed i915_program_error: Exceeded max nr indirect texture lookups i915_program_error: Exceeded max nr indirect texture lookups i915_program_error: Exceeded max ALU instructions After ~5 minutes, I got this!
> ...enabling the extension with driconf--but without installing the libtxc_dxtn > package--will tell games that you have support, and then intentionally do the > wrong thing (which explains Attachment #2528 [details]). ...actually, it doesn't. Tim should be a DXT5 texture, too, but he's rendering okay. That might just be a bug in the drivers. --ryan.
> with this coredump, which, again, looks like a bug in the drivers. I'll report > this one upstream if you agree. I agree, that sounds like a driver bug. I should be releasing a build of Braid that doesn't need s3tc soon, which might solve this problem, too. --ryan.