The framerate won't be half - you wrap the entire left eye rendering inside a GL display list and use the cache to render the right eye. In practice the framerate doesn't drop all that much.
That only is a meaningful optimization if the limiting factor of the game is how long it takes the CPU to fill out the display list (a function of CPU speed and how well the developer has batched up their API calls), not how long the GPU takes to render it (a function mostly of vertex throughput and fill-rate). If the game is GPU-bound, your framerate would drop nearly in half.
Not to mention that while the IA32/x86 architecture is sneered at by architecture snobs, there are benefits from the CISC-to-micro-ops layer in that the machine code is much more compact than RISC code, and so can reduce memory bandwidth requirements for instruction fetch and make more efficient use of instruction cache. (Basically the CISC instruction set ends up acting like a data-compression layer on the instruction stream)
I have to admit my heart goes out to the Intel engineers who thought they would finally escape their x86 legacy with their "clean slate" Itanium, but then ended up having to emulate AMD's 64-bit hack to x86 instead. Apple is so close to the point where they could have made x86-64 the minimum spec machine for the Intel transition... I wonder if not waiting for this point (or that's what I'm assuming from what they've told developers to code for) could really bite them in the ass if they have to start supporting 4 architectures for their OS (PPC32, PPC64, x86-32, and x86-64)
Also, while most people can't really distinguish 60 fps from 30 fps (although I think they can notice the "glassy smoothness" subconsciously), the decreased response time at higher framerates makes a big difference for gameplay, especially in driving games, where it is easy for people to start overcorrecting turns when the framerate is too low.
Most modern 3D pipelines introduce a few frames of latency--for instance, on a popular console, the sequence is: controller stick moved, signal is sent to console, at the next vertical blank the new controller position is sent to the main CPU, at which point the gameplay or physics code updates the game state, then builds up a graphics display list to show it, but the previous frame's display list is currently being drawn, so it won't be kicked off until the next vertical blank. So then the new scene is drawn, but it is being drawn to an offscreen buffer so that you don't see the triangles being drawn in, then the NEXT vertical blank, the offscreen is typically copied along with motion blur or other effects, to the actual screen, and only then does the TV start to draw a frame that reflects what the user did three frames ago. So, at 60 fps, this works out to about 45 milliseconds, but at 30 fps it climbs up to nearly a tenth of second.
So for a PC game, running at greater than 60 fps does actually have an effect on reduced latency, even if running at 60 Hz refresh (of course many CRT monitors can go to 120 Hz these days). The old consoles such as the Atari 2600 pretty much drew the picture just ahead of the electron beam--try playing a game like Kaboom! with a paddle on a real Atari connected to a real analog CRT TV (digital TVs can introduce yet more latency) to see what true responsiveness feels like!
Power-on to Desktop: 46 Seconds (autologin enabled, no startup items)
Shutdown: 13 seconds
I usually just have the laptop sleeping, and while wake from sleep is really fast, the one irritating thing is the airport card takes a few seconds to reconnect to the network, and so if Mail happens to check during that time, it just fails right away. It seems like they could special-case that situation in some way.
After reading about how the head of SIS (A.K.A. MI6) was called "C", I figured that surely at some point they would refer to James Bond on the site somewhere. When I found it, I was a little surprised that they didn't say the film had no basis in reality. I guess they're hoping to use the connection to help recruiting...
Q: How realistic is the depiction of SIS in the James Bond films?
A: James Bond, as Ian Fleming originally conceived him was based on reality. But any author needs to inject a level of glamour and excitement beyond reality in order to sell. By the time the filmmakers focused on Bond the gap between truth and fiction had already widened. Nevertheless, staff who join SIS can look forward to a career that will have moments when the gap narrows just a little and the certainty of a stimulating and rewarding career which, like Bond's, will be in the service of their country.
I'm not too surprised that tattoos haven't been pursued by the copyright holders, because it's pretty nickel-and-dime, and probably in a lot of cases it increases the value of the brand (except for family-focused characters portrayed in adult situations), and suing some guy for a cartoon tattoo is likely to generate a PR backlash.
Big chip companies inscribing copyrighted characters onto their chips, on the other hand, is quite surprising. My guess is that the legal staffs of these companies weren't consulted on this practice, because basically if you have a clue you know that risking litigation for some geeky easter egg that has almost no positive benefit for the company is completely stupid, especially where it's not completely out of the question for the IP holder to be awarded a per-unit royalty retroactively. I suppose the engineers at those companies probably have little experience with the IP issues involving licensed properties and haven't yet achieved that level of defensive paranoia that is pretty much required these days.
Unfortunately the "standards set by the big guys" aren't that great. My experience, at least coming from the real-time side of the coin, is that MAX, Maya, Multigen each suck in different ways; usually something that is easy on one package is hard on the others, maintaining plugins is far harder than it should be, plus they all seem surprisingly buggy for "professional" software. Maya has what looks on paper as a "pretty" architecture that sounds appealing, but in practice it seems to devolve into a twisted morass of nodes because they are missing a secondary layer of organization--it's like debugging large programs in machine language. MAX seems pretty slapped together and has its own share of bone-headed problems. All the packages seem to be poorly-performing resource hogs. It'll only get worse for next-generation stuff. Plus I don't even really use these things, I just have to watch the artists using them.
Occasionally I wonder what a "iApp" style 3D modeler would look like; sort of like a GarageBand, where you would sacrifice some advanced functionality to make a slick and easy-to-use package that can solve 90% of people's problems. I think it would require some amazingly clever re-conceptualization of the editing problem...
UK: I haven't got a nose. US: I don't have a nose.
UK: Microsoft are delaying Longhorn. US: Microsoft is delaying Longhorn.
Also, grammar certainly does change quite a bit even in the course of a thousand years. E.g., "With this ring I thee wed" is a remnant of when English used Subject-Object-Verb ordering (like German) instead of Subject-Verb-Object, whereas most of the so-called "strong irregular verbs" in English can be traced back to proto Indo-European (~7000 BC). English has also lost almost all of its declinations for case, except for pronouns.
Nevertheless, this new technique does sound like a promising tool for historical linguistics.
I'm sure the Revolution controller will be much more sophisticated and smooth than the PowerGlove, but according to this site the PowerGlove had multi-bit precision on most of its axes. I wonder if they had a "1-bit compatibility mode" to work with existing games built for the standard controller. I've also heard of people hacking the PowerGlove to use on their PC as a cheap VR device. Caveat: I have never used one myself.
Inspired by the success of the VPL DataGlove, the Mattel toy company manufactured in 1989 a low-cost glove as a controller for Nintendo home vidco games. The Power Glove is a flexible molded plasticgauntlet with a Lycra palm. Embedded in the plastic on the backs of the fingers are resistive-ink flex sensors that register overall bending of the thumb and index, middle, and ring fingers with two bits of precision per finger. (This is a limitation of the A/D converters used, not the sensors themselves.) Mounted on the back of the hand are acoustic trackers that locate the glove accurately in space (to one-fourth inch) with respect to a companion unit mounted on the television monitor. The trackers also provide four bits of roll orientation for the hand (rotation of the wrist). Although the least accurate of the whole-hand input devices the Power Glove is also the cheapest by a factor of 100. It works with several Nintendo games, such as one where punching motions control the swing of an on-screen boxer. Some games have been especiallv designed for the Power Glove. One allows a player to "hit" or "grab and throw" a ball against tiles in a hand-ball-like court imaged on the screen.
The fact that you plucked an old 2MB Virge out of a P166, stuck it into a newer machine as a *secondary* card, and you were able to drag a modern 3D game into its monitor and it actually ran at all is nothing short of a miracle...
The Virge was definitely a dog back in its day, probably even worse than an ATI Rage II, but I would be impressed if any of its better-performing contemporaries (e.g, Rendition or Mystique) would be capable of that feat... I just did a search, and couldn't even find any evidence of Virge drivers for 2000/XP. I had thought that trying to get dual monitors to work under 98 was pretty touch-and-go.
Yeah, it looks like the three biggest reasons why VU0 was hardly ever utilized by most games have been addressed: 1) much more useful connection to main memory without bothering the main CPU, 2) writing your code in C/C++ is now a reasonable option due to a more complete set of instructions, and 3) much more local memory (vs 4K!)
I kind of think they still have to worry about 4) lazy programmers...
I hope the compiler support for vector intrinsics is better than the Dylan Cuthbert VU0 macro mode extensions to gcc--while cool, the compiler was constantly putting in redundant load/stores all over the place.
I would bet good money that at least one launch PS3 title will not use the SPEs at all, just PowerPC straight to RSX...
I presume the OP was aware of this and just making a joke, but for pedantry, just noting that SI uses a specific subset of the more general metric system, namely meters, kilograms, and all other units that are derived from those or seconds such as newtons (kg m/s^2) or joules. There are other non-SI systems that use metric, such as CGS (centimeter-gram-second), with derived units such as dynes and ergs. Then of course there is the inch-pinch-jiffy system of which we do not speak.
But thanks to the fscking Brits who dumped their crappy system on us hapless Americans, I can only really think in things like foot-pounds and pounds-per-inch spring rates, and end up having to use abominations such as slugs for mass.
Current generation OpenGL drivers do not translate calls to DirectX. In fact, under Windows OpenGL calls go straight to the graphics driver without much Microsoft code being involved, which means that the overhead can be much less, although it also makes the drivers more work to write and maintain. There used to be a MS-supplied "Mini-client driver" which allowed smaller vendors to more easily add OpenGL support, but MS dropped support of this a while ago.
However, Microsoft has definitely been discouraging use of OpenGL on Windows for quite a while, and while I don't believe Microsoft is actually artificially degrading OpenGL performance in any way on their current operating systems, this effort probably has led to the hardware vendors devoting less time and energy to developing OpenGL drivers.
John Carmack has always acted as a force keeping OpenGL alive on the PC by coding his games (and thus also the games that use his engine) for OpenGL instead of Direct3D; however, the current reports are that id is now doing dual Xbox360/PC development of their next-generation engine. Unless Microsoft is releasing an OpenGL library for Xbox360 (highly unlikely), this probably means that he is switching over to D3D.
Since Apple tends to ship their consumer machines with non-upgradeable, lower-end 3D cards, any 3D game on the Mac is likely to be GPU-limited anyways, so using an OpenGL-to-DirectX conversion library may not be that much of a performance hit.
On a geological scale, the earth has had periods of being incredibly hot with no polar caps, and also of being a frozen "snowball" where life can barely survive. Our current temperate conditions (in a brief warm spell or interglacial within a greater ice age) are definitely not the norm, so we all have a really big incentive not to screw with it, because compared to the majority of the earth's history, we really have it good right now.
Unfortunately, the earth's climate is chaotic and nonlinear, where runaway processes can very quickly and probably irreversibly magnify small changes (e.g., melting ice sheets releasing trapped CO2 causing further warming on one hand, or another situation where a cold summer not melting as much snow in the north, causing the earth to reflect more heat, causing it to be even colder next summer, etc) Furthermore, an increase in global temperatures by a few degrees doesn't simply mean that everywhere goes up a few degrees and that's that--more likely is it would cause shifts in air and ocean currents, probably causing hard to predict changes everywhere. The Western Europeans, who depend on the gulf stream staying where it is, are probably more vulnerable. If currently productive growing regions become infertile, that will be quite disruptive, especially to those of us in the "First World" who would most likely lose out in any reshuffling of the climate deck.
While it may seem paradoxical that even though we can't be sure if changes could lead to sudden warming or sudden cooling, pumping out tons and tons of greenhouse gasses into the air is basically performing a huge, uncontrolled experiment in global climate change. Oh, yeah, and a billion Chinese people would like to buy cars and run their air conditioner all summer, and if we Americans haven't set such a good example of self restraint, we can hardly ask them to be mindful of their CO2 emissions?
Actually, most PC games end up being CPU-bound when running at "reasonable" resolutions/AA settings. Due to inefficiencies in it's architecture, DirectX incurs a very high overhead for each batch of primitives, so much so that Microsoft is telling developers to focus on reducing the number of batches per frame to as low as a few hundred for maximum performance. Supposedly this will be vastly reduced in future versions of DirectX.
Obviously Microsoft has always been trying to drive out OpenGL in favor of DirectX, but I wonder if the existence of the Xbox has given them additional incentive--if they get game developers to use DirectX instead of OpenGL, this not only makes porting to Mac and *NIX much harder, but also makes porting to Xbox360 easier.
If the "translation" layer doesn't support HLSL vertex and pixel shaders, it will make OpenGL dead in the water for PC gaming. I wonder what this will do to the 3D workstation market, though. Will users of Maya start switching to Macs, or will the next version of Maya use D3D?
SN now has their own in-house C++ compiler. Uptake for the PS2 has been pretty slow because it came so late in the product cycle and is taking a while to mature; however I believe that SNC is the primary compiler for PSP, and after the Sony acquisition I can imagine it will become the standard PS3 compiler (although GCC probably has better support for PPC than MIPS, so it might be harder for SN to make their compiler competitive).
Revolution will probably be stuck with Codewarrior (bleah), unless someone else besides SN gets into the GCC custom support business.
I wonder if every cross-console tool provider will be acquired by one of the console makers or EA. Who's next; RAD tools?
My big beef with C++ member function pointers is that there isn't a good way to pass a pointer to a member function of class A to someone who hasn't "heard" of class A without ugly workarounds.
I feel like the C++ member function pointers are nearly useless in their current form. If the language supported the concept of a bound member function pointer, it would enable a lot of the nice things you can do in ObjC, and fairly efficiently.
and want to pass my_foo->Bar(), the compiler should be able to output pretty much the same code as when it would actually generate a member function call, e.g., adjust the "this" pointer if neccesary, lookup the actual function address in the vtab, and then just store those two pointers. Actually calling through this "fat pointer" might even be faster than a regular virtual function call--just put the "this" part of the pointer into the appropriate register and then jump-to-subroutine-register on the function pointer (you could even load the "this" pointer in the branch delay slot on MIPS architectures). This would be incredibly useful, the main problem is coming up with a nice syntax that fits into the rest of the language. How about this one:
This has always seemed to me like such an obvious, useful, and unobtrusive extension to the language, that I'm curious if there is some good reason why this hasn't been considered--e.g., is there some nasty case where this would be hard or impossible to implement, or is considered to violate some aesthetic principle of the language, or are what seem to me to be ugly workarounds considered acceptable by most people (and thus extending the language to support it would be "redundant")?
Even in basic rock and roll there's a lot of subtleties in timing that people don't even notice that they're doing, but affect the feel quite a bit. However, that's something that can be solved by better "content" for this machine. After listening to the mp3 clips, I think this machine is suffering an even more basic limitation in that it doesn't seem like they have any control of damping, and possibly no modulation of picking strength, so it didn't even sound like a guitar at all, more like a robotic harpsichord with broken dampers (the strings would ring on and made some of the songs sound almost cacophonic).
I wonder if they could improve their sound using the existing hardware but using more clever programming and/or specially-authored files (instead of what sounds like quantized MIDI files played through a pretty naive mapping of notes to strings)--for instance, they might be able to fake out left-hand damping say in response to midi key-off messages by modulating the "finger" solenoids with PWM to release the pressure a little bit to "kill" the note at least for the fretted notes, and while they probably couldn't do pull-offs, they should definitely be able to do "hammer-ons" instead of picking the string for every note.
One thing's for certain, that thing could probably play some pretty crazy chord-shapes with its 20-something fingertips. I wonder if there have been any guitarists with extra fingers on their left hand that could play a full C7-shape barre chord or some other impossible thing.
From the PA scans I've seen, I would guess VU0 is idle most if not all of the time on the majority of PS2 games, and I suspect we'll see 7 dark SPE's on a lot of the first-generation PS3 titles.;)
I do think they must have been talking to PC developers or something, especially when they say things like the original Xbox was limited by a slow CPU and "only" 64 MB of memory. At least when co-developing with the PS2, it felt like the Xbox had gobs of CPU time and RAM, and the limiting factor was fill rate and memory throughput.
Also, as someone who's written non-graphics VU0 code, to me the SPEs look like a walk in the park. Integer multiplies? We can use C? Read *and* write memory without CPU intervention? Sounds pretty good to me, although of course it will probably be hard to find enough tasks that are a natural fit to the SPEs, not to mention multi-platform issues.
I remember when we first moved to PS2 development from the PC, and all the PS1 developers were saying how awesome the seemingly crippled PS2 was and I thought they were delusional. Now I feel like an old codger telling the kids how in my day we had to pair our instructions by hand, and we liked it! Actually, I am kind of sad to see the end of the PS2; while I've certainly done my share of cursing at a black screen or a 30 page DMA log, it has been pretty satisfying to pull off all the various hacks you do to get stuff running on a PS2, plus the nice feeling that doing all your graphics straight to the metal without a single library call. I think those days are over, and in ten years, nobody will care that we once got MSKPATH3 to work with DMA call/return or whatever. Such is life.
The reason Apple didn't get the CPUs they wanted from IBM is that they are too small of a player to justify the high cost to develop a series of laptop G5s or equivelent, when the bulk of IBMs customers were elsewhere with different requirements (e.g., embedded systems or consoles). By using "commodity" x86 chips from Intel, Apple is able to share the development cost across all Wintel PCs, plus leave the option of jumping to AMD if relations with Intel sour.
It's possible that the chips for Apple may have very slight variations from the regular Intel CPUs, and most likely a somewhat different motherboard chipset, but because they seeded x86 boxes to developers with one year to go, switching ISAs at the last minute would be suicide for Apple. While it is true that supporting x86 is likely to flush out most of the endian bugs in Mac software, you'll still have lots of code like:
if (PLATFORM_X86) do_sse_code(); else do_altivec_code();
And the guy that wrote do_sse_code() will be mighty pissed if that has to be pitched and needs to be written at the last minute, plus of course all the regression testing, etc.
The next Macs will definitely run x86 and make a slow transition to x86-64. Although you can't trust anyone's predictions about anything, especially Apple!
I could more easily imagine some new imaging method (I have no idea, but what about nano-scale devices doing some sort of micro-dissection?) that could record the interconnections and structure of a brain, feed this into a simulation using the current low-level understanding and modeling of neurons (which sounds like it is rather good according to what you say), and then get a very good simulation of a working brain. However, this wouldn't mean that the researchers "understood" the brain in any sense, just that they were able to record and replicate it.
Much the same way that in a physical simulation the engineer can understand the low-level behaviors of individual components well enough to create an accurate simulation, but it will have emergent properties that the engineer is in no better position to understand than anyone else because they happen at a higher level of abstraction. (My experience is in vehicle dynamics, where this is often true).
I suppose this "replicated brain" (let's assume it's a mouse brain to sidestep ethical issues) would be greatly useful as a "black box", because you could run all kinds of experiments on it that wouldn't be possible with a real brain. Also, once you have a complete system that you can test (and thus validate against a real mouse), you could hopefully determine which simplifying assumptions are valid. Running tests that require a few seconds of simulated time and take a year of computing time would allow it to be done earlier. It will be interesting to see if the various systems within the brain are at all like the sorts of solutions a human engineer would come up with (the way things like eyes are), or if they are completely impossible to understand, much like computer code that has evolved organically (thousands of code monkeys adding and removing code short-sightedly to achieve short term goals, but the system as a whole is not understandable)
...messing with a $200 video card is one thing, but voiding the warranty on your brand new $30,000 car is another, especially a very high-tech new model. Also, I believe it's not just the intake, but also the intake manifold, MAF sensors, throttle body, and airbox.
It will be interesting to see what the various tuners do with the E90 325--presumably the big guys like Dinan who enjoy a close relationship with BMW might get some pressure not to release a cheap 255 hp upgrade. The VANOS systems are supposed to be very hard to modify--it may turn out to be non-trivial to make the change without inside information.
Even if Apple did port their OS to x86 or x86/64 (clearly possible since NeXTSTEP ran on x86 as does Darwin), none of the apps would work. Apple was able to smooth out the 68K/PowerPC transition with emulation and whatnot, but it would still be a huge black eye for Apple if all current apps could only run on this archictecture under emulation, which would be horribly slow.
Whatever differences their are between G3, G4, and G5, it pretty much has zero effect on 99% of the code out there because it's all running the same instruction set. While OSX probably has vestigal support for NeXT's "fat binaries" (One application with executables for multiple architectures), getting developers to recompile all existing apps, fix any endian-related bugs (in theory nobody has these, but in practice they crop up everywhere and can be hard to track down). Since it's already hard enough to get third-party developers to support OS X as it is, I can't imagine that a slightly cheaper CPU would be worth that price to Apple. Now if Intel made a PowerPC-compatible CPU, that would be another story.
Exactly! The only place where RFID seems to make any sense is for public transit and things of that sort where lots of people stream through really quickly without any special interaction, and that could be done with a pre-paid pass of some kind without having to expose your entire credit account to anyone who can wave a receiver somewhere near you...
In most other types of transactions, (e.g., gas station, grocery store) swiping the card is a tiny fraction of the transaction time. Since credit card companies usually eat losses when fraud occurs, it's not clear why they would be eager to get behind this, especially as it also opens up the possibility of abuse by customers ("I didn't know I was being charged for those porno videos, honest!")
In fact just today I saw one sort of classic case where there was a comment indicating a problem that had lingered even though the actual problem had been fixed.
Except for the use of comments for marking "document structure" as well as brief "overview" for more complicated modules, I view comments inline with code as being required only if something is tricky, questionable, or some other hackery. Usually the time spent commenting the actual code would better be spent refactoring it and cleaning it up.
I think someone has a quote about code being primarily intended to be read by humans and secondarily by compilers, although surely phrased in some more clever and pithier way...
Slashdot Mirror
I have to admit my heart goes out to the Intel engineers who thought they would finally escape their x86 legacy with their "clean slate" Itanium, but then ended up having to emulate AMD's 64-bit hack to x86 instead. Apple is so close to the point where they could have made x86-64 the minimum spec machine for the Intel transition... I wonder if not waiting for this point (or that's what I'm assuming from what they've told developers to code for) could really bite them in the ass if they have to start supporting 4 architectures for their OS (PPC32, PPC64, x86-32, and x86-64)
Most modern 3D pipelines introduce a few frames of latency--for instance, on a popular console, the sequence is: controller stick moved, signal is sent to console, at the next vertical blank the new controller position is sent to the main CPU, at which point the gameplay or physics code updates the game state, then builds up a graphics display list to show it, but the previous frame's display list is currently being drawn, so it won't be kicked off until the next vertical blank. So then the new scene is drawn, but it is being drawn to an offscreen buffer so that you don't see the triangles being drawn in, then the NEXT vertical blank, the offscreen is typically copied along with motion blur or other effects, to the actual screen, and only then does the TV start to draw a frame that reflects what the user did three frames ago. So, at 60 fps, this works out to about 45 milliseconds, but at 30 fps it climbs up to nearly a tenth of second.
So for a PC game, running at greater than 60 fps does actually have an effect on reduced latency, even if running at 60 Hz refresh (of course many CRT monitors can go to 120 Hz these days). The old consoles such as the Atari 2600 pretty much drew the picture just ahead of the electron beam--try playing a game like Kaboom! with a paddle on a real Atari connected to a real analog CRT TV (digital TVs can introduce yet more latency) to see what true responsiveness feels like!
iBook 1.33GHz 512 MB, 10.4.2
Power-on to Desktop: 46 Seconds (autologin enabled, no startup items)
Shutdown: 13 seconds
I usually just have the laptop sleeping, and while wake from sleep is really fast, the one irritating thing is the airport card takes a few seconds to reconnect to the network, and so if Mail happens to check during that time, it just fails right away. It seems like they could special-case that situation in some way.
From the FAQ:
Big chip companies inscribing copyrighted characters onto their chips, on the other hand, is quite surprising. My guess is that the legal staffs of these companies weren't consulted on this practice, because basically if you have a clue you know that risking litigation for some geeky easter egg that has almost no positive benefit for the company is completely stupid, especially where it's not completely out of the question for the IP holder to be awarded a per-unit royalty retroactively. I suppose the engineers at those companies probably have little experience with the IP issues involving licensed properties and haven't yet achieved that level of defensive paranoia that is pretty much required these days.
Occasionally I wonder what a "iApp" style 3D modeler would look like; sort of like a GarageBand, where you would sacrifice some advanced functionality to make a slick and easy-to-use package that can solve 90% of people's problems. I think it would require some amazingly clever re-conceptualization of the editing problem...
UK: I haven't got a nose. US: I don't have a nose.
UK: Microsoft are delaying Longhorn. US: Microsoft is delaying Longhorn.
Also, grammar certainly does change quite a bit even in the course of a thousand years. E.g., "With this ring I thee wed" is a remnant of when English used Subject-Object-Verb ordering (like German) instead of Subject-Verb-Object, whereas most of the so-called "strong irregular verbs" in English can be traced back to proto Indo-European (~7000 BC). English has also lost almost all of its declinations for case, except for pronouns.
Nevertheless, this new technique does sound like a promising tool for historical linguistics.
The Virge was definitely a dog back in its day, probably even worse than an ATI Rage II, but I would be impressed if any of its better-performing contemporaries (e.g, Rendition or Mystique) would be capable of that feat... I just did a search, and couldn't even find any evidence of Virge drivers for 2000/XP. I had thought that trying to get dual monitors to work under 98 was pretty touch-and-go.
I kind of think they still have to worry about 4) lazy programmers...
I hope the compiler support for vector intrinsics is better than the Dylan Cuthbert VU0 macro mode extensions to gcc--while cool, the compiler was constantly putting in redundant load/stores all over the place.
I would bet good money that at least one launch PS3 title will not use the SPEs at all, just PowerPC straight to RSX...
But thanks to the fscking Brits who dumped their crappy system on us hapless Americans, I can only really think in things like foot-pounds and pounds-per-inch spring rates, and end up having to use abominations such as slugs for mass.
However, Microsoft has definitely been discouraging use of OpenGL on Windows for quite a while, and while I don't believe Microsoft is actually artificially degrading OpenGL performance in any way on their current operating systems, this effort probably has led to the hardware vendors devoting less time and energy to developing OpenGL drivers.
John Carmack has always acted as a force keeping OpenGL alive on the PC by coding his games (and thus also the games that use his engine) for OpenGL instead of Direct3D; however, the current reports are that id is now doing dual Xbox360/PC development of their next-generation engine. Unless Microsoft is releasing an OpenGL library for Xbox360 (highly unlikely), this probably means that he is switching over to D3D.
Since Apple tends to ship their consumer machines with non-upgradeable, lower-end 3D cards, any 3D game on the Mac is likely to be GPU-limited anyways, so using an OpenGL-to-DirectX conversion library may not be that much of a performance hit.
Unfortunately, the earth's climate is chaotic and nonlinear, where runaway processes can very quickly and probably irreversibly magnify small changes (e.g., melting ice sheets releasing trapped CO2 causing further warming on one hand, or another situation where a cold summer not melting as much snow in the north, causing the earth to reflect more heat, causing it to be even colder next summer, etc) Furthermore, an increase in global temperatures by a few degrees doesn't simply mean that everywhere goes up a few degrees and that's that--more likely is it would cause shifts in air and ocean currents, probably causing hard to predict changes everywhere. The Western Europeans, who depend on the gulf stream staying where it is, are probably more vulnerable. If currently productive growing regions become infertile, that will be quite disruptive, especially to those of us in the "First World" who would most likely lose out in any reshuffling of the climate deck.
While it may seem paradoxical that even though we can't be sure if changes could lead to sudden warming or sudden cooling, pumping out tons and tons of greenhouse gasses into the air is basically performing a huge, uncontrolled experiment in global climate change. Oh, yeah, and a billion Chinese people would like to buy cars and run their air conditioner all summer, and if we Americans haven't set such a good example of self restraint, we can hardly ask them to be mindful of their CO2 emissions?
Obviously Microsoft has always been trying to drive out OpenGL in favor of DirectX, but I wonder if the existence of the Xbox has given them additional incentive--if they get game developers to use DirectX instead of OpenGL, this not only makes porting to Mac and *NIX much harder, but also makes porting to Xbox360 easier.
If the "translation" layer doesn't support HLSL vertex and pixel shaders, it will make OpenGL dead in the water for PC gaming. I wonder what this will do to the 3D workstation market, though. Will users of Maya start switching to Macs, or will the next version of Maya use D3D?
Revolution will probably be stuck with Codewarrior (bleah), unless someone else besides SN gets into the GCC custom support business.
I wonder if every cross-console tool provider will be acquired by one of the console makers or EA. Who's next; RAD tools?
I feel like the C++ member function pointers are nearly useless in their current form. If the language supported the concept of a bound member function pointer, it would enable a lot of the nice things you can do in ObjC, and fairly efficiently.
if you have something like:
and want to pass my_foo->Bar(), the compiler should be able to output pretty much the same code as when it would actually generate a member function call, e.g., adjust the "this" pointer if neccesary, lookup the actual function address in the vtab, and then just store those two pointers. Actually calling through this "fat pointer" might even be faster than a regular virtual function call--just put the "this" part of the pointer into the appropriate register and then jump-to-subroutine-register on the function pointer (you could even load the "this" pointer in the branch delay slot on MIPS architectures). This would be incredibly useful, the main problem is coming up with a nice syntax that fits into the rest of the language. How about this one:This has always seemed to me like such an obvious, useful, and unobtrusive extension to the language, that I'm curious if there is some good reason why this hasn't been considered--e.g., is there some nasty case where this would be hard or impossible to implement, or is considered to violate some aesthetic principle of the language, or are what seem to me to be ugly workarounds considered acceptable by most people (and thus extending the language to support it would be "redundant")?I wonder if they could improve their sound using the existing hardware but using more clever programming and/or specially-authored files (instead of what sounds like quantized MIDI files played through a pretty naive mapping of notes to strings)--for instance, they might be able to fake out left-hand damping say in response to midi key-off messages by modulating the "finger" solenoids with PWM to release the pressure a little bit to "kill" the note at least for the fretted notes, and while they probably couldn't do pull-offs, they should definitely be able to do "hammer-ons" instead of picking the string for every note.
One thing's for certain, that thing could probably play some pretty crazy chord-shapes with its 20-something fingertips. I wonder if there have been any guitarists with extra fingers on their left hand that could play a full C7-shape barre chord or some other impossible thing.
I do think they must have been talking to PC developers or something, especially when they say things like the original Xbox was limited by a slow CPU and "only" 64 MB of memory. At least when co-developing with the PS2, it felt like the Xbox had gobs of CPU time and RAM, and the limiting factor was fill rate and memory throughput.
Also, as someone who's written non-graphics VU0 code, to me the SPEs look like a walk in the park. Integer multiplies? We can use C? Read *and* write memory without CPU intervention? Sounds pretty good to me, although of course it will probably be hard to find enough tasks that are a natural fit to the SPEs, not to mention multi-platform issues.
I remember when we first moved to PS2 development from the PC, and all the PS1 developers were saying how awesome the seemingly crippled PS2 was and I thought they were delusional. Now I feel like an old codger telling the kids how in my day we had to pair our instructions by hand, and we liked it! Actually, I am kind of sad to see the end of the PS2; while I've certainly done my share of cursing at a black screen or a 30 page DMA log, it has been pretty satisfying to pull off all the various hacks you do to get stuff running on a PS2, plus the nice feeling that doing all your graphics straight to the metal without a single library call. I think those days are over, and in ten years, nobody will care that we once got MSKPATH3 to work with DMA call/return or whatever. Such is life.
It's possible that the chips for Apple may have very slight variations from the regular Intel CPUs, and most likely a somewhat different motherboard chipset, but because they seeded x86 boxes to developers with one year to go, switching ISAs at the last minute would be suicide for Apple. While it is true that supporting x86 is likely to flush out most of the endian bugs in Mac software, you'll still have lots of code like:
And the guy that wrote do_sse_code() will be mighty pissed if that has to be pitched and needs to be written at the last minute, plus of course all the regression testing, etc.The next Macs will definitely run x86 and make a slow transition to x86-64. Although you can't trust anyone's predictions about anything, especially Apple!
Much the same way that in a physical simulation the engineer can understand the low-level behaviors of individual components well enough to create an accurate simulation, but it will have emergent properties that the engineer is in no better position to understand than anyone else because they happen at a higher level of abstraction. (My experience is in vehicle dynamics, where this is often true).
I suppose this "replicated brain" (let's assume it's a mouse brain to sidestep ethical issues) would be greatly useful as a "black box", because you could run all kinds of experiments on it that wouldn't be possible with a real brain. Also, once you have a complete system that you can test (and thus validate against a real mouse), you could hopefully determine which simplifying assumptions are valid. Running tests that require a few seconds of simulated time and take a year of computing time would allow it to be done earlier. It will be interesting to see if the various systems within the brain are at all like the sorts of solutions a human engineer would come up with (the way things like eyes are), or if they are completely impossible to understand, much like computer code that has evolved organically (thousands of code monkeys adding and removing code short-sightedly to achieve short term goals, but the system as a whole is not understandable)
It will be interesting to see what the various tuners do with the E90 325--presumably the big guys like Dinan who enjoy a close relationship with BMW might get some pressure not to release a cheap 255 hp upgrade. The VANOS systems are supposed to be very hard to modify--it may turn out to be non-trivial to make the change without inside information.
Whatever differences their are between G3, G4, and G5, it pretty much has zero effect on 99% of the code out there because it's all running the same instruction set. While OSX probably has vestigal support for NeXT's "fat binaries" (One application with executables for multiple architectures), getting developers to recompile all existing apps, fix any endian-related bugs (in theory nobody has these, but in practice they crop up everywhere and can be hard to track down). Since it's already hard enough to get third-party developers to support OS X as it is, I can't imagine that a slightly cheaper CPU would be worth that price to Apple. Now if Intel made a PowerPC-compatible CPU, that would be another story.
In most other types of transactions, (e.g., gas station, grocery store) swiping the card is a tiny fraction of the transaction time. Since credit card companies usually eat losses when fraud occurs, it's not clear why they would be eager to get behind this, especially as it also opens up the possibility of abuse by customers ("I didn't know I was being charged for those porno videos, honest!")
Except for the use of comments for marking "document structure" as well as brief "overview" for more complicated modules, I view comments inline with code as being required only if something is tricky, questionable, or some other hackery. Usually the time spent commenting the actual code would better be spent refactoring it and cleaning it up.
I think someone has a quote about code being primarily intended to be read by humans and secondarily by compilers, although surely phrased in some more clever and pithier way...