Some games save continuously because they don't want the player to be able to revert to a previous saved state after having things go wrong; instead, they want the player to face the consequences of a poor decision. Think NetHack.
We're talking about a console with flash memory storage. Flash is rather slow to write to, and continual saving would wear out the flash fairly quickly.
I know and understand completely, but this was an easy 1-bit switch. Not data that would have to be shoehorned into working by an expert.
I've done the same thing in games I've created. Never anything controversial though. Just came down to I decided against using a feature, so I just turned off the flag in the level data that triggered it.
I've also seen ROM hacking guides out there where changing one byte changes a boss into a different boss that's not normally in the game.
I'm far more surprised that this ever got into the project in the first place than I am that it was left in.
Have to disagree with you bud, the data for the 'mod' (which it wasn't) was in the data files for the game. It was distributed on the CD. It was therefore part of the game. It has the potential to be accessed, one way or another.
Most games have stuff like that in there. Unless you're really tight on space, fully removing unused stuff often isn't worth the risk of breaking something in the process. Especially not on a game primarily intended for consoles, where modifying things is hard and the game runs directly from the disc/cartridge.
I mean, people drive to the mall because there's parking. If there was no parking, they wouldn't drive to the mall en masse and circle around looking for parking.
You've obviously never been to a mall in New Jersey.
Gotta wonder who designs them. Take the largest mall in the state, where parking is already maxed out during the busier times of the year, and build a 16 screen movie theater right in the middle of the parking lot. Absolutely brilliant.
Why would he go with cable when fiber is available? Sure cable is going to market itself as the better option, but from a technological standpoint, it's not.
Cablevision offers 15 and 30 Mbps plans for $45 and $60 per month, possibly cheaper if you get additional services from them.
Why should someone care if they have a coax or fiber cable running into their house? The coax connects to a fiber backbone once it hits the utility poll anyway.
But your analogy is a bit flawed. The UPS consumer who will receive the package is like you or I at home at our computer; we know not nor care what UPS had to do to get it to our doorstep, as long as they charge us the amount agreed upon. How do you fit that into your Internet analogy? I suppose you could say UPS is like your local ISP, whereas the trunk providers are the toll road owners.
Of course my analogy was a bit flawed - most analogies are flawed at least a little. I went along that route because the previous poster started in that direction and got it completely wrong.
Let's try this. UPS has a contract with the operator of the toll road negotiating a price for their trucks full of packages to use the roads. The toll operator then starts inspecting the trucks on their way through and sending them on the slow road unless the shipper of the packages pays tolls as well.
Here is the question: Should the road builder be forced to open up his private roadways to the public, at no cost, even though he spent $X Billion of his own money building the roads?
That's about as far off as you can be. To go along with your original UPS/FedEx/etc idea...
You order a package from Amazon. Amazon ships it to you via UPS. Along the way, UPS takes your package along a toll road. The toll operator looks inside the truck, sees an Amazon package, wants to force the truck to take the slow lanes unless Amazon pays a toll in addition to the toll UPS is paying. Should that be allowed?
Not sure if this is an urban legend or not, but function calls between separate source code files could take longer than functions in the same source code file because the compiled executable code could end up on separate virtual memory pages. I would guess that modern compilers would optimisze the code to avoid this problem.
Virtual memory pages are typically 4 KB, so in a program of any substantial size, the odds are pretty high of any given function call crossing a page boundary. If you get a source file with a few thousand lines of code in it, you're likely to run into those issues.
This isn't an issue with kernel code, as the kernel isn't swappable. You'd have some pretty serious issues if your scheduler was swapped out to disk...
As someone with very good vision (once rated 20/10, now closer to 20/15), I find it absolutely bizarre when people comment on how HDTV vs. SDTV is "merely incremental". For my eyes, moving from a 480i blurred, craptastic image to a 720p/1080i crisp, clear picture is even more impressive than a supposedly mammoth change like B&W to color.
I'm sure a lot of that depends on your provides your TV service. If you get HD from Cablevision, it's overly compressed with very glaring compression artifacts. To me, the artifacts arefar more noticeable than the resolution increase.
Who would have thought before the Xbox that Microsoft would become a major console player? As I recall, that decision was greeted with its fair share of derision and skepticism.
Well, no one really expected MS to be perfectly happy losing $500 million every almost quarter for about 7 years now. Apparently that one profit making quarter when Halo 2 came out (and probably another when Halo 3 comes out) makes it all worthwhile to them.
Additionally RPGs have traditionally not done as well here (though I think this is a bit of a catch-22).
RPGs don't do nearly as well in the US as they do in Japan. The European game market is generally considered to be more like the US market than the Japanese market. I think that's the line of thought leading to less RPGs in Europe.
I'm sure you're right. I didn't know the details of when the K6/K6-2/K6-3 came out, so I just lumped them all together into K6. At the time, it didn't really seem like there was a huge difference between them.
K7 was long lived, but Athlon XP was a pretty significant upgrade which gave a lot more life to the K7 line.
Rockstar didn't just say, "Hah! GTA:SA sold great once it was AO, who cares if they AO this game!" they pushed the release date so they could rework the game to get an M rating.
That might have had more than a little something to do with the fact that it was a Wii/PS2 game but Nintendo and Sony don't allow AO titles on their consoles. GTA:SA got rerated AO after release, with future pressing having the AO content removed.
In addition to the Am386, the AMD K6s were inferiour to P4's, and there was a span of almost a year between P4's debut and K7's debut that Intel was running rings. Now, we're once again waiting over a year [wikipedia.org] for AMD's answer to Intel's leapfrog.
You've got your timeframes off by a bit. K6 competed against the Pentium 2 and early Pentium 3. The K7 was the original Athlon, which beat the P3 in the race to 1 GHz. Unfortunately for AMD, winning that battle cost them, as the Athlon didn't scale well too far past 1 GHz, so they fell behind the P4 for a while until the Athlon XP came out.
Verizon charges to send or receive text messages. The charges seem to be variable as well. I keep text messages blocked, however, before I did, I saw charges range from 10 - 17 cents. Not sure if the difference is peak/offpeak, data transfer fees, phase of the moon, or what.
Verizon has text messaging plans that give you a couple hundred messages in or out a month for a few dollars (varies greatly depending on when you signed up for it), but without those plans, they definitely charge you for incoming.
IMHO, if a "device" has several registers, modes, chipsets, etc.. it's no longer just a device.
Well, a keyboard probably fits your definition of a device then. But not much else. Even a mouse has an assortment of registers and modes to control how it works - variable sampling rates, support different protocols for backward compatibility (2 button mode, scroll wheel mode, ps/2 vs usb modes, etc), etc.
As for your Macs working well, yes, that's Apple's specialty. They limit your hardware options to only a few that they have carefully chosen so that they can be confident that everything will work.
Well, you missed the point of it. This is referring to DMA. DMA is means of fast transfer of data between main memory and an expansion device. Basically, this means that, for example, to send a packet of data to your network card, the data must exist within the first 4 GB of memory.
It simply means that when the kernel allocates buffers for data transfer to/from hardware, it has to be a little careful about where it does it. This doesn't have any impact whatsoever on userspace code.
Also, at least in the early days of 32 code, there were limits such as DMA only supporting the first 24 bits of address space. This isn't really anything new, nor is it anything to be concerned about unless you're a kernel developer.
Technically correct and wrong at the same time. EM64T has a kludge in the way that memory is addressed. The EM64T chips cannot access memory above 4GB without using pointers.
You can't access any memory without pointers.
You're probably thinking of Page Addressing Extensions (PAE), which let you swap out parts of the page tables to point to memory above 4 GB. That's existed since the Pentium Pro or so. EM64T is just the damage control name Intel's marketing department came up with for their implementation of AMD64.
There's very little difference between the instructions in the different modes. The memory management unit is where most of the differences are. Properly written 16 bit real mode code will still run in 16 bit protected mode. The only difference is how the segment portion of the pointer in interpreted.
As for 16 bit vs 32 bit modes. The instructions are mostly the same. A code segment is specified as being either 16 or 32 bit. That size is the default data sized used by instructions within that segment. There is a "size override" prefix, which if found immediately before an instruction, tells the CPU that the following instruction should use the opposite of default size.
I don't remember the specifics, but 64 bit mode just continues along with the same ideas. There aren't many changes from 32 bit code to 64 bit.
From what I've seen of g++'s headers, the different variants of operator seem to put the parameters into a common format and pass it into a core function that does the real work.
The linker will remove functions it is positive won't be used. The issue here is calling cout to print "Hello World". You only *need* the code to print out a string, but once you get into the core of cout, you reach stuff like if (data is string) {} else if (data is int) else if (data is float) {}. Which branches are needed can't be determined until run time, so you have to pull in all the code to format ints, floats, etc. That's where the bloat comes from.
It also means that the program won't grow much if you try doing fancy things with cout.
Slashdot Mirror
Intel's gonna do what Intel always does - they're gonna turn that stuff into silicon. Expect a physics engine chip from Intel.
Quite the opposite. Intel's going to work on making it scale well across multiple CPU cores so that gamers will want to buy quad core CPUs.
Making you want to replace your CPU more often is much more attractive to Intel than starting a whole new completely unproven niche hardware line.
Some games save continuously because they don't want the player to be able to revert to a previous saved state after having things go wrong; instead, they want the player to face the consequences of a poor decision. Think NetHack.
We're talking about a console with flash memory storage. Flash is rather slow to write to, and continual saving would wear out the flash fairly quickly.
I know and understand completely, but this was an easy 1-bit switch. Not data that would have to be shoehorned into working by an expert.
I've done the same thing in games I've created. Never anything controversial though. Just came down to I decided against using a feature, so I just turned off the flag in the level data that triggered it.
I've also seen ROM hacking guides out there where changing one byte changes a boss into a different boss that's not normally in the game.
I'm far more surprised that this ever got into the project in the first place than I am that it was left in.
They did do that, didn't they?
Yeah, I was commenting on how they took a bad situation and made it worse.
Better theater than others in the area, though, from what I've heard.
Not from what I've heard. Smaller screens than the tenplex it replaced.
Have to disagree with you bud, the data for the 'mod' (which it wasn't) was in the data files for the game. It was distributed on the CD. It was therefore part of the game. It has the potential to be accessed, one way or another.
Most games have stuff like that in there. Unless you're really tight on space, fully removing unused stuff often isn't worth the risk of breaking something in the process. Especially not on a game primarily intended for consoles, where modifying things is hard and the game runs directly from the disc/cartridge.
I mean, people drive to the mall because there's parking. If there was no parking, they wouldn't drive to the mall en masse and circle around looking for parking.
You've obviously never been to a mall in New Jersey.
Gotta wonder who designs them. Take the largest mall in the state, where parking is already maxed out during the busier times of the year, and build a 16 screen movie theater right in the middle of the parking lot. Absolutely brilliant.
I wonder how much Microsoft paid Miguel to say this.
They don't pay him. And that's what started him on his duplicating everything MS quest.
He applied for a job at MS years ago and got denied. Since then, he's been on this weird open source mixed with MS worship quest.
In some bits, it is predictably proximate to the tipping point to count it as either "1" or "0".
In ALL cases, it is predictable.
If I flip a coin onto my hand, it's predictable that it will land on either heads or tails. That doesn't mean it's not random though.
Why would he go with cable when fiber is available? Sure cable is going to market itself as the better option, but from a technological standpoint, it's not.
Just looking at FIOS pricing, the options are 5/15/30 Mbps for $40/$50/$180 per month.
Cablevision offers 15 and 30 Mbps plans for $45 and $60 per month, possibly cheaper if you get additional services from them.
Why should someone care if they have a coax or fiber cable running into their house? The coax connects to a fiber backbone once it hits the utility poll anyway.
But your analogy is a bit flawed. The UPS consumer who will receive the package is like you or I at home at our computer; we know not nor care what UPS had to do to get it to our doorstep, as long as they charge us the amount agreed upon. How do you fit that into your Internet analogy? I suppose you could say UPS is like your local ISP, whereas the trunk providers are the toll road owners.
Of course my analogy was a bit flawed - most analogies are flawed at least a little. I went along that route because the previous poster started in that direction and got it completely wrong.
Let's try this. UPS has a contract with the operator of the toll road negotiating a price for their trucks full of packages to use the roads. The toll operator then starts inspecting the trucks on their way through and sending them on the slow road unless the shipper of the packages pays tolls as well.
Here is the question: Should the road builder be forced to open up his private roadways to the public, at no cost, even though he spent $X Billion of his own money building the roads?
That's about as far off as you can be. To go along with your original UPS/FedEx/etc idea...
You order a package from Amazon. Amazon ships it to you via UPS. Along the way, UPS takes your package along a toll road. The toll operator looks inside the truck, sees an Amazon package, wants to force the truck to take the slow lanes unless Amazon pays a toll in addition to the toll UPS is paying. Should that be allowed?
Not sure if this is an urban legend or not, but function calls between separate source code files could take longer than functions in the same source code file because the compiled executable code could end up on separate virtual memory pages. I would guess that modern compilers would optimisze the code to avoid this problem.
Virtual memory pages are typically 4 KB, so in a program of any substantial size, the odds are pretty high of any given function call crossing a page boundary. If you get a source file with a few thousand lines of code in it, you're likely to run into those issues.
This isn't an issue with kernel code, as the kernel isn't swappable. You'd have some pretty serious issues if your scheduler was swapped out to disk...
As someone with very good vision (once rated 20/10, now closer to 20/15), I find it absolutely bizarre when people comment on how HDTV vs. SDTV is "merely incremental". For my eyes, moving from a 480i blurred, craptastic image to a 720p/1080i crisp, clear picture is even more impressive than a supposedly mammoth change like B&W to color.
I'm sure a lot of that depends on your provides your TV service. If you get HD from Cablevision, it's overly compressed with very glaring compression artifacts. To me, the artifacts arefar more noticeable than the resolution increase.
Who would have thought before the Xbox that Microsoft would become a major console player? As I recall, that decision was greeted with its fair share of derision and skepticism.
Well, no one really expected MS to be perfectly happy losing $500 million every almost quarter for about 7 years now. Apparently that one profit making quarter when Halo 2 came out (and probably another when Halo 3 comes out) makes it all worthwhile to them.
Additionally RPGs have traditionally not done as well here (though I think this is a bit of a catch-22).
RPGs don't do nearly as well in the US as they do in Japan. The European game market is generally considered to be more like the US market than the Japanese market. I think that's the line of thought leading to less RPGs in Europe.
I'm sure you're right. I didn't know the details of when the K6/K6-2/K6-3 came out, so I just lumped them all together into K6. At the time, it didn't really seem like there was a huge difference between them.
K7 was long lived, but Athlon XP was a pretty significant upgrade which gave a lot more life to the K7 line.
Rockstar didn't just say, "Hah! GTA:SA sold great once it was AO, who cares if they AO this game!" they pushed the release date so they could rework the game to get an M rating.
That might have had more than a little something to do with the fact that it was a Wii/PS2 game but Nintendo and Sony don't allow AO titles on their consoles. GTA:SA got rerated AO after release, with future pressing having the AO content removed.
In addition to the Am386, the AMD K6s were inferiour to P4's, and there was a span of almost a year between P4's debut and K7's debut that Intel was running rings. Now, we're once again waiting over a year [wikipedia.org] for AMD's answer to Intel's leapfrog.
You've got your timeframes off by a bit. K6 competed against the Pentium 2 and early Pentium 3. The K7 was the original Athlon, which beat the P3 in the race to 1 GHz. Unfortunately for AMD, winning that battle cost them, as the Athlon didn't scale well too far past 1 GHz, so they fell behind the P4 for a while until the Athlon XP came out.
Verizon charges to send or receive text messages. The charges seem to be variable as well. I keep text messages blocked, however, before I did, I saw charges range from 10 - 17 cents. Not sure if the difference is peak/offpeak, data transfer fees, phase of the moon, or what.
Verizon has text messaging plans that give you a couple hundred messages in or out a month for a few dollars (varies greatly depending on when you signed up for it), but without those plans, they definitely charge you for incoming.
IMHO, if a "device" has several registers, modes, chipsets, etc.. it's no longer just a device.
Well, a keyboard probably fits your definition of a device then. But not much else. Even a mouse has an assortment of registers and modes to control how it works - variable sampling rates, support different protocols for backward compatibility (2 button mode, scroll wheel mode, ps/2 vs usb modes, etc), etc.
As for your Macs working well, yes, that's Apple's specialty. They limit your hardware options to only a few that they have carefully chosen so that they can be confident that everything will work.
Well, you missed the point of it. This is referring to DMA. DMA is means of fast transfer of data between main memory and an expansion device. Basically, this means that, for example, to send a packet of data to your network card, the data must exist within the first 4 GB of memory.
It simply means that when the kernel allocates buffers for data transfer to/from hardware, it has to be a little careful about where it does it. This doesn't have any impact whatsoever on userspace code.
Also, at least in the early days of 32 code, there were limits such as DMA only supporting the first 24 bits of address space. This isn't really anything new, nor is it anything to be concerned about unless you're a kernel developer.
Technically correct and wrong at the same time. EM64T has a kludge in the way that memory is addressed. The EM64T chips cannot access memory above 4GB without using pointers.
You can't access any memory without pointers.
You're probably thinking of Page Addressing Extensions (PAE), which let you swap out parts of the page tables to point to memory above 4 GB. That's existed since the Pentium Pro or so. EM64T is just the damage control name Intel's marketing department came up with for their implementation of AMD64.
There's very little difference between the instructions in the different modes. The memory management unit is where most of the differences are. Properly written 16 bit real mode code will still run in 16 bit protected mode. The only difference is how the segment portion of the pointer in interpreted.
As for 16 bit vs 32 bit modes. The instructions are mostly the same. A code segment is specified as being either 16 or 32 bit. That size is the default data sized used by instructions within that segment. There is a "size override" prefix, which if found immediately before an instruction, tells the CPU that the following instruction should use the opposite of default size.
I don't remember the specifics, but 64 bit mode just continues along with the same ideas. There aren't many changes from 32 bit code to 64 bit.
Actually, cout ::operator
From what I've seen of g++'s headers, the different variants of operator seem to put the parameters into a common format and pass it into a core function that does the real work.
The linker will remove functions it is positive won't be used. The issue here is calling cout to print "Hello World". You only *need* the code to print out a string, but once you get into the core of cout, you reach stuff like if (data is string) {} else if (data is int) else if (data is float) {}. Which branches are needed can't be determined until run time, so you have to pull in all the code to format ints, floats, etc. That's where the bloat comes from.
It also means that the program won't grow much if you try doing fancy things with cout.