That solved some problems; the linker gave me errors relating to OpenAL, but I am pretty sure that is due to the fact that the OpenAL development libraries on my computer have been corrupted (due to my ignorance while messing around a year back). By deleting the Audio framework from the build targets I bypass all of that, but still remain with a cryptic error in XCode's build script:
/bin/sh -c /Users/lew/Desktop/sfml2/build/xcode/sfml.build/dev_10_6/all.build/Script-4C2639F61219B1B70074EB9F.sh
usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-apvX] source_file target_file
cp [-R [-H | -L | -P]] [-f | -i | -n] [-apvX] source_file ... target_directory
Command /bin/sh failed with exit code 64
(The .sh file just contained the command to copy .framework files to a folder.) Very weird, I think it's probably something uniquely messed up about my computer though, not a general problem. Unfortunately this means I probably won't be able to do any experiments with the code until I get a chance to do a clean OS reinstall.
About your problem: That screenshot looks exactly like what I've seen happen in earlier versions of SFML for OSX in minimal graphical test programs with no calls to either Draw() or Clear(), just Display(). What seems to happen is that the SFML program recieves a junk graphical memory recycled from other programs, and displays that if it isn't overwritten by the program. Since using sf::Image and sf::Sprite gets you a blank screen, something involved in their use probably forces a Clear() on the RenderWindow.
Here is my theory: You can render OpenGL with Window, but the RenderWindow class fails. The main difference between these two seems to be that RenderWindow has a Draw() method. There is probably a problem with something used by Draw(), either a function called or some data that isn't getting properly set by some other system.
Since presumably this is a bug specific to the OSX implementation, maybe somewhere down the chain is failing silently. I'd check to see if there is some point at which a call to the system fails, it signals that error by returning a null pointer rather than a pointer to data, and then the SFML code treats that null as if it were optional data rather than an error signal.
Good luck!
