You're forgetting that the Constitution gives Congress the power to provide for the general welfare of the United States. That's where all that stuff falls under.
Yeah, Zelda 2 didn't have money, hence it wasn't plentiful.
Enemies drop much less money in Zelda 1 than in other Zeldas. In most of the newer games, your wallet is about full by the time you actually have to spend money, but in the first, you have to actively hunt down money early on to equip yourself. After that point, there's enough free money lying around that you don't have to hunt too hard for money, but it's still no where near as easy as the newer games where you can chop grass randomly and find large amounts of rupees.
The money for Tingle wasn't a big deal unless you waited to do that stuff until you absolutely had to. Money is plentiful in every non-NES Zelda game, so as long as you go see Tingle when you wallet starts getting full, you shouldn't have to worry about it much.
The complaint with Wind Waker is all the sailing needed to track down the stuff the maps point to... which was even worse in the Japanese version, as while the US had maps to triforce pieces, Japan had maps to maps to maps to Triforce pieces.
You might make an argument about not allowing hard links, or deleting files that are in use, but the renaming thing is just stupid.
It's not so much the renaming thing that's bad. The problem is following it up by creating another file with the same name while the original is still in use. Bad things can happen when you do that with things like shared libraries or data files that affect program logic.
logically, if it's mostly first person and mostly shooting, I think you pretty much have to put it in the FPS category, even if it does overlap with other genres a bit.
But that's the thing. Metroid Prime isn't mostly shooting. It's exploring with a little shooting thrown in. You can constantly shoot if you want to, but there's little reason to.
The trash issue is just a weird thing, but the rest of the things you listed make sense. Under the Windows design, it would be a bug if you could do those things.
Unix and Windows look at the file system in two different ways. On Unix, the filename doesn't mean much. The filename is used to look up an inode, which is what actually tracks the data. Once the inode is found, the filename is meaningless. You can move, change, or delete the filename as you wish without it impacting the inode or the actual file data.
The Windows approach doesn't make a distinction between the filename and the inode. As the inode is invisible to the user, Windows doesn't let it show through in any way.
The biggest difference this makes is on Unix two programs can open what they think is the same file but actually can be completely unrelated. Hardcore Unix people think this is a good thing. Nobody else does.
I don't play Mario Kart hardcore, so I can't really comment on the balance too much, other than to say nothing stands out as being really out of line to me. The big thing about Double Dash was it was a far more accessible game. 2 players on one kart is a lot more fun than separate karts when you've got players of different skill levels.
As for the battle mode, the DD stages are at least more interesting than MK64's. I couldn't stand that stage that was just a circle with a lava pit in the middle. The slanted track just didn't work well with the game's camera. Outside of that stage, none of the other MK64 battle tracks stand out to me anymore.
I know that, I originally started this by saying it would have too little memory to be worthwhile. My point there was just that the bank switching issue was essentially negligible.
That's true, but only because a programmer's usage patterns are highly atypical. Typical usage patterns for normal users do not involve lots of short-lived processes that read in a chunk of data, process it, and exit;
Ignore the short lived process part of it, which isn't the important part, and it's not that atypical. Anything involving HTML is going to be frequently opening and closing the same files. Whether you're designing a site or just browsing the company intranet in a web browser, you're going to be constantly opening and closing lots of HTML, image, and stylesheet files.
Audio work will have similar patterns - modify your composition, then read in the samples to create the output. Or 3D graphics work with the textures.
Oh, and lets not forget databases, which are full of random access of large data sets.
This would end up being a much faster workflow because instead of having to go through filesystem lookups and read the blocks (which is relatively slow even from cache), the compiler would simply be handed the data it needs, or at least a series of VM pages that will contain the needed content after it is paged in.
On any sort of large project, the memory demands for a system like that would be unfeasible. Not to mention you're basically just creating your own cache, which would have the same access issues as the system cache.
The typical computer user (not programmer) reboots their computer every few days, whether because they need to swap batteries in a laptop, because the kernel is leaking memory, etc. For them, that gives a fairly short upper bound to the lifespan of data in the cache.
That was true in the Win9x days, but not anymore. Look at your typical college or office setup. It's pretty rare to turn the computers off in those places.
If the computer reboots before that data is needed again, you've just made every disk operation take an extra few dozen CPU cycles with no benefit.
A few dozen CPU cycles on a modern computer is going to take in the ballpark of 10-20 nanoseconds. A typical hard disk is going to take around 10 milliseconds to seek to the data, plus the time to read it. The CPU time is completely negligible.
That means that your cache is now effectively 10% slower than it was before. If most of your data is already cached, that's a pretty huge impact, and if you are pulling data from cache frequently, it can easily exceed the gains you'd get from occasionally saving a disk read.
10% slower cache is completely meaningless when you realize that the cache lookup is a million times faster than the disk read.
That should not be the case. The symbol tables are the only thing that absolutely has to be loaded at startup. Everything after that should be on an as-needed basis, though there are performance advantages to immediately loading all of the blocks containing functions that you know will be used during a typical application launch, of course.
Theory and practice are different though. Seriously, read some of the "Why does KDE start so slowly?" articles. A very large amount of symbols get resolved at program startup. Enough to create very noticeable delays.
You can still throw this page away; if you have to reload it from disk, then you just take the extra performance hit of having to relink it. The logic need not be in the kernel. I don't see any reason why relocatable code should be any different except for the need to keep track of where you put it instead of relying on the file to provide a load address.
The problem with this is the entire concept of virtual memory. Virtual memory is completely transparent to the application. Only the kernel knows it happens. Relocations are done in userspace. What you're talking about here makes sense and could be done with enough kernel work, but isn't. At least not in modern Unix systems. I don't know about Windows.
This is nothing to do with lack of developers. It's a case of finding a last minute show stopping bug. A game needs to be final and done with testing about 2 months before the release date. They should be starting manufacturing now. Either they knew for several months that they weren't going to make the date, or much more likely, a serious bug was discovered at the last minute.
From the little we've heard and the timing, it sounds like they found a show stopper bug at the last minute. They basically started talking about the delay right when they should have been sending the final game for manufacturing. The commentary about it on smashbros.com yesterday makes it sound like it's an unexpected issue rather than simply not being done on time.
Running Win3.1 apps on Win32 isn't really a virtual machine. It's just a 16 bit process where all the Win16 API calls thunk over to the corresponding Win32 calls. Likewise for running Win32 apps on Win64.
And it does matter how large it is, as the Win32 code has to know how to deal with being called from 16 bit code.
I think you're close on your idea. Except it's the rabid fighting game fans trying to justify why they like SSB. Kinda like the diehard RPG fans calling Zelda an RPG to justify liking it...
Most SSB fans realize there isn't really a good genre to put the game into, although fighting is probably the closest.
Bank switching actually wouldn't be a big deal for swap. You're most likely swapping out 4 KB pages, so it'll work well with the 64 KB bank, and a bank switch isn't more than a few instructions.
Paging out data to disk in order to make room for disk cache is almost never a good idea, as the changes of needing to later access a data page page in an application are typically far greater than the chances of reusing a randomly read block on disk.
That depends on how you use your computer. Think about at a programmer's workload. You start the compiler, it processes your code along with a ton of other files it depends on, then you get the results. And usually a few minutes later you'll have another build with more changes.
By contrast, data explicitly loaded into RAM by an application (assuming the app is reasonably well written) is in memory for a reason, and if the data were transient, the app would have repeatedly reused a single chunk of temporary storage instead of keeping the data around. The odds that any data won't ever be used again should be vanishingly small unless an app is written poorly.
Again, programmer's workflow. Take a program like Visual Studio. It'll read in and parse your entire program and all the headers it's dependent on. It'll store a tree in memory of all the symbols within the scope of the project. On a large project, only a very small portion of that symbol data will be useful to what you're currently working on, but the IDE has no way of knowing what code you're going to write, so it can't trim down that data.
Thus, cache is a great example of the principe of diminishing returns. Doubling cache does not necessarily double the benefits. Once cache gets to a certain point, doubling it no longer significantly increases the number of additional hits in the cache. Every increase beyond that point will likely hurt performance by increasing the management overhead without actually increasing the number of successful hits.
You probably need a ridiculous amount of RAM and an extreme habit of opening files once and never using them again before that would have a detectable impact.
Indeed, the only thing that makes sense to not keep in core is infrequently used code text, but that can be thrown away without ever paging it out; it can always be paged back in from the original executable if needed.... Note: this all assumes that your OS is smart enough to only load in application pages as they are used rather than loading the entire app in at launch.
You're forgetting about one big factor. Code relocation. Any time code calls a shared library, the program loader has to fill in the appropriate memory address at load time. The code loaded does not directly match the code on disk anymore. In a C++ program, there's a LOT of relocations that need to be done. They're slow. Look into all the "Why does KDE take so long to start up?" stories if you don't believe me. The relocations have two side effects relevant to this discussion:
1) A much larger portion of the executable gets loaded at startup than you would otherwise think.
2) Sections of code with relocations can't simply be reread from disk and must instead be swapped as needed, unless you move the relocation logic from userspace and into the kernel.
The supposed character tiers in Smash Bros are a pretty stupid idea. They come from tournament play where matches are limited to 1 vs 1 and the rules are set to eliminate as much randomness as possible. Items get turned off and a large chunk of the stages aren't allowed.
It's basically trying to turn Smash Bros into Street Fighter and isn't at all representative of how the game is normally played.
What's a high end ISA graphics card going to have, 512 KB of RAM ? I can't picture anyone wanting to swap to that. PCI most likely wouldn't have more than a few MB of RAM, making it questionable as well.
Nope. Here's a map. Look up Varia Suit, which you get after defeating Flaahgra, the first real boss. It's in the middle of the Chozo Ruins. The nearest save point, the black dot in the yellow circle, is two rooms away, southeast. The room immediately to the north of the save point is full of stuff you need to shoot to get past; the room immedately south of Flaahgra is a puzzle room which requires you to do stuff in the right order, shoot things, and climb up a series of annoying platforms.
Just checked that as I had a save not long after. It took just over a minute to get from the Save Point to the door to Flaahgra's room while playing on hard mode (which I think doubles the hitpoints of everything).
For "The room immediately to the north of the save point is full of stuff you need to shoot to get past", it was 3 one hit to kill enemies that appear directly in your line of fire.
For the other room, the "puzzle" is scanning a few symbols that are on your way up, no order required. Once you know where they are, they barely slow you down. Shoot a missile at the wasp hives when you walk in and you won't get any wasps to worry about. For the tenacles, they should be right in your line of fire as you approach, so it's not exactly a challenge to shoot them. As for the platforms, they're very large platforms spaced closely together. The jumps get much harder as you progress through the game.
The other reason was that every time you left a room, it would respawn.
You can definitely go at least one room away and come back without the enemies respawning.
Which meant that travelling required you to shoot the same monsters again, and again, and again, and... it was just dull.
Most enemies you can just ignore and walk right past if you're just passing through a room. Remember, most creatures aren't really enemies. They only bother you if you get too close to them. The environment is your real enemy. Ignore the creatures unless they're preventing you from getting where you're trying to go.
Well, in Prime 1, the one boss with a badly placed save isn't too big a deal. It's a very simple boss that you should be able to beat very easily once you have a clue what's going on. It really should only beat you if you're totally not expecting it and come in very weak.
Prime 2 I will agree was extremely frustrating when it came to that boss without a save.
Anyway, I'm not trying say those cases weren't design mistakes. I'm just responding to someone who was claiming these issues occurred early and often, ruining the game. If you think that's the case, then you're just completely missing the save points, which aren't hidden...
Oh, look, here's a boss. I've just met it for the first time and it's killed me. Fair enough, that's what bosses do. Okay, back up to the save point and let's try again. Uh... the closest save point to the boss is five minutes' walk away. On the other side of a puzzle room. And a room-full of low level monsters I have to fight through. Every time.
You must've been missing the save points. There was only one boss in Metroid Prime that was any significant distance away from a save point, and it was about 2/3 through the game. It was some sort of security drone in the Phazon Mines... for whatever reason, they put a save room immediately after the boss fight rather than before it.
Prime 2 also had one boss like that, about halfway through (Alpha Blogg I think it was called). Prime 3 didn't have anything like that.
Rare cost ~300 million; Bungie would be worth at least twice that today
MS paid Nintendo ~300 million for Nintendo's 49% share of Rare. Presumably they paid Rare a similar amount for the rest of the company.
As for comparing the values of the company, that's a tough call. Rare owned the rights to Perfect Dark, Banjo-Kazooie, Killer Instinct, Conker, and some assorted other properties, some recent, some not. The only thing Bungie has done in this decade is Halo, which MS is retaining the rights to. They've got the rights to their older games, but none of them are fresh, so their value is low. Rare also was a much larger studio. Bungie works on one game at a time, whereas Rare typically did 3-4 at a time back then.
Slashdot Mirror
Who's talking about the preamble? I'm referring to Article I, Section 8. Right before they give examples of what Congress can do.
You're forgetting that the Constitution gives Congress the power to provide for the general welfare of the United States. That's where all that stuff falls under.
Yeah, Zelda 2 didn't have money, hence it wasn't plentiful.
Enemies drop much less money in Zelda 1 than in other Zeldas. In most of the newer games, your wallet is about full by the time you actually have to spend money, but in the first, you have to actively hunt down money early on to equip yourself. After that point, there's enough free money lying around that you don't have to hunt too hard for money, but it's still no where near as easy as the newer games where you can chop grass randomly and find large amounts of rupees.
The money for Tingle wasn't a big deal unless you waited to do that stuff until you absolutely had to. Money is plentiful in every non-NES Zelda game, so as long as you go see Tingle when you wallet starts getting full, you shouldn't have to worry about it much.
The complaint with Wind Waker is all the sailing needed to track down the stuff the maps point to... which was even worse in the Japanese version, as while the US had maps to triforce pieces, Japan had maps to maps to maps to Triforce pieces.
You might make an argument about not allowing hard links, or deleting files that are in use, but the renaming thing is just stupid.
It's not so much the renaming thing that's bad. The problem is following it up by creating another file with the same name while the original is still in use. Bad things can happen when you do that with things like shared libraries or data files that affect program logic.
logically, if it's mostly first person and mostly shooting, I think you pretty much have to put it in the FPS category, even if it does overlap with other genres a bit.
But that's the thing. Metroid Prime isn't mostly shooting. It's exploring with a little shooting thrown in. You can constantly shoot if you want to, but there's little reason to.
Morrowind is a first person game that also features shooting. But it's an RPG, not an FPS.
The trash issue is just a weird thing, but the rest of the things you listed make sense. Under the Windows design, it would be a bug if you could do those things.
Unix and Windows look at the file system in two different ways. On Unix, the filename doesn't mean much. The filename is used to look up an inode, which is what actually tracks the data. Once the inode is found, the filename is meaningless. You can move, change, or delete the filename as you wish without it impacting the inode or the actual file data.
The Windows approach doesn't make a distinction between the filename and the inode. As the inode is invisible to the user, Windows doesn't let it show through in any way.
The biggest difference this makes is on Unix two programs can open what they think is the same file but actually can be completely unrelated. Hardcore Unix people think this is a good thing. Nobody else does.
I don't play Mario Kart hardcore, so I can't really comment on the balance too much, other than to say nothing stands out as being really out of line to me. The big thing about Double Dash was it was a far more accessible game. 2 players on one kart is a lot more fun than separate karts when you've got players of different skill levels.
As for the battle mode, the DD stages are at least more interesting than MK64's. I couldn't stand that stage that was just a circle with a lava pit in the middle. The slanted track just didn't work well with the game's camera. Outside of that stage, none of the other MK64 battle tracks stand out to me anymore.
I know that, I originally started this by saying it would have too little memory to be worthwhile. My point there was just that the bank switching issue was essentially negligible.
That's true, but only because a programmer's usage patterns are highly atypical. Typical usage patterns for normal users do not involve lots of short-lived processes that read in a chunk of data, process it, and exit;
Ignore the short lived process part of it, which isn't the important part, and it's not that atypical. Anything involving HTML is going to be frequently opening and closing the same files. Whether you're designing a site or just browsing the company intranet in a web browser, you're going to be constantly opening and closing lots of HTML, image, and stylesheet files.
Audio work will have similar patterns - modify your composition, then read in the samples to create the output. Or 3D graphics work with the textures.
Oh, and lets not forget databases, which are full of random access of large data sets.
This would end up being a much faster workflow because instead of having to go through filesystem lookups and read the blocks (which is relatively slow even from cache), the compiler would simply be handed the data it needs, or at least a series of VM pages that will contain the needed content after it is paged in.
On any sort of large project, the memory demands for a system like that would be unfeasible. Not to mention you're basically just creating your own cache, which would have the same access issues as the system cache.
The typical computer user (not programmer) reboots their computer every few days, whether because they need to swap batteries in a laptop, because the kernel is leaking memory, etc. For them, that gives a fairly short upper bound to the lifespan of data in the cache.
That was true in the Win9x days, but not anymore. Look at your typical college or office setup. It's pretty rare to turn the computers off in those places.
If the computer reboots before that data is needed again, you've just made every disk operation take an extra few dozen CPU cycles with no benefit.
A few dozen CPU cycles on a modern computer is going to take in the ballpark of 10-20 nanoseconds. A typical hard disk is going to take around 10 milliseconds to seek to the data, plus the time to read it. The CPU time is completely negligible.
That means that your cache is now effectively 10% slower than it was before. If most of your data is already cached, that's a pretty huge impact, and if you are pulling data from cache frequently, it can easily exceed the gains you'd get from occasionally saving a disk read.
10% slower cache is completely meaningless when you realize that the cache lookup is a million times faster than the disk read.
That should not be the case. The symbol tables are the only thing that absolutely has to be loaded at startup. Everything after that should be on an as-needed basis, though there are performance advantages to immediately loading all of the blocks containing functions that you know will be used during a typical application launch, of course.
Theory and practice are different though. Seriously, read some of the "Why does KDE start so slowly?" articles. A very large amount of symbols get resolved at program startup. Enough to create very noticeable delays.
You can still throw this page away; if you have to reload it from disk, then you just take the extra performance hit of having to relink it. The logic need not be in the kernel. I don't see any reason why relocatable code should be any different except for the need to keep track of where you put it instead of relying on the file to provide a load address.
The problem with this is the entire concept of virtual memory. Virtual memory is completely transparent to the application. Only the kernel knows it happens. Relocations are done in userspace. What you're talking about here makes sense and could be done with enough kernel work, but isn't. At least not in modern Unix systems. I don't know about Windows.
This is nothing to do with lack of developers. It's a case of finding a last minute show stopping bug. A game needs to be final and done with testing about 2 months before the release date. They should be starting manufacturing now. Either they knew for several months that they weren't going to make the date, or much more likely, a serious bug was discovered at the last minute.
From the little we've heard and the timing, it sounds like they found a show stopper bug at the last minute. They basically started talking about the delay right when they should have been sending the final game for manufacturing. The commentary about it on smashbros.com yesterday makes it sound like it's an unexpected issue rather than simply not being done on time.
Running Win3.1 apps on Win32 isn't really a virtual machine. It's just a 16 bit process where all the Win16 API calls thunk over to the corresponding Win32 calls. Likewise for running Win32 apps on Win64.
And it does matter how large it is, as the Win32 code has to know how to deal with being called from 16 bit code.
I think you're close on your idea. Except it's the rabid fighting game fans trying to justify why they like SSB. Kinda like the diehard RPG fans calling Zelda an RPG to justify liking it...
Most SSB fans realize there isn't really a good genre to put the game into, although fighting is probably the closest.
Bank switching actually wouldn't be a big deal for swap. You're most likely swapping out 4 KB pages, so it'll work well with the 64 KB bank, and a bank switch isn't more than a few instructions.
Paging out data to disk in order to make room for disk cache is almost never a good idea, as the changes of needing to later access a data page page in an application are typically far greater than the chances of reusing a randomly read block on disk.
...
That depends on how you use your computer. Think about at a programmer's workload. You start the compiler, it processes your code along with a ton of other files it depends on, then you get the results. And usually a few minutes later you'll have another build with more changes.
By contrast, data explicitly loaded into RAM by an application (assuming the app is reasonably well written) is in memory for a reason, and if the data were transient, the app would have repeatedly reused a single chunk of temporary storage instead of keeping the data around. The odds that any data won't ever be used again should be vanishingly small unless an app is written poorly.
Again, programmer's workflow. Take a program like Visual Studio. It'll read in and parse your entire program and all the headers it's dependent on. It'll store a tree in memory of all the symbols within the scope of the project. On a large project, only a very small portion of that symbol data will be useful to what you're currently working on, but the IDE has no way of knowing what code you're going to write, so it can't trim down that data.
Thus, cache is a great example of the principe of diminishing returns. Doubling cache does not necessarily double the benefits. Once cache gets to a certain point, doubling it no longer significantly increases the number of additional hits in the cache. Every increase beyond that point will likely hurt performance by increasing the management overhead without actually increasing the number of successful hits.
You probably need a ridiculous amount of RAM and an extreme habit of opening files once and never using them again before that would have a detectable impact.
Indeed, the only thing that makes sense to not keep in core is infrequently used code text, but that can be thrown away without ever paging it out; it can always be paged back in from the original executable if needed.
Note: this all assumes that your OS is smart enough to only load in application pages as they are used rather than loading the entire app in at launch.
You're forgetting about one big factor. Code relocation. Any time code calls a shared library, the program loader has to fill in the appropriate memory address at load time. The code loaded does not directly match the code on disk anymore. In a C++ program, there's a LOT of relocations that need to be done. They're slow. Look into all the "Why does KDE take so long to start up?" stories if you don't believe me. The relocations have two side effects relevant to this discussion:
1) A much larger portion of the executable gets loaded at startup than you would otherwise think.
2) Sections of code with relocations can't simply be reread from disk and must instead be swapped as needed, unless you move the relocation logic from userspace and into the kernel.
The supposed character tiers in Smash Bros are a pretty stupid idea. They come from tournament play where matches are limited to 1 vs 1 and the rules are set to eliminate as much randomness as possible. Items get turned off and a large chunk of the stages aren't allowed.
It's basically trying to turn Smash Bros into Street Fighter and isn't at all representative of how the game is normally played.
What's a high end ISA graphics card going to have, 512 KB of RAM ? I can't picture anyone wanting to swap to that. PCI most likely wouldn't have more than a few MB of RAM, making it questionable as well.
Nope. Here's a map. Look up Varia Suit, which you get after defeating Flaahgra, the first real boss. It's in the middle of the Chozo Ruins. The nearest save point, the black dot in the yellow circle, is two rooms away, southeast. The room immediately to the north of the save point is full of stuff you need to shoot to get past; the room immedately south of Flaahgra is a puzzle room which requires you to do stuff in the right order, shoot things, and climb up a series of annoying platforms.
Just checked that as I had a save not long after. It took just over a minute to get from the Save Point to the door to Flaahgra's room while playing on hard mode (which I think doubles the hitpoints of everything).
For "The room immediately to the north of the save point is full of stuff you need to shoot to get past", it was 3 one hit to kill enemies that appear directly in your line of fire.
For the other room, the "puzzle" is scanning a few symbols that are on your way up, no order required. Once you know where they are, they barely slow you down. Shoot a missile at the wasp hives when you walk in and you won't get any wasps to worry about. For the tenacles, they should be right in your line of fire as you approach, so it's not exactly a challenge to shoot them. As for the platforms, they're very large platforms spaced closely together. The jumps get much harder as you progress through the game.
The other reason was that every time you left a room, it would respawn.
You can definitely go at least one room away and come back without the enemies respawning.
Which meant that travelling required you to shoot the same monsters again, and again, and again, and... it was just dull.
Most enemies you can just ignore and walk right past if you're just passing through a room. Remember, most creatures aren't really enemies. They only bother you if you get too close to them. The environment is your real enemy. Ignore the creatures unless they're preventing you from getting where you're trying to go.
Well, in Prime 1, the one boss with a badly placed save isn't too big a deal. It's a very simple boss that you should be able to beat very easily once you have a clue what's going on. It really should only beat you if you're totally not expecting it and come in very weak.
Prime 2 I will agree was extremely frustrating when it came to that boss without a save.
Anyway, I'm not trying say those cases weren't design mistakes. I'm just responding to someone who was claiming these issues occurred early and often, ruining the game. If you think that's the case, then you're just completely missing the save points, which aren't hidden...
Are there Rogue Squadron games other than the N64 / GameCube ones?
Those games dumped you into open areas and gave you missions to accomplish. Nothing like a game like, say, Star Fox.
Bloody Metroid bloody Prime.
Oh, look, here's a boss. I've just met it for the first time and it's killed me. Fair enough, that's what bosses do. Okay, back up to the save point and let's try again. Uh... the closest save point to the boss is five minutes' walk away. On the other side of a puzzle room. And a room-full of low level monsters I have to fight through. Every time.
You must've been missing the save points. There was only one boss in Metroid Prime that was any significant distance away from a save point, and it was about 2/3 through the game. It was some sort of security drone in the Phazon Mines... for whatever reason, they put a save room immediately after the boss fight rather than before it.
Prime 2 also had one boss like that, about halfway through (Alpha Blogg I think it was called). Prime 3 didn't have anything like that.
No, they don't. As very few games are DX10, a crappy DX9 implementation would hurt Vista adoption.
Rare cost ~300 million; Bungie would be worth at least twice that today
MS paid Nintendo ~300 million for Nintendo's 49% share of Rare. Presumably they paid Rare a similar amount for the rest of the company.
As for comparing the values of the company, that's a tough call. Rare owned the rights to Perfect Dark, Banjo-Kazooie, Killer Instinct, Conker, and some assorted other properties, some recent, some not. The only thing Bungie has done in this decade is Halo, which MS is retaining the rights to. They've got the rights to their older games, but none of them are fresh, so their value is low. Rare also was a much larger studio. Bungie works on one game at a time, whereas Rare typically did 3-4 at a time back then.