XScreenSaver 5.15

XScreenSaver 5.15 is out now. Three new hacks this time, Hilbert, CompanionCube, and TronBit!

Looking back, it seems that I haven't written a new screen saver since 2008! (SkyTentacles, and the 3D rewrite of Sonar). But in the last three days, I wrote three new ones. Go figure.

(Well, a bit more than three days because I had a couple of false starts with Hilbert without getting anywhere, but once I turned the corner on that (see what I did there?) it came together pretty quickly.)

Hilbert's performance isn't fantastic at depths above 5 but whattayagonnado. Oddly, it starts grinding even in wireframe mode, and all the pain appears to be on the GL side. You'd think that drawing a couple million line segments wouldn't be that big a deal, here in the future.

I couldn't decide whether the Weighted Companion Cube should do the usual "spinny, wobbly" thing, or the BouncingCow thing, so it can do both. Before you complain, yes, I realize that multiple cubes is non-canon. Think of it as a fever dream.

You can now point your Image Directory at an RSS URL (e.g., Flickr) in the image-manipulating and slideshow hacks.

By mildly-popular demand, the MacOS DMG now also contains interactive stand-alone applications of Apple2 and Phosphor, so you can use them as retrocomputey terminal emulators, just like you can on Linux.

If you use Linux in a Japanese locale, please let me know whether the unlock dialog looks right, and whether you can use non-ASCII characters in your password.

I could also still use some confirmation of the installation instructions on Gnome 3 systems.

I finally bit the bullet and "upgraded" to XCode 4, which was a huge pain in the ass. I still find it largely incomprehensible, especially when it comes to adding or copying targets, but I figured I couldn't put it off forever. The most frustrating part about this is that XCode 4 has apparently gone out of its way to make it impossible to build MacOS 10.4 and/or PPC binaries (which XCode 3.2.6 was still able to do), which means that 10.5 Intel is now required. This bums me out, because I still have a mostly-functional hand-me-down PPC MacBook! It's not even that old, and now it's no longer possible to target software at it after only two OS revs? Madness. I live in dread of the endian-specific bugs that will sneak in now, but then, maybe it doesn't matter any more.

I don't have access to a 10.7 machine (I have the fear) but I'm told the savers work there.

Tags: , , , , ,

42 Responses:

  1. Chris Yeh says:

    From a purely UI perspective, XCode 4.* has been an unmitigated disaster. Harder to find useful things? Check. Harder to adjust build configurations, compilers and target options? Check. Presented with a sea of tabular data that looks a lot like a giant excel spreadsheet? Check. Hidden menus that configure the behavior of giant buttons labeled 'Build' and 'Run' ? Check.

    I spent the last week adjusting things so I never had to look at the UI again.

    It's like a race to the bottom. I used to think that the Microsoft Visual Studio tools were awful.

  2. John Bloom says:

    So, I'll prefix this by saying that "Sys Admin" probably describes me better than "Programmer," but is doing a PPC and/or 10.4 build just a matter of opening the project in Xcode 3.x, hitting build and seeing if any version specific or endian specific bugs have crept in? Or would I be getting myself into something a lot hairer than that?

    Also, congrats on the release.
    Also, also: My mom is a huge fan of the whole xscreensaver package. At this point I don't think she'd go back to Windows simply for lack of xscreensaver.

    -John

    • jwz says:

      Keeping both XCode 3 and XCode 4 installed on the same system is difficult already, and eventually, probably soon, XCode 3 will stop working altogether. Plus, I would drop dead of shock if it turned out that XCode 3 can do anything reasonable with XCode 4 project files, which would mean maintaining two trees.

      • John Bloom says:

        Alright, so hypothetically, let's say I have a Mac OS X 10.6 VM that I'm happy to keep at XCode 3.2.6, a copy of the XScreensaver 5.14 source (for the project files), a copy of XScreensaver 5.15 source (for the ... source) and some kind of perverse desire to compile things for dead platforms. Am I talking hours to get 5.15 building or days/weeks/months?

        • jwz says:

          You said "MacOS VM" so you're already down a rathole so deep you may never see the sun again.

          • John Bloom says:

            Ahaha. It seemed like a good idea at the time. See my first post (sysadmin not programmer). It actually works surprisingly well whenever it's doing things that don't require graphics acceleration. So, while I was down in this rathole anyways, I figured I might as well compile xscreensaver to run on my iMac G5.

          • Edouard says:

            I bought VMWare Fusion, and although I mostly use it for Windows and Linux VMs, it'll run OSX 10.5, 10.6 (well, the server versions) and 10.7. It's at least an option for running old versions of Xcode that should continue to work for years (if the age of Windows VMs I can run is anything to go by).

  3. Otto says:

    Perfectly canon. Companion cubes are sentient of course. They just have a lot of them.

  4. steen says:

    I'm not finding TronBit in the osx dmg, unless you named it something weird. The other new ones are there and looking good though.

    • jwz says:

      Oh, great. See also XCode 4 being a steaming pile of shit.

      Somehow the TronBit target (or product? Are they the same thing? Who can tell?) is not a part of the "All Savers" target (or scheme???) but both Hilbert and CompanionCube are.

      Which means I succeeded in doing it twice, by accident, and can't reproduce it a third time.

      Fuck this piece of shit software sideways.

    • jwz says:

      Ok, I figured it out. Let's see if I can find it again next time. I've updated the dmg.

  5. _Claymore_ says:

    Running 10.7.1, I get crashes from Dali's Clock as well as long hangs from Sonar. I attribute that last part to the arp table you're building or whatever.

    • jwz says:

      Someone else said Dali Clock crashes on 10.7 with a GL error, but I have no idea why. Works fine on 10.6.

      Sonar shouldn't hang unless your DNS is fucked. Can you attach gdb and see what it's doing?

      • Dan says:

        I'm seeing the Dali Clock crash as well. My Mac OS X debugging skills are nearly non-existent, but I'll help out if I can.

        • jwz says:

          On 10.7, I assume?

          Fixing this is probably going to require someone building Dali Clock under XCode and looking at the debugger on 10.7. Or waiting until I get around to upgrading, when that person will be me...

          • Dan says:

            Yes, 10.7. Well, I can give it a try and get back to you. Here's some of the crash log, in case it helps at all.

            Crashed Thread: 0 Dispatch queue: com.apple.main-thread

            Exception Type: EXC_CRASH (SIGABRT)
            Exception Codes: 0x0000000000000000, 0x0000000000000000

            Application Specific Information:
            com.apple.preference.desktopscreeneffect v.4 (Desktop & Screen Saver)
            objc[2021]: garbage collection is ON
            abort() called

            Application Specific Signatures:
            DaliClock

            Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
            0 libsystem_kernel.dylib 0x00007fff920b9ce2 __pthread_kill + 10
            1 libsystem_c.dylib 0x00007fff964197d2 pthread_kill + 95
            2 libsystem_c.dylib 0x00007fff9640aa7a abort + 143
            3 org.jwz.DaliClockSaver 0x00000001153b3a5a check_gl_error + 219
            4 org.jwz.DaliClockSaver 0x00000001153b3d56 -[DaliClockView initWithFrame:ownWindow:] + 726
            5 org.jwz.DaliClockSaver 0x00000001153b1ae8 -[DaliClockSaverView initWithFrame:isPreview:] + 222

        • jwz says:

          From another report, it looks like CGLEnable(cctx,kCGLCEMPEngine) is producing the GL error "invalid framebuffer op" in Dali Clock on 10.7. But, the same call exists in the various other XScreenSaver savers, and those are working fine there, so that's weird.

          • Dan says:

            I'm stumped. I can't even *find* the daliclock code, let alone compile it for debugging. where is that hiding? And the source tar file seems to be missing mismunch.c and m6502.h.

            • jwz says:

              mismunch.c was deleted, it shoudln't be referenced any more. Where do you see it? m6502.h should be generated by running m6502.sh on the *.asm files.

              • Dan says:

                There's a red entry in the project: Hacks/XScreenSaver/mismunch.c

                Thanks for the tip on m6502.h, I didn't realize there were generated files. Heh, I'm building it now, it's the first time I've heard the fan on my Macbook Air come on.

              • Dan says:

                I "modernized" the project and built it for 10.7, and get the same crash. It's at line 348 in DaliClockView.m.

              • Dan says:

                OK, now I really know what's broken...it's really at line 285, the call to glClear. I stepped through and saw the error, and commenting it out makes the crash go away.

    • jwz says:

      Regarding Sonar, try unchecking "Resolve host names" and see if that makes the hangs go away.

  6. Legooolas says:

    Oddly, it starts grinding even in wireframe mode, and all the pain appears to be on the GL side.

    Last time I looked at GL (long, long ago) wireframe was just done by using pairs of really thing triangles, so it's only the number of filled pixels which gets reduced and not the number of triangles (in fact I'm pretty sure there will be more triangles), so it tends not to be any quicker on most cards.

    Some fancypants CAD-enabled drivers for particular cards would do wireframe as actual lines and it would be faster, but most cards didn't IIRC.

    • jwz says:

      Well, the reason they use triangles for lines is that it's actually faster, for RISC-like reasons. "Texture Mapping as a Fundamental Drawing Primitive". But anyway, wireframe should still be faster because in that mode I've also turned off lighting, face culling and the depth buffer... unless these days you get all of those for free, anyway. I dunno. It's weird.

      • ajax says:

        You pretty much do get those for free in the hardware, or at least in hardware that counts as competent by the standards of 2002. Any performance benefit you see from turning them off is going to be a function of eliminating the cost of telling the GPU about them.

        But I suspect that's your performance problem anyway. You're using glVertex (okay, and CallList, but not with big lists), which transforms your complaint into "You'd think that a couple million function calls sixty times a second wouldn't be that big a deal, here in the future." GLES got rid of that API for a reason, it's too slow to be usable for serious work.

        • jwz says:

          Given that the scene is actually different at every frame, the GL 1.x way is: call glVertex a zillion times, which pushes a zillion vertexes down the pipeline to the GPU, non-blocking; then flush and render. Whereas the GLES way would be: malloc an array; fill that array with a zillion vertexes; push that array down the pipeline to the GPU; then flush and render. Unless GL 1.x is being stupid and not coalescing all of that into a single write(), I don't see how this results in any difference.

          Basically, everything I've read about the API changes for GLES seem like they only optimize static scenes. That's great if you're writing a shooter where the walls and commandos never change shape, I guess. I don't think it helps with anything I do.

          • ajax says:

            Let's say I was going to ship you a hundred T-shirts. Would you rather they come in individual soft-pack envelopes, or one box? It really doesn't matter that they're all different sizes and colors each time you get them shipped, one of these is going to be a lot more efficient to unpack.

            Consider the instruction sequence for an impossibly perfect dispatch scenario for glVertex3f: call into libGL, call to context vtable (inside Begin/End or not etc), mov, mov mov, ret, ret. 7 instructions per. If you use DrawElements, each vertex is just the three mov's, and you get to amortize that function call overhead over the entire scene.

            Since they're the tools I'm familiar with: on a Linux machine with an Intel GMA4500 chip (a little faster than a first-gen Mac Book Air), hilbert -delay 0 -3d at depth 5 has the hilbert binary at ~95% CPU usage but only ~16% GPU usage. You're starving the GPU because you're taking too long to describe the geometry. Sure, it's new geometry every time, but tIme you're spending banging through function calls is time you're not spending giving the GPU work to do.

            This is why competent GL implementations do not batch all your Vertex calls up into one big write. While your app is taking its sweet-ass time describing the geometry, that GPU is going idle. Instead we'll build up reasonable-sized batches at a time and submit them as they fill up.

  7. rrp says:

    I just built it with no errors or warnings using Xcode 3.2.6 on OS X 1.6.8. The targets exist for the three new savers, but for some reason Build(make all) ignores them. Selecting and building the targets individually works fine, as do the resulting savers. Apple2.app and Phosphor.app work, though I think I'll stick with Terminal.app. I will note one small regression from 5.13: SaverTester.app, at least as built by me, has the generic App icon, rather than the XScreenSaver icon it had in the past.

  8. I can understand Apple's policy of forced obsolescence on their OS, since it's in their interest to not have to support multiple old versions. I can't understand why they also force it on developers. Making it impossible to develop for 10.7 while also supporting 10.4 is just annoying. It's not like the older compiler/SDK needs any changes to keep targeting the same old OS.

  9. Ben Morrow says:

    Isn't XCode 4 based on clang/llvm rather than gcc? Clang currently has rather poor support for PPC. If so, then, given that Apple switched because recent versions of gcc are GPL3 only, you get to blame RMS. Which is always fun.

    • Adam A. says:

      XCode 4 gives you your choice of 3 different C* compilers - gcc, gcc/llvm, or clang/llvm. Last I checked, gcc/llvm is the default, and a poor default it is too -- XCode 4 doesn't understand how to parse errors from gcc, only from clang. Nice.

  10. chris t says:

    I switched a spare Ubuntu system over to Japanese and compiled xscreensaver with defaults, straight out of the tarball. The unlock dialog looks just the way it does in ASCII. Should I try uncommenting the bits mentioned in that bug? (I haven't even looked to see whether the code's changed.)

    I also changed my password to a Japanese phrase, but I wasn't able to enter it without being able to activate the input method. (The default unlock dialog allows the 'activate input method' keyboard shortcut to work, which rather surprised me.) I have a kana keyboard around here, but I'll need to hunt down a ps/2 -> usb adapter.

    • jwz says:

      Thanks! No, you don't need to change the code, that patch is in the current version. Can you use any non-ASCII characters in your password, e.g., € or £ or something easier to type?

  11. Jeff says:

    Having recently (one month ago) left Linux for the Mac I am only just now beginning to work with Xcode (4.1.something). Is there any particular steaming shit I should beware of, or will I likely be untouched by the steam because I've never known how things used to work?

    • jwz says:

      I just find the whole thing incomprehensible. Your mileage may vary.

      Maybe it's less confusing if your project only builds a single executable.

  12. Lloyd says:

    shouldn't that cube be dropping into some hole and out some other hole?

  13. [...] final straw came because I follow Jamie Zawinski’s blog. When he posted that he created a bouncing Companion Cube screen saver, I had to have it. The laptop could afford to burn resources now, and the lid was always open [...]