The Apple online docs are mostly at the API level, and lacking in the higher-level overview department. I found "Cocoa Programming" by Anguish, Buck, and Yacktman to be pretty useful, because they give a decent birds-eye view of the Cocoa design patterns.
I'm more of a command-line, straight-to-the-win32 API programmer, so if you're used to using MFC or something, there might be a better resource that maps from MFC to Cocoa. I found Cocoa programming to be really fun--Objective C is very easy to pick up, and it's amazing how you can write rich GUI apps with very few lines of code. With Cocoa and CoreAudio I was able to throw together a simple, working multitrack audio recording app pretty quickly with effects and everything, although when GarageBand came out, I abandoned it as being redundant.
I've usually written apps with the Model-View-Controller structure, and kept the Model layer in C++ with a C interface, so that it can be cross-platform. I keep meaning to try writing some sort of Win32 partial subset of Cocoa (sort of an equivalent to mingw32/cygwin) so that I could develop apps for Cocoa and be able to port them to other OSs--there is GnuStep, but I would prefer to be able to build a "pure" Win32 target, even if it meant writing some sort of NIB-to-C translator or some such... although that would break my current system of having all hobby programming be on the Mac and all work programming be on Wintel...;)
The GameCube is far easier to develop games for than the PS2. Like the Xbox, the graphics engine on the GC is accessed through a fairly easy-to-use library (similar to a very stripped-down OpenGL), plus because the hardware itself is less flexible than the nVidia hardware (e.g., no vertex or pixel shaders, fewer texture stages), the API is simpler which makes up for the fact that it's a "new" API instead of something based on an existing PC graphics API. The only gotcha is that it uses the opposite byte-ordering from the other consoles. Unfortunately the third-party market for GameCube is terrible, which is why few people are spending much time targetting it.
Whereas the Xbox and GameCube give you a graphics API to use, to develop for the PS2 (without using RenderWare or other middleware) is basically equivalent to writing your game *and* writing your own version of Direct3D/OpenGL *and* writing your own driver-level code to drive a somewhat screwball (although endearing) architecture and work around some rather glaring limitations in the hardware (e.g., lack of color*color blending, hardware clipping, have to fake out zfail by reversing the entire zbuffer with sprite strips, etc, etc). Testing out a new vertex shader on the Xbox can take five minutes, whereas even with a good set of macros, writing and debugging a new PS2 VU microprogram can take hours if things don't go well.
The only reason that PS2 games look "about" as good as Xbox games is that developers spend much more time working on PS2 technology due to its far greater market share. Also, since content creation (3D models, animation, texture maps, sound music) and QA/approvals/marketing/licensing make up a pretty huge percentage of the cost of developing a title, the extra hours of PS2-specific programmer sweat/pain doesn't act as a huge additional cost in the big picture. However, uncounted scores of programmers who have sacrificed their sanity to coding for the "Emotion Engine" will probably have to be buried in concrete in a few years after the PS3 replaces the PS2 and all their hard-won skills become useless...
While technically a computer can be represented with an a really enormous FSM, to represent a computer with N bits of state (e.g., all the total bits in registers, RAM, hard disk, etc) requires a FSM with O(2^N) states, whereas to model that same system with a bounded-tape TM requires a tape with O(N) cells, so by some sort of vague hand-waving feel-good rational, I thereby claim that a bounded-tape TM is a more meaningful equivalent to a computer. A FSM for the microcontroller in my washing machine might take more states than there are atoms in the known universe, due to that pesky 2^N factor.
It is sort of like saying that Shakespeare is equivalent to a roomful of typing monkeys because you can generate all possible N-page plays in a finite amount of time with a finite number of monkeys.
Perhaps a better analogy would be that you can model the behavior of the planets with epicycles to any degree of precision as long as you add enough epicycles, but it is not a good model of orbits. It's been well over ten years since I've studied this, though, so insert grains of salt as appropriate...
Just making a 90 nanometer version of a 386 will not magically allow it to run at 5 or even 3 GHz--the main reason for all that "cruft" (as you call the extra transistors of a modern CPU compared to a 386) is in fact to allow higher clock speeds. If that wasn't the case, Intel would have just been clocking their older CPUs higher and higher to beat the "Megahertz" race.
The way that modern chips are able to be clocked so high is the use of deeper pipelines and more parallel operations, both of which require vastly more transistors, as well as the branch prediction and other logic to reduce the adverse affects of pipeline stalls. It's not like the individual transistors of a 3 GHz P4 are switching at ten times the speed of the transistors in a 300 MHz P2.
Also note, at 12 MHz, 128 386's could do an amazing 1.5 GHz clocks in total, not counting all the overhead for getting memory to flow between 128 different processors not even designed for dual-processing.
That doesn't make any sense. Developing nations tend to use energy in dirtier and less fuel-efficient ways, yes, but they also use vastly less per capita then we do. Oh, and by the way, they spend a lot of that energy producing crap that we buy. Imagine everyone in India and China owning a car. The cars in the US are pretty clean from an emissions standpoint, but likely generate more CO2 per vehicle than your typical 3rd world vehicle. Leaving the SUVs aside, a high tech 200 hp V6 hauling a 3500 lb sedan doesn't get any better gas mileage than the cheap, light, small-displacement cars common in poorer nations, and so the CO2 emissions will be comparable. (We're talking about greenhouse gases, not smog here) Modern engines are incredibly efficient, but due to cheap gas and the fact that externalities (e.g., pollution) are not accounted for in the cost of operating a car, we just "spent" the technological gain on more power to haul heavier vehicles, plus due to uncontrolled sprawl, lack of public transit, and other changes we're driving more, and due to globalization more of our goods are shipped long distance.
"The real protection against nature is the wealth that arises from free societies"
Protection against nature? the problem isn't "nature", it's the distinctly unnatural effects of dumping billions of tons of extra carbon into the atmosphere.
The deepest irony is that right now in the US we've got a sweet deal, climate-wise, in the status quo, with our temperate climate and fertile breadbaskets. From purest self-interest, we'd be shooting ourselves in the foot if we continue to perturb the system. On a geological time frame most of the time the earth has either been incredibly hot with no ice caps, or frozen in ice ages; our current temperate, interglacial state is the exception, not the rule, and while it won't last forever, we still have a huge vested interest in keeping it that way as long as possible. It's true that we really don't know how the system works, but dumping tons of carbon into the air is equivalent to blindly conducting a major climatological experiment. While it's theoretically possible that we could introduce enough "dimming" from particulate pollution to counterbalance greenhouse effects, the presence of many positive-feedback systems (melting ice sheets releasing stored CO2, forests switching from carbon sinks to carbon sources, etc) make that rather unlikely. It's like saying that the best way to good health is to drink lots of beer, lots of coffee, smoke lots of opium and lots of crystal meth because they'll all cancel each other out, instead of not doing any of them and maybe get out of the house every now and then.
This happened before with CFCs--the scientific community pointed out the harmful effects of CFCs on the ozone layer, the world acted to reduce CFCs, and it appears like we might have acted in time--the ozone holes seem to be shrinking.
Maybe we'll act in time for climate change. Or perhaps invading Iran would be a better use of our time.
I guess we'll soon find out how much of this is the kind of crack-smoking stuff Sony said about the PS2 (remember we'd all be using PS2-powered graphical supercomputer workstations?) and whether any game will be able to achieve even a fraction of the theoretical performance in the first year or two. The scary part is I feel like Sony really *believes* their own hype (not that Microsoft doesn't have the same problem).
I think Sony probably feels vindicated by the success of the Playstation2 and its wacky architecture that, lets face it, is probably contributing to untold man-centuries of additional work than if the xbox or GameCube had won the console wars. Of course since everyone spent all this time learning how to do all the l33t PS2 tricks everybody spits on the Xbox as being for wimps...
While the idea of coding an entire project in little streaming modules that run on a zillion little processors is certainly academically interesting, if we won't be allowed to run our "main logic" code on some kind of CPU with more than 128K of addressable memory, that will be a huge barrier to entry, and could put Sony at a huge disadvantage compared to more conventional consoles. At least with the PS2 you could run most of your code on a fairly normal CPU and just focus on putting the graphics pipeline on the vector units, and maybe a few other things as needed, which is a lot of "bang for the buck", plus it lets you maintain a clean, multi-platform structure.
Well, here's hoping that at least the APUs will have such "frivolous" features such as integer multiply and hopefully a C compiler... also, if the guys who wrote the rather bloated IOP "operating system" code are involved with this project, that could be nasty... at least with the PS2 you could go straight to the metal and not have to care too much that nobody at SCEI seems to know how to write proper code...
I didn't think that was just a rumor--I thought the story was that some Israeli branch of Intel developed the Pentium-M based on the Pentium III architecture (which was much more efficient clock-per-clock than the P4, which was designed more for marketing-driven clock speed), and now Intel is seeing the error of its ways and giving up on the super-clocked, super-long-pipeline approach and ditching the P4 architecture and adopting AMDs non-GHz-based numbering schemes as well as, umm, their 64-bit instruction set. Oops.
A modern conventional computer is a finite state automata.
A modern computer has equivalent power to a bounded-tape Turing machine. Anyways, a "true" Turing machine can't actually use an infinite amount of tape without taking an infinite amount of time to do so, so the difference is fairly academic.
In some sense you could argue that a computer is a FSA, but that's not really a meaningful analogy--that would be like modeling planetary orbits with a billion epicycles. A FSA for a computer with only 64KB of memory will have 256^65536 states (well, plus a few more for the CPU registers)! I don't know exactly how big that number is, but it's definitely more than the number the particles in the known universe. With one state for each possible configuration of every bit in the system, that's not unlike trying to recreate Shakespeare by printing all possible combinations of letters and spaces.
...far, far, into the distant future, Haley Joel Osmond is saying to himself at the bottom of the ocean:
To be or not to be, aaaaaaaaaaaaaaaaaaaaaaaa.
To be or not to be, aaaaaaaaaaaaaaaaaaaaaaab.
To be or not to be, aaaaaaaaaaaaaaaaaaaaaaac.
To be or not to be, aaaaaaaaaaaaaaaaaaaaaaad.
Caveat to the original poster--I know nothing about your Dell LCD display, and haven't looked at your video...
Back in the DirectX 7 era, there were a number of video drivers that would use huge pushbuffers/command buffers so that you could actually have 10 or more frames worth of rendering scenes queued up before they would make it to the screen. (It's one of those naughty driver tricks that helps certain benchmark scores at the expense of actual users). It often was the case that as long as you locked the frame buffer once per frame (as older games did to display UI/overlays) it would force it to actually display in real time, but if you stopped doing that (which was what you were supposed to do for max performance) you could get as much as three seconds behind on some systems!
Anyways, I thought that those problems were behind us, although I haven't been all that up on PC video driver stuff for a few years... However, as the parent to this post says, if the problem was due to the actual LCD response time, it wouldn't look like latency, but instead more like ghosting/smearing. I'd definitely try it on another PC first before blaming the monitor...
Since combustion of one unit of gasoline requires more than ten units of air (containing oxygen), most car engines are limited by how much air they can get into the cylinders--it's fairly easy to just squirt more fuel, but to get more air in you have to either force it in with a turbocharger or a supercharger or reduce sources of friction on the way in (lower-restriction air intakes, etc) or fool with cam timing. Nitrous oxide is a cheap and easy way of adding more oxygen for a short period of time, plus it has the added benefit of helping to cool the cylinders, preventing "knocking" (premature ignition of the fuel by "hot spots" in the engine == $$$ if left unchecked).
Usually nitrous oxide systems are set up to inject extra fuel along with the nitrous oxide to keep the correct fuel/oxygen ratio.
As an aside, F&F fans should realize that NOS (Nawz) is the logo of Nitrous Oxide Systems, not a chemical abreviation for nitrious oxide, although they spend a lot of money trying to get their name associated with it.
"This essay reads like one of a hundred handouts I received in Intro to Lit classes. It makes the argument that you must make an argument, that there is structure to any argument, and that there is a historical tradition behind how an essay is constructed."
Perhaps I am smoking something, but I thought Graham's whole point was that "real" essays shouldn't be a structured argument, but rather an edited version of a meandering stream of consciousness that leads to surprises for both the author and the reader.
I agree, though, that there might be some crossover between writing software and writing essays, because when programming for all but the smallest of projects, it is probably at least as important that another human can read and understand the code as it is that the compiler can turn it into a (mostly) correct program. The skill that allows a good programmer to find a concise, elegant, and clear solution to a problem may be similar to that of a gifted essayist who can express an idea clearly and succinctly instead of blathering on with self-indulgent witticisms.
Most cellphones seem to modify their output based on how good the reception is (probably mainly to save battery life), which is why phones will run down faster if you're out in the middle of nowhere, and the phone has to "shout" to talk to a tower.
So presumably the presence of a pico-cell will reduce the RF output of the phones to a fair degree, and probably also prevent them from screwing up the ground stations as they are overflown.
One potential problem is that airline cabins are LOUD--most people adapt and don't realize this, but it will probably be hard to hear and people will probably compensate by shouting into the phones. I suppose the airlines will find a way to have over-the-top roaming charges which might reduce in-flight use a little bit, and there's always text messaging.
They're hung up on the "one drive failure" because RAID 0 increases the chance of failure. Let's say each hard drive has a 1 percent chance of failing in a given time period. If you have a two-drive RAID 0 array, then the probability of either drive failing in this period is about 2 percent, or twice as likely. (P = 1 - (1 -.01)^2)
For a four-drive RAID 0 array, this becomes a nearly 4 percent chance of failure.
To be honest, for a two-disk array, this is not a huge difference in reliability, and may well be comparable to the variance in reliability among different hard drives--to go from making infrequent backups to making daily backups over this difference would be fairly irrational--if you value your data enough to switch to daily backups under RAID 0, you should either have already be making near-daily backups (or using a redundant RAID scheme).
Don't tell anybody, but this must actually break the iTunes DRM good and hard. CrossOverOffice almost certainly uses a standard Linux sound driver to get the sound data to the sound chip. This is bound to mean/dev/dsp, which is "hackable" in the sense that anyone with root access can snarf the digital audio data between when it gets decrypted by iTunes and when it gets sent to the sound chip. You can then make unlimited unencumbered copies. Additionally, knowing that the file was uncompressed from lossy AAC compression, it should be possible to recompress it in such a way as exactly to recover the original compressed file, just sans DRM encumbrance.
This is just the same as burning songs from iTMS in iTunes onto a CD, ripping them, and then recompressing (or not), which is allowed behavior on a normal iTunes installation. Or using a digital sound card (you can get an Edirol UA-1D USB for $40) and a S/PDIF loopback cable. Or writing a fake soundcard driver under Windows or OS X (believe it or not, but Linux is not the only OS with documented device driver protocols!).
The problem is the signal is already decompressed by the time it gets to the sound card driver. "Breaking iTunes' DRM" means getting access to the unencrypted compressed sound data. There is no known way to recover the AAC compressed source from the decompressed version--to preserve the same sound quality as the original iTMS file you have to recompress lossless (which creates a much larger file)--if you just recompress as AAC or MP3 you will lose quality from the roundtrip, although presumably this is fine for some. Basically, iTMS DRM is supposed to guarantee that you cannot create a unencumbered small file of the same quality from your downloaded songs, plus put a convenience barrier to discourage casual file swapping.
I own an iPod, a fairly small (Canon S200) digital camera, and a cell phone. However, 99% of the time the cellphone is in my pocket and the other devices are in my house or in my car. Also, I'm usually too protective of the camera and iPod to want them rattling around in my pocket (yes, having a case/holder would help!), plus traveling means carrying two more chargers along with me (can't they at least agree on a common, chainable charging system?).
I actually use the primitive calender feature on the phone because it's the one way I can be sure of remembering to go to the dentist at 4 PM or whatever. Basically there are people who carry backpack or something around all the time and those who don't. For those who don't, it's the choice between crappy cellphone camera or no camera at all.
Obviously the battery problem will prevent good convergence devices for quite some time, but even my Nokia phone could be improved quite a bit if the software were better written.
I would personally love to see Apple enter the cellphone market--in spite of any "do one thing well" issues (clearly an iMac does many things well), Apple is one of the few companies that is actually good at both hardware and software, especially user interface design. I bet given a phone design with a decent-sized touchscreen they could implement an elegent multifunction device.
Mobile phone use is about the same in America as it is in Europe. The difference is mostly that people in Europe (I've heard) and in Asia (I've seen firsthand) often use their phones primarily for text messaging. Here in the US, most don't. I'm not sure why, my guess is that we're just too lazy to learn how to type on the telephone pad.:)
I've been curious about that myself. My one thought is the large disparity in the use of public transit between the US and the rest of the world--clicking on your phone while on a subway makes more sense than doing it in rush-hour traffic. The other possibility could be a difference in social norms. In the US, while many people are irritated by people yammering on their cellphones in public spaces (usually at high volume, and the content is either completely inane: "Hi, it's me. I'm in the supermarket," or excessively personal: "So my doctor says I have crabs..."), it's not actually considered socially unacceptable behavior. I feel like I've seen equal if not more cellphone yammering when I've been to Europe, though, so who knows... or perhaps fewer Europeans have access to IM clients from their workspace and use text messaging as a substitute?
Why doesn't someone who actually lives there chime in instead of me pulling unsubstantiated hypotheses out of my behind...
EA acquiring Criterion is something I've been worrying about for a long time. I was kind of expecting someone like Sony to jump in at the last minute to try and prevent it, but oh well. Maybe this means Sony actually hopes to ship the PS3 with usable graphics libraries...
While Renderware is certainly the most popular console middleware provider by far, a minority of games actually use Renderware, so it might be hard to bring antitrust charges--Renderware certainly has far less of a monopoly than Sony does on the console market.
Anyways, I agree that EA probably doesn't give a rat's ass about the licensing revenues. My guess is they would be more likely to just stop licensing Renderware for future 3rd-party games than deliberately set mines in it. A precedent for this is when EA bought BlackBox, they made BlackBox stop licensing its cross-platform video codec to other developers.
It's quite likely that EA acquired Criterion as a somewhat defensive strategy--if they are intending to try and migrate their various studios to Renderware (which would ease the sharing of technology, assets, and employees between their studios), then by *not* acquiring Criterion they would be left quite vulnerable if Sony, Microsoft, or someone else acquired it.
Deciding to go with a particular middleware provider is a huge commitment even for a smaller studio--all of your code and tools are built around it, making it very expensive to switch. When you're EA and thinking of switching all or some of your studios to Renderware, it's an even bigger leap. EA will have to walk a fine line--if they start abusing their position, people will drop Renderware and a competing middleware provider will fill the vacuum, but if they "play nice", people will continue to use it at least for the next several years giving EA a nice leash on other developers, and possibly a slice of GTA[n] profits...
As the Playstation3 looms on the horizon, we may be entering an era where in-house graphics engines won't be able to compete with a dedicated large team who does nothing but develop and refine their engine. If Renderware had remained independent and was able to offer a good early PS3 implementation, it could have been a huge switchover; currently, it would be quite risky for anyone to switch to Renderware.
This also brings up the vulnerability of all middleware being acquired by someone like EA. Amusingly, the only way for a middleware company to guarantee the future would be to do something like GPL at least the API and specification of their middleware system, so that at least it would be possible for another provider to provide a compatible system in the event of a hijacking (although this would remove the "lock-in" advantage). A more exciting alternative would be if various smaller developers pooled resources and worked on some sort of open-sourced engine--as hardware power increases, graphics engines will continue to get more general-purpose and less game-specific, and the graphics engine itself will become less of a differentiating feature in the marketplace. Trying to make an GPL-like license that would be compatible with all the Sony/Microsoft/Nintendo SDK licensing might be tricky, but surely it's possible. The proliferation of open standards for games technology would also facilitate moving to a Hollywood studio business model for game developement, where developers are hired on a per-project basis, and standard toolsets make it easier for artists and to a lesser degree programmers to jump from project to project, making it easier to have the "small team in preproduction, huge team in production, small team in final testing/approval" structure.
While I'm a not an OSS developer, I definitely find that as a software engineer I am as interested in interface usability as I am in software architecture. I think there is quite a bit of overlap there, because the design of a programs structure and internal APIs is another form of designing a system to be usable, although by other developers (or yourself, if you work at multiple levels within your projects as I do).
Making a subsystem robust, flexible, and easy to use is a very similar challenge to making a good user interface. Both are hard but not unsolveable problems--you just have to spend some time thinking before you rush to start coding.
While it's not good to design the UI last, it is possible to design applications with a hard wall between the "guts" of the application engine and the GUI--besides being a good software design principle, this allows multiple GUIs to be created, and would make it easier for people like you to contribute to OSS projects.
Another point that has been already made but needs reinforcing--artists are not designers! (and most "web designers" are not designers either) The GUIs at work that I've seen that were dominated by an artist are often worse than the programmer-designed ones--lots of pretty borders that take up valuable screen real estate, hand-built art bits to make every screen different from every other one in slight ways, button schemes that only work with four-letter text labels, etc, etc.
Anyways, if you want to perservere, and you have access to a Mac (as I think you might if you're an architect), is to install the developer tools that come with OS X (called Xcode in the current version). There is a tool called "Interface Builder" that lets you design user interfaces by dragging buttons around and making connections, that can actually form GUI prototypes that can even have limited functionality. If you made an awesome looking "dummy" application and put it up somewhere along with a well-thought out control flow diagram or other document, I bet some programmer might say "hey, that would be really cool if it worked" and add the neccesary code. Hell, I probably would!;)
My feeling is that it probably won't be too hard to integrate (I haven't looked at the API yet), but the main difference is that Spotlight is a feature that regular people will use and probably start to expect, whereas AppleScript was really only for a smaller group of "power users". Perceived utility is often a stronger factor for developers when selecting features than ease of implementation (unless they're wimps!;)
Also, for applications that just use files, Spotlight will still be able to find these documents based on filename and other metadata. For my personal use, I predict that I will use Spotlight all the time for searching files, contacts, e-mails, and maybe songs/photos (which will all be supported since I just use the Apple applications for these tasks), and so whether or not 3rd-party apps support it will not be a big factor to me.
I don't know much about Automator, their new GUI-based batch system, but I'm guessing that it will be much more widely-used than AppleScript. You'd think there would be a way to write shims to let Automator talk to apps that have AppleScript bindings and leverage that capability for more users.
My understanding is that there is an area in the back of the brain where there is a fairly straightforward map of the retina. (E.g., they are able to stimulate points in this area with electrodes and get patients to see dots at desired locations in the visual field.)
This would imply that the optic nerve really is a bunch of wires connecting rods and cones to the brain. After this point, there are various edge-detectors and other fairly simple image-processing operations (the usual low-mhz, massively parallel wetware). So I think a low-res, black-and-white "artificial eye" is definitely within the realm of the possible, especially for someone who had working vision during the early developmental stages--you'd just have to implant a grid of electrodes connected to a video-in jack on the skull. I'm guessing the main trick would be to get something that wouldn't be rejected or damage the nerves.
Wouldn't the centripetal acceleration be a factor at the end of the launch? My numbers or math might be wrong, but I work it out to be:
A = V^2/R = (30,000 m/s)^2/ (1,700,000 m) = 530 m/s^2 = 53g
I suppose you could construct your accelerator in a spiral shape to make the final section as straight as possible, but that would involve either a pretty crazy support structure or some big excavation...
Another possibility would be to make a tiny capsule for just the people, and accelerate that to a smaller velocity using a shorter accelerator. Sling a series of rocket fuel tanks out at higher and higher speeds, so that the capsule can dock with each tank, use it to accelerate, and then meet the next one. Presumably the fuel tanks could use a short accelerator with very high acceleration.
The only real use that the article mentioned was subway commuters watching last night's game, which obviously only appeals to the small fraction of the US that uses public transit (although of course numbers are far higher in Europe and Asia).
A different use that occurs to me is the portable video players are a pretty good match for the little video clips you can shoot with most digital cameras. I've noticed already that when you have your camera with you with some videos on it, you always end up passing it around--"hey look at this guy wiping out on his snowboard" or whatever. I could imagine a portable video player with a big hard drive could facilitate swapping little video clips (which are better to watch on a tiny screen than a two hour feature film) especially if they could dock directly to each other and to cameras.
It could still be a solution in search of a problem, though. However, I'd be curious to see what Apple would do with a video iPod project, especially if it were well integrated into iMovie and iTunes--probably they'd need to either add video to iTunes (and iTMS?) or add an iTunes-like library with autosync to iMovie. Since only iTunes is available in Windows, and iTunes already uses QuickTime for playback chores, I would imagine they would go for the former, and leave iMovie as a Mac-only content creation tool.
Just to add to your list, both graphics and physics engines require linear algebra. Writing either one of these things without a completely intuitive grasp of vectors and matrices will be very challenging. Furthermore, physics engines typically use numerical integration, so the closed-form techniques that make up the bulk of calculus aren't really applicable, and for multibody stuff you'll probably need ODEs/PDEs and the ability to wade through some pretty hairy equations. Most of the good literature relevant to realtime physics engines comes from either the mechanical engineering world or the robotics foks, so hitting the books pretty hard will be required anyways if you just have an undergraduate CS degree.
One thing that was really helpful to me in college was to work as a tutor in the math center--it's one thing to pass some calculus classes, even doing fairly well, but the experience of having to repeatedly explain the concepts got me to get a much more solid grasp of the stuff I had just quickly learned for a test and then forgotten. I nearly got a double major in math, but didn't feel like taking three upper level math courses plus an extra senior thesis project my last year, but in actuality, experience gained from being a tutor helps me far more in my current work than if i had gotten the dual major and taken some more esoteric math classes.
Slashdot Mirror
I'm more of a command-line, straight-to-the-win32 API programmer, so if you're used to using MFC or something, there might be a better resource that maps from MFC to Cocoa. I found Cocoa programming to be really fun--Objective C is very easy to pick up, and it's amazing how you can write rich GUI apps with very few lines of code. With Cocoa and CoreAudio I was able to throw together a simple, working multitrack audio recording app pretty quickly with effects and everything, although when GarageBand came out, I abandoned it as being redundant.
I've usually written apps with the Model-View-Controller structure, and kept the Model layer in C++ with a C interface, so that it can be cross-platform. I keep meaning to try writing some sort of Win32 partial subset of Cocoa (sort of an equivalent to mingw32/cygwin) so that I could develop apps for Cocoa and be able to port them to other OSs--there is GnuStep, but I would prefer to be able to build a "pure" Win32 target, even if it meant writing some sort of NIB-to-C translator or some such... although that would break my current system of having all hobby programming be on the Mac and all work programming be on Wintel...
Whereas the Xbox and GameCube give you a graphics API to use, to develop for the PS2 (without using RenderWare or other middleware) is basically equivalent to writing your game *and* writing your own version of Direct3D/OpenGL *and* writing your own driver-level code to drive a somewhat screwball (although endearing) architecture and work around some rather glaring limitations in the hardware (e.g., lack of color*color blending, hardware clipping, have to fake out zfail by reversing the entire zbuffer with sprite strips, etc, etc). Testing out a new vertex shader on the Xbox can take five minutes, whereas even with a good set of macros, writing and debugging a new PS2 VU microprogram can take hours if things don't go well.
The only reason that PS2 games look "about" as good as Xbox games is that developers spend much more time working on PS2 technology due to its far greater market share. Also, since content creation (3D models, animation, texture maps, sound music) and QA/approvals/marketing/licensing make up a pretty huge percentage of the cost of developing a title, the extra hours of PS2-specific programmer sweat/pain doesn't act as a huge additional cost in the big picture. However, uncounted scores of programmers who have sacrificed their sanity to coding for the "Emotion Engine" will probably have to be buried in concrete in a few years after the PS3 replaces the PS2 and all their hard-won skills become useless...
It is sort of like saying that Shakespeare is equivalent to a roomful of typing monkeys because you can generate all possible N-page plays in a finite amount of time with a finite number of monkeys.
Perhaps a better analogy would be that you can model the behavior of the planets with epicycles to any degree of precision as long as you add enough epicycles, but it is not a good model of orbits. It's been well over ten years since I've studied this, though, so insert grains of salt as appropriate...
The way that modern chips are able to be clocked so high is the use of deeper pipelines and more parallel operations, both of which require vastly more transistors, as well as the branch prediction and other logic to reduce the adverse affects of pipeline stalls. It's not like the individual transistors of a 3 GHz P4 are switching at ten times the speed of the transistors in a 300 MHz P2.
Also note, at 12 MHz, 128 386's could do an amazing 1.5 GHz clocks in total, not counting all the overhead for getting memory to flow between 128 different processors not even designed for dual-processing.
"The real protection against nature is the wealth that arises from free societies"
Protection against nature? the problem isn't "nature", it's the distinctly unnatural effects of dumping billions of tons of extra carbon into the atmosphere.
The deepest irony is that right now in the US we've got a sweet deal, climate-wise, in the status quo, with our temperate climate and fertile breadbaskets. From purest self-interest, we'd be shooting ourselves in the foot if we continue to perturb the system. On a geological time frame most of the time the earth has either been incredibly hot with no ice caps, or frozen in ice ages; our current temperate, interglacial state is the exception, not the rule, and while it won't last forever, we still have a huge vested interest in keeping it that way as long as possible. It's true that we really don't know how the system works, but dumping tons of carbon into the air is equivalent to blindly conducting a major climatological experiment. While it's theoretically possible that we could introduce enough "dimming" from particulate pollution to counterbalance greenhouse effects, the presence of many positive-feedback systems (melting ice sheets releasing stored CO2, forests switching from carbon sinks to carbon sources, etc) make that rather unlikely. It's like saying that the best way to good health is to drink lots of beer, lots of coffee, smoke lots of opium and lots of crystal meth because they'll all cancel each other out, instead of not doing any of them and maybe get out of the house every now and then.
This happened before with CFCs--the scientific community pointed out the harmful effects of CFCs on the ozone layer, the world acted to reduce CFCs, and it appears like we might have acted in time--the ozone holes seem to be shrinking.
Maybe we'll act in time for climate change. Or perhaps invading Iran would be a better use of our time.
I think Sony probably feels vindicated by the success of the Playstation2 and its wacky architecture that, lets face it, is probably contributing to untold man-centuries of additional work than if the xbox or GameCube had won the console wars. Of course since everyone spent all this time learning how to do all the l33t PS2 tricks everybody spits on the Xbox as being for wimps...
While the idea of coding an entire project in little streaming modules that run on a zillion little processors is certainly academically interesting, if we won't be allowed to run our "main logic" code on some kind of CPU with more than 128K of addressable memory, that will be a huge barrier to entry, and could put Sony at a huge disadvantage compared to more conventional consoles. At least with the PS2 you could run most of your code on a fairly normal CPU and just focus on putting the graphics pipeline on the vector units, and maybe a few other things as needed, which is a lot of "bang for the buck", plus it lets you maintain a clean, multi-platform structure.
Well, here's hoping that at least the APUs will have such "frivolous" features such as integer multiply and hopefully a C compiler... also, if the guys who wrote the rather bloated IOP "operating system" code are involved with this project, that could be nasty... at least with the PS2 you could go straight to the metal and not have to care too much that nobody at SCEI seems to know how to write proper code...
I didn't think that was just a rumor--I thought the story was that some Israeli branch of Intel developed the Pentium-M based on the Pentium III architecture (which was much more efficient clock-per-clock than the P4, which was designed more for marketing-driven clock speed), and now Intel is seeing the error of its ways and giving up on the super-clocked, super-long-pipeline approach and ditching the P4 architecture and adopting AMDs non-GHz-based numbering schemes as well as, umm, their 64-bit instruction set. Oops.
In some sense you could argue that a computer is a FSA, but that's not really a meaningful analogy--that would be like modeling planetary orbits with a billion epicycles. A FSA for a computer with only 64KB of memory will have 256^65536 states (well, plus a few more for the CPU registers)! I don't know exactly how big that number is, but it's definitely more than the number the particles in the known universe. With one state for each possible configuration of every bit in the system, that's not unlike trying to recreate Shakespeare by printing all possible combinations of letters and spaces.
To be or not to be, aaaaaaaaaaaaaaaaaaaaaaaa.
To be or not to be, aaaaaaaaaaaaaaaaaaaaaaab.
To be or not to be, aaaaaaaaaaaaaaaaaaaaaaac.
To be or not to be, aaaaaaaaaaaaaaaaaaaaaaad.
Caveat to the original poster--I know nothing about your Dell LCD display, and haven't looked at your video...
Back in the DirectX 7 era, there were a number of video drivers that would use huge pushbuffers/command buffers so that you could actually have 10 or more frames worth of rendering scenes queued up before they would make it to the screen. (It's one of those naughty driver tricks that helps certain benchmark scores at the expense of actual users). It often was the case that as long as you locked the frame buffer once per frame (as older games did to display UI/overlays) it would force it to actually display in real time, but if you stopped doing that (which was what you were supposed to do for max performance) you could get as much as three seconds behind on some systems!
Anyways, I thought that those problems were behind us, although I haven't been all that up on PC video driver stuff for a few years... However, as the parent to this post says, if the problem was due to the actual LCD response time, it wouldn't look like latency, but instead more like ghosting/smearing. I'd definitely try it on another PC first before blaming the monitor...
Usually nitrous oxide systems are set up to inject extra fuel along with the nitrous oxide to keep the correct fuel/oxygen ratio.
As an aside, F&F fans should realize that NOS (Nawz) is the logo of Nitrous Oxide Systems, not a chemical abreviation for nitrious oxide, although they spend a lot of money trying to get their name associated with it.
I agree, though, that there might be some crossover between writing software and writing essays, because when programming for all but the smallest of projects, it is probably at least as important that another human can read and understand the code as it is that the compiler can turn it into a (mostly) correct program. The skill that allows a good programmer to find a concise, elegant, and clear solution to a problem may be similar to that of a gifted essayist who can express an idea clearly and succinctly instead of blathering on with self-indulgent witticisms.
IANAELDH (I am not an English lit. degree-holder)
So presumably the presence of a pico-cell will reduce the RF output of the phones to a fair degree, and probably also prevent them from screwing up the ground stations as they are overflown.
One potential problem is that airline cabins are LOUD--most people adapt and don't realize this, but it will probably be hard to hear and people will probably compensate by shouting into the phones. I suppose the airlines will find a way to have over-the-top roaming charges which might reduce in-flight use a little bit, and there's always text messaging.
To be honest, for a two-disk array, this is not a huge difference in reliability, and may well be comparable to the variance in reliability among different hard drives--to go from making infrequent backups to making daily backups over this difference would be fairly irrational--if you value your data enough to switch to daily backups under RAID 0, you should either have already be making near-daily backups (or using a redundant RAID scheme).
The problem is the signal is already decompressed by the time it gets to the sound card driver. "Breaking iTunes' DRM" means getting access to the unencrypted compressed sound data. There is no known way to recover the AAC compressed source from the decompressed version--to preserve the same sound quality as the original iTMS file you have to recompress lossless (which creates a much larger file)--if you just recompress as AAC or MP3 you will lose quality from the roundtrip, although presumably this is fine for some. Basically, iTMS DRM is supposed to guarantee that you cannot create a unencumbered small file of the same quality from your downloaded songs, plus put a convenience barrier to discourage casual file swapping.
I actually use the primitive calender feature on the phone because it's the one way I can be sure of remembering to go to the dentist at 4 PM or whatever. Basically there are people who carry backpack or something around all the time and those who don't. For those who don't, it's the choice between crappy cellphone camera or no camera at all.
Obviously the battery problem will prevent good convergence devices for quite some time, but even my Nokia phone could be improved quite a bit if the software were better written.
I would personally love to see Apple enter the cellphone market--in spite of any "do one thing well" issues (clearly an iMac does many things well), Apple is one of the few companies that is actually good at both hardware and software, especially user interface design. I bet given a phone design with a decent-sized touchscreen they could implement an elegent multifunction device.
Why doesn't someone who actually lives there chime in instead of me pulling unsubstantiated hypotheses out of my behind...
While Renderware is certainly the most popular console middleware provider by far, a minority of games actually use Renderware, so it might be hard to bring antitrust charges--Renderware certainly has far less of a monopoly than Sony does on the console market.
Anyways, I agree that EA probably doesn't give a rat's ass about the licensing revenues. My guess is they would be more likely to just stop licensing Renderware for future 3rd-party games than deliberately set mines in it. A precedent for this is when EA bought BlackBox, they made BlackBox stop licensing its cross-platform video codec to other developers.
It's quite likely that EA acquired Criterion as a somewhat defensive strategy--if they are intending to try and migrate their various studios to Renderware (which would ease the sharing of technology, assets, and employees between their studios), then by *not* acquiring Criterion they would be left quite vulnerable if Sony, Microsoft, or someone else acquired it.
Deciding to go with a particular middleware provider is a huge commitment even for a smaller studio--all of your code and tools are built around it, making it very expensive to switch. When you're EA and thinking of switching all or some of your studios to Renderware, it's an even bigger leap. EA will have to walk a fine line--if they start abusing their position, people will drop Renderware and a competing middleware provider will fill the vacuum, but if they "play nice", people will continue to use it at least for the next several years giving EA a nice leash on other developers, and possibly a slice of GTA[n] profits...
As the Playstation3 looms on the horizon, we may be entering an era where in-house graphics engines won't be able to compete with a dedicated large team who does nothing but develop and refine their engine. If Renderware had remained independent and was able to offer a good early PS3 implementation, it could have been a huge switchover; currently, it would be quite risky for anyone to switch to Renderware.
This also brings up the vulnerability of all middleware being acquired by someone like EA. Amusingly, the only way for a middleware company to guarantee the future would be to do something like GPL at least the API and specification of their middleware system, so that at least it would be possible for another provider to provide a compatible system in the event of a hijacking (although this would remove the "lock-in" advantage). A more exciting alternative would be if various smaller developers pooled resources and worked on some sort of open-sourced engine--as hardware power increases, graphics engines will continue to get more general-purpose and less game-specific, and the graphics engine itself will become less of a differentiating feature in the marketplace. Trying to make an GPL-like license that would be compatible with all the Sony/Microsoft/Nintendo SDK licensing might be tricky, but surely it's possible. The proliferation of open standards for games technology would also facilitate moving to a Hollywood studio business model for game developement, where developers are hired on a per-project basis, and standard toolsets make it easier for artists and to a lesser degree programmers to jump from project to project, making it easier to have the "small team in preproduction, huge team in production, small team in final testing/approval" structure.
Making a subsystem robust, flexible, and easy to use is a very similar challenge to making a good user interface. Both are hard but not unsolveable problems--you just have to spend some time thinking before you rush to start coding.
While it's not good to design the UI last, it is possible to design applications with a hard wall between the "guts" of the application engine and the GUI--besides being a good software design principle, this allows multiple GUIs to be created, and would make it easier for people like you to contribute to OSS projects.
Another point that has been already made but needs reinforcing--artists are not designers! (and most "web designers" are not designers either) The GUIs at work that I've seen that were dominated by an artist are often worse than the programmer-designed ones--lots of pretty borders that take up valuable screen real estate, hand-built art bits to make every screen different from every other one in slight ways, button schemes that only work with four-letter text labels, etc, etc.
Anyways, if you want to perservere, and you have access to a Mac (as I think you might if you're an architect), is to install the developer tools that come with OS X (called Xcode in the current version). There is a tool called "Interface Builder" that lets you design user interfaces by dragging buttons around and making connections, that can actually form GUI prototypes that can even have limited functionality. If you made an awesome looking "dummy" application and put it up somewhere along with a well-thought out control flow diagram or other document, I bet some programmer might say "hey, that would be really cool if it worked" and add the neccesary code. Hell, I probably would! ;)
Also, for applications that just use files, Spotlight will still be able to find these documents based on filename and other metadata. For my personal use, I predict that I will use Spotlight all the time for searching files, contacts, e-mails, and maybe songs/photos (which will all be supported since I just use the Apple applications for these tasks), and so whether or not 3rd-party apps support it will not be a big factor to me.
I don't know much about Automator, their new GUI-based batch system, but I'm guessing that it will be much more widely-used than AppleScript. You'd think there would be a way to write shims to let Automator talk to apps that have AppleScript bindings and leverage that capability for more users.
This would imply that the optic nerve really is a bunch of wires connecting rods and cones to the brain. After this point, there are various edge-detectors and other fairly simple image-processing operations (the usual low-mhz, massively parallel wetware). So I think a low-res, black-and-white "artificial eye" is definitely within the realm of the possible, especially for someone who had working vision during the early developmental stages--you'd just have to implant a grid of electrodes connected to a video-in jack on the skull. I'm guessing the main trick would be to get something that wouldn't be rejected or damage the nerves.
Another possibility would be to make a tiny capsule for just the people, and accelerate that to a smaller velocity using a shorter accelerator. Sling a series of rocket fuel tanks out at higher and higher speeds, so that the capsule can dock with each tank, use it to accelerate, and then meet the next one. Presumably the fuel tanks could use a short accelerator with very high acceleration.
A different use that occurs to me is the portable video players are a pretty good match for the little video clips you can shoot with most digital cameras. I've noticed already that when you have your camera with you with some videos on it, you always end up passing it around--"hey look at this guy wiping out on his snowboard" or whatever. I could imagine a portable video player with a big hard drive could facilitate swapping little video clips (which are better to watch on a tiny screen than a two hour feature film) especially if they could dock directly to each other and to cameras.
It could still be a solution in search of a problem, though. However, I'd be curious to see what Apple would do with a video iPod project, especially if it were well integrated into iMovie and iTunes--probably they'd need to either add video to iTunes (and iTMS?) or add an iTunes-like library with autosync to iMovie. Since only iTunes is available in Windows, and iTunes already uses QuickTime for playback chores, I would imagine they would go for the former, and leave iMovie as a Mac-only content creation tool.
Physics engines - Calculus, trig
Just to add to your list, both graphics and physics engines require linear algebra. Writing either one of these things without a completely intuitive grasp of vectors and matrices will be very challenging. Furthermore, physics engines typically use numerical integration, so the closed-form techniques that make up the bulk of calculus aren't really applicable, and for multibody stuff you'll probably need ODEs/PDEs and the ability to wade through some pretty hairy equations. Most of the good literature relevant to realtime physics engines comes from either the mechanical engineering world or the robotics foks, so hitting the books pretty hard will be required anyways if you just have an undergraduate CS degree.
One thing that was really helpful to me in college was to work as a tutor in the math center--it's one thing to pass some calculus classes, even doing fairly well, but the experience of having to repeatedly explain the concepts got me to get a much more solid grasp of the stuff I had just quickly learned for a test and then forgotten. I nearly got a double major in math, but didn't feel like taking three upper level math courses plus an extra senior thesis project my last year, but in actuality, experience gained from being a tutor helps me far more in my current work than if i had gotten the dual major and taken some more esoteric math classes.