And no, Zelda was always called an action RPG, like secret of mana was. It was never an "adventure" game ever.
Zelda was only ever considered an RPG by the kind of gamer that usually only plays RPGs, but needs an excuse to justify liking Zelda.
If you check the old guides from when Nintendo used to publish large strategy guides that covered multiple games, Zelda was always in the Adventure section.
Zelda really doesn't count as an RPG unless you use such a broad definition of RPG that almost any game counts as an RPG. Collecting items to progress doesn't make something an RPG...
RTF is simply a version of.doc that's largely ASCII text. It's main purpose was to be a format that was easier for tools to parse. Windows Help files used to be based off it. You can still drop whatever random objects into it.
Perhaps PowerPC has some extra features to enable it, but on x84-64, you're not getting 64 bit anything unless the kernel is running in 64 bit mode.
As for the kernel not needing to access more than a couple gigs directly - how do you propose handling memory management past the 4 GB mark? Do you propose only allowing virtual memory (including memory mapped files) on the first 4 GB ?
There's no 64 bit Flash because your Flash code is compiled into native code at run time. The compiler needs to be rewritten to make it work. Open sourcing the code wouldn't magically fix that.
Actually, last time I checked modern 64-bit cpus could actually only address 2^40 bytes of Ram, because you couldn't physically attach that much ram to them. 2^39 starting at 0 and 2^39 at the other end of the 64-bit spectrum.
2^40 is the physical RAM limit. AMD didn't bother to connect more pins to the memory bus simply because it's going to be a long time before anyone tries to put that much RAM into a PC. Reduced the number of pins needed in the chip socket and cut costs.
I believe the virtual memory goes to 2^48. Not sure the logic on that one, but it was probably to cut down on the size of page tables. I'm sure it's also one of those things that when the time comes, they'll add a setting in newer chips to enable more bits.
There was active 68k code in the classic MacOS right up to the end. The end was over 10 years after they produced the final 68k Mac. That doesn't mean the system would run on 68k, but it does mean that Apple isn't afraid to support legacy code.
If you run in x86 chip in 64 bit mode, you still retain the ability to run 32 bit code. Your kernel has to be fully 64 bit, but it's a very minor issue to keep some things as 32 bit. They could very easily make an OS that requires a 64 bit CPU but yet have the majority of the code be 32 bit.
Mac Minis still shipping with 32 bit CPUs is the biggest reason for them to keep 32 bit alive.
An still, to this day, I don't understand why people like playing Goldeneye or any other console FPS. The control you get with the gamepad is about 1000 times worse then what you get with a keyboard and mouse to the point where I find it completely frustrating and, and am unable to play almost all console FPS games.
Keyboard and mouse offers great control when you master it. But it's a rather steep learning curve. WASD isn't intuitive at all - they aren't seperated at all from the rest of the keyboard and are positioned under the weak fingers of your weak hand. At least with a gamepad, your directional controls were actually intended for directional control.
The only exception is Metroid. This is because although it is a FPS, it isn't about twitch reflexes, and being able to aim perfectly. My only real complaint about Metroid is that there's too much jumping. Which is really hard in a game where you can't see your feet.
Metroid is an exploration game that happens to involve shooting stuff, and the controls are designed around that. The jumping is pretty easy in the game as they tended to leave a comfortable margin of error on the jumps. The camera also tilts down as you jump, which helps a little too. You tend to learn the jumping pretty quickly though and only really have to think about it on the jumps that approach the limits of your jumping distance, which isn't often.
I'd like to hear Miyamoto's reasoning for suggesting a first-person viewpoint. He may have had some gameplay specific reasons as well, but my reason for liking first-person is mainly aesthetic.
The reasoning given at the time came down to every time you entered a new room, the first thing you'd do was switch to the first person view point and look around. You'd keep going back to that view as you looked for things of interest in the room. You ended up spending a lot of time in the first person view, so it made sense to make it all first person.
Actually they will talk fine as long as they were both opened at the same time (either both before or both after the upgrade).
That's exactly my point. The Unix way leaves a window where things might not work and just relies on the fact that most of the time there won't be a problem.
You aren't forced to reboot because you're giving up the guarantee that everything is correct.
Of course, that's why you need cp, rm, mv etc. statically linked, or you should have sash (statically linked, of course) installed. (Busybox may be the modern equivalent of sash, but I've never investigated it).
Good advice, but a lot of distros don't follow it. Just checked my Fedora box -/bin/cp is linked against 8 shared libraries.
command.com almost certainly is horribly written, but that doesn't mean that it wasn't a really good idea for it to have the core commands built in.
You cant understand it because you've never seen it being used.
Quite the contrary. I can't understand it because I've seen where it fails, and I've done enough system programming to be rather familiar with how horrible an idea it can be.
The only catch is that if you update something critical like Xorg then you cant start new applications once its updated because the new library cant talk to the old X server currently running.
That's exactly where the problems come in. Any kind of interprocess communication becomes a total crapshoot. Even though process X and process Y are both using/usr/lib/libfoox.y.so, you have no guarentee that the two libraries can talk to each other. Remember, the version number in an so file refers to the external API - it says nothing about the implementation of that API.
I don't get how anyone could consider this a bad idea. The only times it falls over is when people don't follow convention (change your library number when changing APIs!)
The problem isn't when APIs change, because as you said, the number should change. The problem is when the implementation of the API changes.
Anything internal to the library can change at any time, regardless of the library version number. This isn't a problem on self contained code, but leads to potential problems with programs that interact with each other. Say you have a database library that supports multiple processes accessing the same file. To implement this, the DB library has a series of locks on the file. Some realizes a potential locking problem, and reorders the calls to grab the locks to solve it. Now, you have a program running accessing the DB at the time you do the update. You now start another instance of the program. You have two instances running with different library versions. They're now performing different locking logic. You've just drastically increased the odds of data corruption and / or deadlocks.
It's because you only ever deal with pointers to files (inodes) and the inodes are what are cached when a file is open.
You don't deal with inodes directly. You deal with filenames, which internally get mapped to inodes. There's no reason the user / developer should ever have to know what an inode is. For whatever reason, the Unix developers decided to let it show through.
I consider it a friendly feature when you're debugging vital system libraries. The system stays alive and repairable even if you have just installed a bad libc.
Last time I did that (probably back in the 90's), any process already running worked, but I couldn't start any new processes. Remember, cp, rm, and mv are usually just programs in/bin, so if core libraries are hosed, you can't use them. I have to give credit to MS for being smart enough to make the corresponding commands built into command.com / cmd.exe.
You can always find out which instance of a library a running process is linked against anyway. No big deal.
You shouldn't ever have to do that. Shared code should always be shared identically between everything using it.
It's good because even if you have an unkillable process zombie'ing around your system, you can still replace a file, reboot, and have things work without having to actually go to single user mode and do things manually. It's important from a remote administration standpoint.
If you're going to reboot, then it loses all advantages you're trying to claim. Do it like Windows does - just have the system automatically make replace the files extremely early on in the boot process. Do it before the distinction between single / multiple user mode.
Does Windows gracefully handle the situation where a DLL which is currently in use is replaced, or will I wind up with applications calling two different versions of the DLL depending on when they started?
The reason Windows updates require reboots is because open files cannot be replaced. So if a DLL is in use at the time of update, it won't actually be installed until you reboot.
Unix systems, otoh, have decided that the name of a file (the thing the user has control over) is not what actually ids a file, but instead the location on disk is the id. Hence why Unix updates don't require reboots and instead result in the problems you've mentioned.
I've always wondered how someone could consider the Unix design a good idea. Two different programs can open what they think is the same file, yet get completely different results. And yet some people don't seem to get why this is a really bad thing for shared libraries (or even files in general).
Roman Catholic opposition to birth control is based on very strong religious reasons: they believe that sex is immoral, and should be engaged in only for creating more followers of the Church and even then should not be enjoyed.
Sorry, but you're completely wrong on that. The Roman Catholic church strongly encourages sex, but strictly within marriage. They actually emphasize it a lot during the marriage preparation stuff.
Metroid has always sold much better in the US and Europe than in Japan. FPS games aren't very popular in Japan. Hence, Metroid Prime isn't a big sell in Japan. I believe the first actually did decently there, at least relative to expectations.
The quality is ridiculous by today's standards (60dpi). It's readable, in the same way that simulated alphabetical text on a 7 segment LCD (pager) screen is readable, but dot matrix makes a typewriter (or Daisy wheel printer) look like fine art by comparison.
You must've had a bottom of the line dot-matrix printer. The better ones hit 360 dpi. Low end ones were around 150 dpi.
If you sent raw text to a dot-matrix, you usually got a so so quality font out of it. If you sent graphic data, you could get pretty good quality at the expense of much longer printing times.
Dot-matrix went out because they're seen as "old", they're NOISY, and the print quality pretty much sucks compared to anything out now.
Dot-matrix can get some really nice quality if you've got good software running. The bigger issue is people don't like dealing with the pinfeeds and jagged edges they leave behind. Or the fact that your paper isn't flat anymore after being printed on.
Maybe in some cases, but definitely not in all. If you check Intel press releases, you'll notice that when they reduce the process size, the first thing they make is flash memory.
Finance jobs also have long base hours, and tend to frequently expect you to put in extra time. The total dollar figure may be good, but it's not that great when you figure out your hourly pay.
I had a finance job once, but just couldn't take the way it took over my life completely. All the good programmers I know wouldn't even consider a finance job due to that.
Funny enough, my wife got my old computer (dual core 3600+ AMD, 2 gigs ram and ATI Radion XT1800), and I put a copy of vista on that machine and it works fine, but all she does on her computer is open the web browser and play solitaire. She has FAR from high end hardware, and she runs it in the high graphics desktop mode without a hickup.
As far as most people are concerned, that's a pretty high end system. The processor is towards the low end for current retail products, but the graphics card is pretty far up there, and 2 gigs of RAM is certainly on the high end. That computer is much better than the average system at Best Buy. Microsoft wouldn't be able to sell Vista if a computer like that couldn't run it.
In February 2009, the FCC of the United States cuts off analog television broadcast, and Americans will make a run on the big box stores to buy spanking new televisions to watch the NCAA men's basketball tournament on. How many of those 3+ million PS3s will connected to HDTVs by the end of March 2009?
What do you think the odds are that the type of person who isn't willing to spend the money on cable or satellite TV is going to spend $500+ on an HDTV when they could instead spend $50 on a converter box? Don't forget the government subsidy on a converter box, making the cost as low as $10.
Also, how much of an intersection do you really see between the set of people with old TVs that don't spend any money on television service and the set of people who are early adopters for the PS3 ?
I don't think the emu10k stuff has any hardware midi. It just supports multiple sound channels in hardware, which avoids needing to do the final combining of the channels in software. It's still doing the resampling in software.
Timidity really isn't very efficient tho - my understanding is a straight port of it to the DS takes up enough CPU power to make it unrealistic to use in games, despite the DS having a 66MHz ARM9 and 16 hardware sound channels (and therefore no software mixing).
Slashdot Mirror
And no, Zelda was always called an action RPG, like secret of mana was. It was never an "adventure" game ever.
Zelda was only ever considered an RPG by the kind of gamer that usually only plays RPGs, but needs an excuse to justify liking Zelda.
If you check the old guides from when Nintendo used to publish large strategy guides that covered multiple games, Zelda was always in the Adventure section.
Zelda really doesn't count as an RPG unless you use such a broad definition of RPG that almost any game counts as an RPG. Collecting items to progress doesn't make something an RPG...
RTF is simply a version of .doc that's largely ASCII text. It's main purpose was to be a format that was easier for tools to parse. Windows Help files used to be based off it. You can still drop whatever random objects into it.
Perhaps PowerPC has some extra features to enable it, but on x84-64, you're not getting 64 bit anything unless the kernel is running in 64 bit mode.
As for the kernel not needing to access more than a couple gigs directly - how do you propose handling memory management past the 4 GB mark? Do you propose only allowing virtual memory (including memory mapped files) on the first 4 GB ?
There's no 64 bit Flash because your Flash code is compiled into native code at run time. The compiler needs to be rewritten to make it work. Open sourcing the code wouldn't magically fix that.
Actually, last time I checked modern 64-bit cpus could actually only address 2^40 bytes of Ram, because you couldn't physically attach that much ram to them. 2^39 starting at 0 and 2^39 at the other end of the 64-bit spectrum.
2^40 is the physical RAM limit. AMD didn't bother to connect more pins to the memory bus simply because it's going to be a long time before anyone tries to put that much RAM into a PC. Reduced the number of pins needed in the chip socket and cut costs.
I believe the virtual memory goes to 2^48. Not sure the logic on that one, but it was probably to cut down on the size of page tables. I'm sure it's also one of those things that when the time comes, they'll add a setting in newer chips to enable more bits.
There was active 68k code in the classic MacOS right up to the end. The end was over 10 years after they produced the final 68k Mac. That doesn't mean the system would run on 68k, but it does mean that Apple isn't afraid to support legacy code.
If you run in x86 chip in 64 bit mode, you still retain the ability to run 32 bit code. Your kernel has to be fully 64 bit, but it's a very minor issue to keep some things as 32 bit. They could very easily make an OS that requires a 64 bit CPU but yet have the majority of the code be 32 bit.
Mac Minis still shipping with 32 bit CPUs is the biggest reason for them to keep 32 bit alive.
An still, to this day, I don't understand why people like playing Goldeneye or any other console FPS. The control you get with the gamepad is about 1000 times worse then what you get with a keyboard and mouse to the point where I find it completely frustrating and, and am unable to play almost all console FPS games.
Keyboard and mouse offers great control when you master it. But it's a rather steep learning curve. WASD isn't intuitive at all - they aren't seperated at all from the rest of the keyboard and are positioned under the weak fingers of your weak hand. At least with a gamepad, your directional controls were actually intended for directional control.
The only exception is Metroid. This is because although it is a FPS, it isn't about twitch reflexes, and being able to aim perfectly. My only real complaint about Metroid is that there's too much jumping. Which is really hard in a game where you can't see your feet.
Metroid is an exploration game that happens to involve shooting stuff, and the controls are designed around that. The jumping is pretty easy in the game as they tended to leave a comfortable margin of error on the jumps. The camera also tilts down as you jump, which helps a little too. You tend to learn the jumping pretty quickly though and only really have to think about it on the jumps that approach the limits of your jumping distance, which isn't often.
I'd like to hear Miyamoto's reasoning for suggesting a first-person viewpoint. He may have had some gameplay specific reasons as well, but my reason for liking first-person is mainly aesthetic.
The reasoning given at the time came down to every time you entered a new room, the first thing you'd do was switch to the first person view point and look around. You'd keep going back to that view as you looked for things of interest in the room. You ended up spending a lot of time in the first person view, so it made sense to make it all first person.
Figuring out how to install Wine is far easier than getting it configured properly to run your apps.
Actually they will talk fine as long as they were both opened at the same time (either both before or both after the upgrade).
That's exactly my point. The Unix way leaves a window where things might not work and just relies on the fact that most of the time there won't be a problem.
You aren't forced to reboot because you're giving up the guarantee that everything is correct.
Of course, that's why you need cp, rm, mv etc. statically linked, or you should have sash (statically linked, of course) installed. (Busybox may be the modern equivalent of sash, but I've never investigated it).
/bin/cp is linked against 8 shared libraries.
Good advice, but a lot of distros don't follow it. Just checked my Fedora box -
command.com almost certainly is horribly written, but that doesn't mean that it wasn't a really good idea for it to have the core commands built in.
You cant understand it because you've never seen it being used.
/usr/lib/libfoox.y.so, you have no guarentee that the two libraries can talk to each other. Remember, the version number in an so file refers to the external API - it says nothing about the implementation of that API.
Quite the contrary. I can't understand it because I've seen where it fails, and I've done enough system programming to be rather familiar with how horrible an idea it can be.
The only catch is that if you update something critical like Xorg then you cant start new applications once its updated because the new library cant talk to the old X server currently running.
That's exactly where the problems come in. Any kind of interprocess communication becomes a total crapshoot. Even though process X and process Y are both using
I don't get how anyone could consider this a bad idea. The only times it falls over is when people don't follow convention (change your library number when changing APIs!)
The problem isn't when APIs change, because as you said, the number should change. The problem is when the implementation of the API changes.
Anything internal to the library can change at any time, regardless of the library version number. This isn't a problem on self contained code, but leads to potential problems with programs that interact with each other. Say you have a database library that supports multiple processes accessing the same file. To implement this, the DB library has a series of locks on the file. Some realizes a potential locking problem, and reorders the calls to grab the locks to solve it. Now, you have a program running accessing the DB at the time you do the update. You now start another instance of the program. You have two instances running with different library versions. They're now performing different locking logic. You've just drastically increased the odds of data corruption and / or deadlocks.
It's because you only ever deal with pointers to files (inodes) and the inodes are what are cached when a file is open.
/bin, so if core libraries are hosed, you can't use them. I have to give credit to MS for being smart enough to make the corresponding commands built into command.com / cmd.exe.
You don't deal with inodes directly. You deal with filenames, which internally get mapped to inodes. There's no reason the user / developer should ever have to know what an inode is. For whatever reason, the Unix developers decided to let it show through.
I consider it a friendly feature when you're debugging vital system libraries. The system stays alive and repairable even if you have just installed a bad libc.
Last time I did that (probably back in the 90's), any process already running worked, but I couldn't start any new processes. Remember, cp, rm, and mv are usually just programs in
You can always find out which instance of a library a running process is linked against anyway. No big deal.
You shouldn't ever have to do that. Shared code should always be shared identically between everything using it.
It's good because even if you have an unkillable process zombie'ing around your system, you can still replace a file, reboot, and have things work without having to actually go to single user mode and do things manually. It's important from a remote administration standpoint.
If you're going to reboot, then it loses all advantages you're trying to claim. Do it like Windows does - just have the system automatically make replace the files extremely early on in the boot process. Do it before the distinction between single / multiple user mode.
Does Windows gracefully handle the situation where a DLL which is currently in use is replaced, or will I wind up with applications calling two different versions of the DLL depending on when they started?
The reason Windows updates require reboots is because open files cannot be replaced. So if a DLL is in use at the time of update, it won't actually be installed until you reboot.
Unix systems, otoh, have decided that the name of a file (the thing the user has control over) is not what actually ids a file, but instead the location on disk is the id. Hence why Unix updates don't require reboots and instead result in the problems you've mentioned.
I've always wondered how someone could consider the Unix design a good idea. Two different programs can open what they think is the same file, yet get completely different results. And yet some people don't seem to get why this is a really bad thing for shared libraries (or even files in general).
Roman Catholic opposition to birth control is based on very strong religious reasons: they believe that sex is immoral, and should be engaged in only for creating more followers of the Church and even then should not be enjoyed.
Sorry, but you're completely wrong on that. The Roman Catholic church strongly encourages sex, but strictly within marriage. They actually emphasize it a lot during the marriage preparation stuff.
Metroid has always sold much better in the US and Europe than in Japan. FPS games aren't very popular in Japan. Hence, Metroid Prime isn't a big sell in Japan. I believe the first actually did decently there, at least relative to expectations.
The quality is ridiculous by today's standards (60dpi). It's readable, in the same way that simulated alphabetical text on a 7 segment LCD (pager) screen is readable, but dot matrix makes a typewriter (or Daisy wheel printer) look like fine art by comparison.
You must've had a bottom of the line dot-matrix printer. The better ones hit 360 dpi. Low end ones were around 150 dpi.
If you sent raw text to a dot-matrix, you usually got a so so quality font out of it. If you sent graphic data, you could get pretty good quality at the expense of much longer printing times.
Dot-matrix went out because they're seen as "old", they're NOISY, and the print quality pretty much sucks compared to anything out now.
Dot-matrix can get some really nice quality if you've got good software running. The bigger issue is people don't like dealing with the pinfeeds and jagged edges they leave behind. Or the fact that your paper isn't flat anymore after being printed on.
Perhaps SDRAM is made in newer fabs.
Maybe in some cases, but definitely not in all. If you check Intel press releases, you'll notice that when they reduce the process size, the first thing they make is flash memory.
Finance jobs also have long base hours, and tend to frequently expect you to put in extra time. The total dollar figure may be good, but it's not that great when you figure out your hourly pay.
I had a finance job once, but just couldn't take the way it took over my life completely. All the good programmers I know wouldn't even consider a finance job due to that.
Funny enough, my wife got my old computer (dual core 3600+ AMD, 2 gigs ram and ATI Radion XT1800), and I put a copy of vista on that machine and it works fine, but all she does on her computer is open the web browser and play solitaire. She has FAR from high end hardware, and she runs it in the high graphics desktop mode without a hickup.
As far as most people are concerned, that's a pretty high end system. The processor is towards the low end for current retail products, but the graphics card is pretty far up there, and 2 gigs of RAM is certainly on the high end. That computer is much better than the average system at Best Buy. Microsoft wouldn't be able to sell Vista if a computer like that couldn't run it.
In February 2009, the FCC of the United States cuts off analog television broadcast, and Americans will make a run on the big box stores to buy spanking new televisions to watch the NCAA men's basketball tournament on. How many of those 3+ million PS3s will connected to HDTVs by the end of March 2009?
What do you think the odds are that the type of person who isn't willing to spend the money on cable or satellite TV is going to spend $500+ on an HDTV when they could instead spend $50 on a converter box? Don't forget the government subsidy on a converter box, making the cost as low as $10.
Also, how much of an intersection do you really see between the set of people with old TVs that don't spend any money on television service and the set of people who are early adopters for the PS3 ?
I don't think the emu10k stuff has any hardware midi. It just supports multiple sound channels in hardware, which avoids needing to do the final combining of the channels in software. It's still doing the resampling in software.
Timidity really isn't very efficient tho - my understanding is a straight port of it to the DS takes up enough CPU power to make it unrealistic to use in games, despite the DS having a 66MHz ARM9 and 16 hardware sound channels (and therefore no software mixing).