Well, the Playstation 1 does run a small OS, it uses the first 64K of RAM, but it doesn't do much. I didn't spend much time with the Playstation 2 but it probably does something similar.
The jazz of which you speak is just an application which gets copied from ROM by a small bit of code at boot-up time. The only thing done before running it is hardware initialisation.
It's not an OS at all, it's just an application, that's the bottom line.
It's only a couple of weeks, sure, but when it takes you from being a few days in front of Microsoft, to over a week behind, well that is significant.
Only time will tell if it will be disastrous. Maybe Xbox will slip too. Who knows?
Given that Mario Kart 64 was pants, I don't know if extrapolating from that particular data point is a good idea. Super Mario Kart on the SNES, yes, awesome game.
Within a year of release? OK you're on. My pound to your dollar.
You're all half right.
* They use the USB protocol
* They're a different shape (so you don't completely f**k the console up when you trip over the lead... Everyone trips over the leads...)
* They use a higher voltage (to run the rumble motors)
Interestingly, J Allard was saying that one of the reasons the controller is so large & heavy is because during testing, they found that it made the rumble feel much better.
Hey, I never said anything was perfect. Yes, it ties you to Win32 platforms. That's the kind of tradeoff we make all the time as game programmers. You should know that. I was just pointing out that Microsoft themselves realised that DirectPlay was rubbish, and they rewrote it completely for version 8, solving many of the problems that you and others were complaining about.
I guess if there was a good cross platform alternative, then maybe people would use that, but AFAIK there is not. Using sockets directly is not a direct alternative to DirectPlay, it's a direct invitation to a world of pain. You should know how much work is involved to get stuff not just working, but working robustly. Would you wish that on every developer?
I'm a lemming? Haha! "Oh no!"
Peace.
No, the signals you talk about are simply strings of bits, fundamentally. Yes, a certain combination of three consecutive bases means "stop". But that idea is not itself embedded in the DNA. It's held in the DNA reader. That was my whole point. DNA does not contain metadata, it is just data. A "stop" code is just as much data as a "make this amino acid" code. Metadata is by definition something about the data. You could put it in the same "stream" but you don't have to, and it often doesn't make sense to do so.
a well-designed app shoudl let the user attempt to open any file. It shoudl try and interpret the data correctly
Isn't this the whole point though? Data is (are?) just data. It doesn't mean anything unless you know how to interpret it. It's like DNA. DNA is just a bunch of data. It doesn't contain anything saying "I'm DNA" or "Read me like this". That information is external to the data itself (themselves?:)
Even on top of that, once you get to the file data, often there are multiple subtypes within it. For example, RIFF files are composed of chunks, each containing different types of data. As long as we consider files to be monolithic, opaque blobs, we're restricting ourselves.
XML is... A discussion for another day...
Yes, I know. I'm just saying it's not a good general solution to the problem (although it's not a bad idea at all as a last resort, instead of just giving up).
Well you say it works for you, so I guess I shouldn't disagree with you. But IMHO it's not a good way to do things. A given program should be able to determine if a given file is of its own type. However, when you're given a file and you have to determine which of a thousand applications it belongs to, that's a whole world of pain. If everyone agreed to put something in the same place in every file, say at the beginning, then it could work. But, it would be ugly, and... Hey, if it's in the same place for every file, why not just take it out of the file and associate it instead? Nautilus may well be able to determine file types, but it's not going to be efficient at it. For example if you throw it a big directory full of stuff it's going to have to scan arbitrary amounts of those files to work out what type they are, and I bet it's not 100% accurate either.
Well, I feel kind of in the middle, because I had thought about it before (but not recently) but I still thought it was interesting.
If I might address your second point, the author did go to some trouble to stress that policies are distinct from the metadata itself. Opening an HTML document as binary doesn't change the fact that it's an HTML document.
I liked this article, it was thought provoking. It reminded me of the Archimedes, with its 16 bit file types, and the Mac. Oh, the dear Mac. How many times did I scream at it, "yes you will bloody open that file!"... While it sits there all like, "No I bloody will not, it's the wrong type, I'm not even looking at it!"...
Hang on a minute though. It's a bit much to have a go at Microsoft about file extensions. Unix? Written in C?.c and.h files? What would happen if you didn't have extensions?
Anyway. Personally I get all excited by the idea of accessing files more as a database action. I know there are people that hate the idea.
Interestingly, NTFS allows you to hang arbitrary stuff off a file. It's also a good way to hide stuff, because almost no-one knows about it. Oh, well.
That's like saying TCP provides nothing over IP. Which is rubbish. Of course DirectPlay provides value, thats what it's there for.
Also, socket programming is not going to help you connect via IPX, modems or serial connections.
Please don't dis things you don't understand.
Wow, you're so wrong. No existing console has OpenGL as its native graphics API. I guess the Indrema would have, but we can forget about that now... OpenGL like libraries have been written for various consoles, but most people prefer to talk to the native APIs.
The N64 has an OpenGL-like API, but it's not OpenGL. The PSOne and PS2 don't really have graphics APIs, there are a few calls to tweak the video hardware, but you basically have to generate your own hardware display lists.
The Dreamcast's native API is called KAMUI, which is nothing like OpenGL (the PowerVR chipset never was very OpenGL friendly). It also runs DirectX 6 if you go with the WindowsCE option.
3D Studio MAX can also use Direct3D.
80 bits, not 80 digits. The x87 supports three formats: 32 bits, 64 bits, and 80 bits. All internal processing is done with 80 bits, but it's rounded when it's stored out as a float or double.
Some operations always give an 80 bit result (eg. adds & muls) but some (eg. divides) can be limited by the current precision setting.
floats have 23 bits of mantissa, 7 digits precision.
doubles have 52 bits of mantissa, 15 digits precision.
80 bit "long doubles" have 64 bits of mantissa, 19 digits precision.
Slashdot Mirror
Might "backfire" though... Boom Boom.
The NA 2.0L would (all other things being equal) be more reliable...
Yeah, well he is Miyamoto! Anyway, what's better? -dono? Or just plain -san?
Isn't "Shigeru-kun" a little familiar? Seems to me "Miyamoto-sama" would be more appropriate.
Me? Oh, definitely not. I guess I should dig it out again one of these days though.
Well, the Playstation 1 does run a small OS, it uses the first 64K of RAM, but it doesn't do much. I didn't spend much time with the Playstation 2 but it probably does something similar.
The jazz of which you speak is just an application which gets copied from ROM by a small bit of code at boot-up time. The only thing done before running it is hardware initialisation.
It's not an OS at all, it's just an application, that's the bottom line.
Whoa. You're wierd.
So, what, you're saying it's better than Super Mario Kart?
It's only a couple of weeks, sure, but when it takes you from being a few days in front of Microsoft, to over a week behind, well that is significant.
Only time will tell if it will be disastrous. Maybe Xbox will slip too. Who knows?
Given that Mario Kart 64 was pants, I don't know if extrapolating from that particular data point is a good idea. Super Mario Kart on the SNES, yes, awesome game.
Within a year of release? OK you're on. My pound to your dollar.
If I Recall Correctly
Or Remember, i guess.
You're all half right.
* They use the USB protocol
* They're a different shape (so you don't completely f**k the console up when you trip over the lead... Everyone trips over the leads...)
* They use a higher voltage (to run the rumble motors)
Interestingly, J Allard was saying that one of the reasons the controller is so large & heavy is because during testing, they found that it made the rumble feel much better.
Hey, I never said anything was perfect. Yes, it ties you to Win32 platforms. That's the kind of tradeoff we make all the time as game programmers. You should know that. I was just pointing out that Microsoft themselves realised that DirectPlay was rubbish, and they rewrote it completely for version 8, solving many of the problems that you and others were complaining about.
I guess if there was a good cross platform alternative, then maybe people would use that, but AFAIK there is not. Using sockets directly is not a direct alternative to DirectPlay, it's a direct invitation to a world of pain. You should know how much work is involved to get stuff not just working, but working robustly. Would you wish that on every developer?
I'm a lemming? Haha! "Oh no!"
Peace.
No, the signals you talk about are simply strings of bits, fundamentally. Yes, a certain combination of three consecutive bases means "stop". But that idea is not itself embedded in the DNA. It's held in the DNA reader. That was my whole point. DNA does not contain metadata, it is just data. A "stop" code is just as much data as a "make this amino acid" code. Metadata is by definition something about the data. You could put it in the same "stream" but you don't have to, and it often doesn't make sense to do so.
Hmm. What type is Courtney?
a well-designed app shoudl let the user attempt to open any file. It shoudl try and interpret the data correctly
:)
Isn't this the whole point though? Data is (are?) just data. It doesn't mean anything unless you know how to interpret it. It's like DNA. DNA is just a bunch of data. It doesn't contain anything saying "I'm DNA" or "Read me like this". That information is external to the data itself (themselves?
Even on top of that, once you get to the file data, often there are multiple subtypes within it. For example, RIFF files are composed of chunks, each containing different types of data. As long as we consider files to be monolithic, opaque blobs, we're restricting ourselves.
XML is... A discussion for another day...
Yes, I know. I'm just saying it's not a good general solution to the problem (although it's not a bad idea at all as a last resort, instead of just giving up).
Well you say it works for you, so I guess I shouldn't disagree with you. But IMHO it's not a good way to do things. A given program should be able to determine if a given file is of its own type. However, when you're given a file and you have to determine which of a thousand applications it belongs to, that's a whole world of pain. If everyone agreed to put something in the same place in every file, say at the beginning, then it could work. But, it would be ugly, and... Hey, if it's in the same place for every file, why not just take it out of the file and associate it instead? Nautilus may well be able to determine file types, but it's not going to be efficient at it. For example if you throw it a big directory full of stuff it's going to have to scan arbitrary amounts of those files to work out what type they are, and I bet it's not 100% accurate either.
Well, I feel kind of in the middle, because I had thought about it before (but not recently) but I still thought it was interesting.
If I might address your second point, the author did go to some trouble to stress that policies are distinct from the metadata itself. Opening an HTML document as binary doesn't change the fact that it's an HTML document.
I liked this article, it was thought provoking. It reminded me of the Archimedes, with its 16 bit file types, and the Mac. Oh, the dear Mac. How many times did I scream at it, "yes you will bloody open that file!"... While it sits there all like, "No I bloody will not, it's the wrong type, I'm not even looking at it!"... .c and .h files? What would happen if you didn't have extensions?
Hang on a minute though. It's a bit much to have a go at Microsoft about file extensions. Unix? Written in C?
Anyway. Personally I get all excited by the idea of accessing files more as a database action. I know there are people that hate the idea.
Interestingly, NTFS allows you to hang arbitrary stuff off a file. It's also a good way to hide stuff, because almost no-one knows about it. Oh, well.
That's like saying TCP provides nothing over IP. Which is rubbish. Of course DirectPlay provides value, thats what it's there for.
Also, socket programming is not going to help you connect via IPX, modems or serial connections.
Please don't dis things you don't understand.
Wow, you're so wrong. No existing console has OpenGL as its native graphics API. I guess the Indrema would have, but we can forget about that now... OpenGL like libraries have been written for various consoles, but most people prefer to talk to the native APIs.
The N64 has an OpenGL-like API, but it's not OpenGL. The PSOne and PS2 don't really have graphics APIs, there are a few calls to tweak the video hardware, but you basically have to generate your own hardware display lists.
The Dreamcast's native API is called KAMUI, which is nothing like OpenGL (the PowerVR chipset never was very OpenGL friendly). It also runs DirectX 6 if you go with the WindowsCE option.
3D Studio MAX can also use Direct3D.
No, it does not. It uses a faintly similar API, but it is not OpenGL.
All fixed in DirectPlay 8. Do try to keep up.
Yawn.
Microsoft are not a monopoly in the games console market. They're about to try to break into it for the first time.
80 bits, not 80 digits. The x87 supports three formats: 32 bits, 64 bits, and 80 bits. All internal processing is done with 80 bits, but it's rounded when it's stored out as a float or double.
Some operations always give an 80 bit result (eg. adds & muls) but some (eg. divides) can be limited by the current precision setting.
floats have 23 bits of mantissa, 7 digits precision.
doubles have 52 bits of mantissa, 15 digits precision.
80 bit "long doubles" have 64 bits of mantissa, 19 digits precision.