a) That's not Java 3D, nor is it part of the Java 3D spec; it's a library built on Java 3D
And that's a problem because... ?
b) It's licensed as GPL; you might as well develop a computer graphics training class based upon proprietary software
That's a fair enough point, though it *is* more than sufficient for the presented purposes of teaching. It's not like a serious 3D developer is going to do his work in Java3D. While you *can* do this, you'll have to work around a number of its shortcomings. A much better idea is to look into working directly with OpenGL through JOGL, or look into one of the many other scenegraphs available for Java.
infer from context/documentation that *some* signed values are actually unsigned values in disguise
Well, yeah. If the documentation says, "This method expects a bit-packed value in ARGB format" you had better pass it a value in ARGB format. That's true whether you're working in Java or C/C++. I pity the fool who doesn't read his documentation.
for such values, use bit shift instead of arithmetic shift
Killer isn't it? Adding that extra > sign.
for such values, manually translate them if they are printed incorrectly on the console or in a debugger
I don't know about you, but I like to see my bit-packed values in Hexadecimal. It's a heck of a lot easier to read than decimal. And what'dya'know? Java just happens to have a library for printing unsigned hexadecimal values.
you will have to devise your own strange and complicated ways to detect overflow
Um, okaaaay. Would you like to explain to the class which overflow-detection scheme you can use in C/C++ that you can't use in Java? Remember, you've got the same bits in that 32-bit value. So unless you've got assembly hooks back to the processor to give you a heads up, I don't see how you could have a test in C that won't work in Java.
you will not be able to assign literal values outside the signed range of the data type (short x = 65535 does not compile)
First off, you're a very bad boy for using the decimal value 65535 when your real intent is obviously to fill all 16 bits with 1's. You should be using 0xFFFF for clarity instead. Secondly, the compiler thinks you're a bad boy for assigning an integer value to a short. You should have done this:
short x = (short)65535;
(Actually, you should have done "short x = (short)0xFFFF", but one point at a time.)
Thirdly, why are you doing such a thing? Java extends all bytes and shorts to integers for operations. This is a feature that gets around problems caused by newbs screwing up byte alignment with pointless attempts at saving memory. Your processor is a 32-bit computational machine. It's poor form (and poor performance) to make it pretend to be a 16-bit machine.
Types will be converted incorrectly, as demonstrated in the following program:
Oh noes! Casting rules!
As in, the rules you read when you learn how to program the language. Unsurprisingly, casts are signed. So if you don't want to cast a number (which you should never, ever, ever be doing with a bit-packed number anyway) you should be doing bitwise casts on them:
x = (0xFFFF & y);
See above for further ranting about why you are using a short for working storage rather than an integer.
Our esteemed anonymous representative was trying to say that their method renders an antialiased scene by nature of the algorithm, not because an antialiasing routine was applied. In theory, this differs from traditional methods in that it makes the renderer simpler and takes fewer computations to achieve the desired result.
In reality, the possibility exists that their claims could be overblown as there are a variety of anti-aliasing routines for 3D rendering. They may be advertising the direct computation of anti-aliasing information over the downscaling methods. (e.g. anisotropic filtering and supersampling) It's hard to say without reading up on the rendering method they're using.
the JPEG library I was using for image recognition in my univeristy robotics class didn't support multidimensional arrays for accessing pixels.
That would be the specific library, not Java. Java has multidimensional arrays, though they are actually arrays within arrays. (ad infinitum)
So if you want the to access pixel i in row j of an image that's x * y pixels, you'd have to use image[j*x + i] (or something like that).
That is generally the fastest way to access image data. I don't know about you, but I've been using the formula (y * width + x) since before Java was even invented. (Actually, it was usually a high-performance variation that derived from the formula, but it was the same basic concept.) The formula is, and please take this with the utmost respect, an absolute requirement for anyone doing intricate graphics work.
FWIW, most programmers today never have to dive down to such a level. C/C++, Java, C#, Language of Choice(TM) all have libraries that abstract away low-level graphics operations. So unless you are writing a graphics library, you shouldn't need to deal with such things any longer.
Of course, in your case you were doing low-level graphics operations. If I were to hazard a guess, you were using the AWT Toolkit to load a JPG image, which you then extracted the pixel information from using a MemoryImageConsumer. (IIRC) Primitive stuff, intended for Applets. The BufferedImage and ImageIO libraries are much more useful these days.
That's because you're specifying a 32-bit int value for an 8-bit byte variable. Try this instead:
byte a = (byte)0xFF;
This program will print out the correct result of -1:
public class TestSign {
public static void main(String[] args)
{
byte a = (byte)0xFF;
System.out.println("Byte = "+a);
} }
If you want to upconvert it to an int, don't cast it. Casting is a sign extended operation. Instead, you can OR the value. e.g.:
byte rgb = 0xFF0000;//Red byte a = (byte)0xFF;
rgb |= a;//Purple
Java makes you work a bit more at it, but it's nothing major. In most circumstances you *should* be using bitwise operations anyway. There are very few situations where you need to add an unsigned byte to a signed integer. (Most of them caused by a false sense of optimization or memory economy.) In those cases you use a (0xFF & a) operation to cast the byte without sign extending it.
I've always been under the Impression that Java can't use hardware rendering, wouldn't that restrict usage for more intense applications?
Java 1.4 added support for a direct-rendering scheme similar to DirectDraw. The primary difference is that surfaces are managed automatically by the JVM rather than being explicitly locked and unlocked.
JOGL introduced an official add-on for OpenGL support in Java, and was standardized under JSR-231. Several Java-based scenegraphs appeared shortly thereafter. The most popular are Xith3D and jMonkeyEngine.
Java3D has been an official add-on since about '98 (IIRC), but it was less useful because it hid access to OpenGL behind its scenegraph. As a result, it was discontinued shortly after the introduction of JOGL, only to be brought back as a Sun Open Source Project. It now supports the JOGL/JSR-231 standard.
And before anyone marks this as a troll, C# supports unsigned values. Java does not. Since RGB color spaces are frequently represented as unsigned values between 0 and the maximum word size (usually 8-bit) this makes working with computer graphics in Java either a giant pain in the ass, or a word size larger than the permitted range. (For example, using shorts instead of bytes.)
Do you even understand how signed values work? Signed and unsigned are the exact same thing, save for two major exceptions:
1. Sign-preserving operations. The only one I can think of off the top of my head is a signed right shift. (>>) Use a bitwise shift instead. (>>>)
2. When the result of computations are printed out. An unsigned value is printed as a larger positive number while a signed value is given a negative sign and inverted if the first bit is a 1, before being printed out.
Java has a very sophisticated graphics library. (see: java.awt.image.BufferedImage) It uses 32-bit ARGB values. Somehow, the sign doesn't seem to cause a problem.:-/
I also agreed the question of who makes a "copy" when you download is a closer question, so I made it simple, citing the case of making a second personal copy for your second computer, and you agreed that the GPL license was required for that personal/user situation.
Yes, because US law is stupidly simple on this point. If a file is downloadable on a website, who made the file available? Presumably, the website owner. Therefore he is giving you a right to a copy. Who transferred a secondary copy from the desktop to the laptop? Presumably, the owner of the computers. Who is on the hook in that situation? The owner of the machines.
Illegal downloading never enters into this argument. It's neither here nor there. GPL software has an initial distribution mechanism that is independent of the GPL. You can purchase a copy for download or on physical media, or you can download a copy for free. Doesn't matter. You don't need the GPL to own that initial copy.
There is no license anywhere in that file, nor on the homepage. Now tell me, what are your rights to that file?
You then returned to the issue of whether downloading is copying, so I gave the example of illegal downloading. You are violating copyright law when you illegally download, and the reason you are violating copyright law is because the act of downloading involves making a copy.
No, you are NOT violating copyright law because you made a copy. You are violating the law because you are knowingly obtaining a copy from someone who does not have the rights to offer you that copy.
A legitimate defense is that any reasonable person under the circumstances of illegal distribution would have thought that the distribution was legal. (Which I believe was a defense used by a few surprised KaZaa users who had paid fees to KaZaa's parent company for the P2P software; but that may have been an invention of Wired's Michelle Delio. Very annoying when journalists don't provide sources.) If that defense breaks down, however, then the law treats the situation in a manner similar to that of knowingly receiving stolen goods. Basically, you knew about the infringement, therefore you are also guilty of the infringement.
Now will you please get this ridiculous idea out of your head that you need the GPL to download software? As I've been repeatedly stating, the GPL's language is very clear that it is predicated on the idea of NOT taking effect when the software is downloaded.
Considering that both the Wii and the DS are smash hits at the moment, I'd say that Nintendo is a "Two Trick Pony". Unless you count the continuing success of the Gameboy Advance. In which case Nintendo is a three trick pony. That is, unless you also count their unrivaled success with the Super Nintendo. In which case they're a four trick pony. Oh, but what about the original Gameboy? Make that a five trick pony. Six if you count the market-reviving, competition-stomping powerhouse that was the NES. Oh, but what about the games?!? Donkey Kong, Super Mario Bros., Mario 3, Zelda, Metroid, Starfox, DK:Country, Mario Kart, Link to the Past, FZero, Mario 64, Starfox 64, Ocarina of Time, FZero X, Metroid Prime-- oh to hell with it. I'll just give you a grand total.
By my count, Nintendo is a 3,421,978 trick pony.
I can certainly see your point. By my count Sony has innovated much more than Nintendo with a grand total of... erm... two tricks. 1.5 if you believe in Sony's (rather confusingly put) "more than 10 years" philosophy of console design.
Yeah, it was pretty common back in the days of floppy disks. It doesn't surprise me that a few companies extended the practice to early CD games. Unfortunately, the console folks tend to think of their media as indestructible for some reason or another. That was more or less true back in the days of cartridges, but it's sure as heck isn't true with optical discs.
Yet Nintendo still prints their "backups are not necessary nor authorized" warning in the manuals. (I imagine that the other console makers print something similar.) That's great. Tell it to a used copy of FZero GX I got that had no visible damage to the disc yet wouldn't function in a Gamecube or Wii.
A simple replacement program would do worlds of good. e.g. The ability to trade in the disk + a small processing fee (say, $5) for a new copy of just the optical disc. This wouldn't be all that different from vehicle extended warranties, which are intended to insure the life of your vehicle beyond the manufacturer's warranty.
This is a bit different. It's a way to convince the OS to give you more time slices than you'd normally be allocated. e.g. If you ran that program of yours twice at the same priority level, both instances should get ~50% of the CPU time. If one of the instances implemented this privilege boosting scheme however, it would get to hog all the CPU time while your other spinlocked program starved.
Whoa. Someone else who likes that shooter. Didn't expect to see that here.:-)
Have you seen how much the Gamecube version of that game goes for these days? I've seen incredible prices on Amazon, well over $100 a piece. eBay isn't much better with used copies going for about $50. I can't help but think that Atari was a victim of bad timing. If they re-released it now, it would be a much greater success than it was back in 2003.
To say that copyright law doesn't track copies is an odd view of the law. You almost seem to be arguing that only a distributor can engage in "copying." That's not the law.
For the umpteenth time, the law explicitly provides for certain forms of copying. Your previous examples of loading a copy on the hard drive and RAM (which is what I was responding to) do not apply.
Section 117, Paragraph (a) of United States Code:
(a) Making of Additional Copy or Adaptation by Owner of Copy. -- Notwithstanding the provisions of section 106, it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:
(1) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner, or
(2) that such new copy or adaptation is for archival purposes only and that all archival copies are destroyed in the event that continued possession of the computer program should cease to be rightful.
Read it, reread it, and read it again until it makes sense.
If Bob used P2P or an illegal FTP site to download an unauthorized copy of software do you think that what Bob did was legal because he did not engage in "copying"?
Sir, this is a dictionary perfect example of a "strawman argument". I would request that you cease such nonsensical arguments immediately, and please pay attention to what is actually being said.
We agree that it's not needed in the U.S. if you already own a copy and just want to run it. You agreed it's needed if you want to install it on your 2nd computer.
I'll be honest with you, you're not making any sense at all. If you agree with these things, then why continue to invent scenarios for the GPL to kick in in which the GPL does NOT kick in?
I can't tell if you agree the GPL is required to modify the software (it is).
I was actually quite clear on the circumstances regarding modification:
You can probably [modify the software] without invoking the terms of the GPL, simply because the copy is your personal property. (See: http://www.gnu.org/licenses/gpl-faq.html#InternalD istribution [gnu.org] for an example situation.)
To add to that, any modifications you do that you don't share are effectively a no-op. Since no one ever sees them, there is no way for the terms of the GPL to apply.
In standard copyright parlance, modification of a computer program is an act of creating a derivative work. Now the copyright laws specifically state in Section 103 that only the owner of a copyright can prepare a derivative work. However, Section 107 explicitly curbs those rights per "fair use". Here's the section in its entirety:
Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phonorecords or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright. In determining whether the use made of a work in any particular case is a fair use the factors to be considered shall include-- (1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes; (2) the nature of the copyrighted work; (3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and (4) the effect of the use upon the potential market for or value of the copyrighted work. The fact that a work is unpublished shall
I never really thought the atari port of pac-man was that bad. Considering the tech they had to work with, it was actually pretty good. Defender was much the same way.
Now tell me, was it really so impossible to make a Pac Man with the right maze and a character that turned his head, or a Defender in which the ship disappeared every time you fired?
I've programmed for the 2600. Its limitations are not what most people think they are. Travesties like PacMan and Defender only happened because a) Atari was churning its employees due to poor treatment and b) Atari never gave anyone enough time to do a really good job on a game.
The funny part is that third party titles regularly exceeded the graphics of Atari's games. The only problem is that very few third parties knew how to make a fun game.:-/
ET really did get a bum rap. I know that it is everyone's favorite game to dislike, but the game wasn't as bad as everyone remembers it. A more sensible argument was that it missed the target market of action-game players that Atari had cultivated. Pushing an adventure game on them was probably a mistake, though it would have been less so if HSW had had a bit more time to tweak the gameplay. (Mostly to prevent you from falling in holes.)
Since E.T. was released right around the same time as the crash, its has been widely attributed as being the cause of the crash. I find this bit of urban mythology to be doubtful as E.T. didn't do nearly as bad as Pacman. (Relatively speaking.) In fact, many of the legends (e.g. there were more carts than consoles) were actually swiped from the story of Pacman and falsely applied to E.T.
While I'll agree that Atari wasn't exactly brimming with quality themselves, the market generally ignored their crud. Kids from the 80's don't even remember how bad Pacman or Defender were. They just remember that it was cool to have these games on a home console. (They were a surprisingly forgiving bunch!) However, Atari's quality snafus were nothing compared to the flood of garbage pouring out of US Games (a division of Quaker Oats!), Apollo, Xonox, Mythicon, Spectravision, Data Age, and Froggo. (Just to name a few.)
Your comments are a bit strange, but I'll take them on one by one:
You're saying that console makers won't impose extreme demands on third parties?
Eh? I believe I said the exact opposite. The market crashed because Atari didn't impose licensing restrictions. Today's console makers impose licensing restrictions to prevent that issue.
Have you seen how many homebrew games exist now on modded consoles/handhelds?
Have you seen many of them for sale in Walmart? The market crashed because of a glut of titles on the market. Not because people were modding their consoles so they could exchange homemade games with each other.
The only modern console I've ever seen commercial homebrew software for is the Dreamcast. And homebrewers only get away with it because Sega doesn't care anymore. The Dreamcast is dead to them.
There are commercial kits for modding and/or homebrewing, but that doesn't change the commercial market for games.
I was just thinking that there were SO many games coming out I couldn't possibly play all the ones I've pre-ordered for any decent length of time, let alone all the ones I want to. I'd say we've got too many developers again.
That doesn't matter. With nearly 200 million consoles strong, there are enough people who would buy these games to make them viable. Sales of over one million copies is still considered a success. Especially for the more casually-targeted games.
Yeah, Nintendo hasn't way underpriced anyone lately. There's no way there'd be a price war again... Wait, who was lowering their prices again?
Ok, this one seems to have gone right past you. The price war was between Commodore and Texas Instrument computers. It was engineered by Tramiel to remove the price difference between computers and consoles. It was also timed to make computers dominant when consoles were at their lowest point. The gambit not only succeeded, but computers managed to fully replace consoles for a period of about 5 years.
Nintendo, Sony, and Microsoft can have a price war all they want. It won't replicate the situation that caused the console crash.
The PS2 was the only console in the households because it had far and away the best games of the era.
I don't think we really disagree. My point is that the PS2 got it start from being a cheap DVD player. Which catapulted it into the role of a casual gaming machine. Which has become a self-perpetuating engine of sales thanks to the large library of casual games.
The point in history I'm discussing is specifically the chicken and the egg solution that the PS2 used. You can't sell consoles unless you have a large library of good games. And you can't get game creators to make good games unless there is a customer base of consoles to target. Sony solved this with a good launch followed by a price drop that made it a cheap DVD player. We don't even think about it now as DVD players are so cheap, but all those games ended up on the console because Sony managed to get the console in the hands of consumers.
What Sony seems to have underestimated with the PS3 is that:
1. Not many people want a BluRay player.
2. $600 may be a bargain in relative terms, but it's a lousy value in absolute terms. Consumers only care about the absolute terms.
Anyone remember the early 80's? The biggest contributor to the great video game crash of 83 was the over abundance of crap in the marketplace.
While you are correct, I think it's important to understand that the crash of '83 can't happen again. The factors that made it happen simply don't exist anymore. Those factors are:
Atari did not want to allow third party developers for their console. Third party developers sprang up anyway, and started chucking out whatever they could possibly sell. Since Atari had no licensing arrangements with these companies, there were no quality control checks in place. Today's console makers require licensing arrangements to prevent exactly this sort of problem. (And to make more money!)
Just before the crash, there was a general feeling that the gaming market was going to experience unlimited growth. This was not the case, and there ended up being more game producers than the market could reasonably handle. Gaming did experience quite a bit of growth, however, and the current market size sits at not-quite 200 million consoles. That's an incredibly large market.
The crash would have been nothing more than a slump if not for a man known as Jack Tramiel. He was determined to make his Commodore computers take over the gaming market. Thanks to a price war with Texas Instruments, he was able to smash the price barrier between consoles and computers at just the right time to put everyone else (both consoles and computers) out of business. (Or at least in a world of hurt.) Stores threw out all their console garbage and started carrying computers. Computers and consoles coexist at a similar price point today, but computer gaming has been largely deemphasized over the years.
Slashdot Mirror
And that's a problem because... ?
That's a fair enough point, though it *is* more than sufficient for the presented purposes of teaching. It's not like a serious 3D developer is going to do his work in Java3D. While you *can* do this, you'll have to work around a number of its shortcomings. A much better idea is to look into working directly with OpenGL through JOGL, or look into one of the many other scenegraphs available for Java.
Well, yeah. If the documentation says, "This method expects a bit-packed value in ARGB format" you had better pass it a value in ARGB format. That's true whether you're working in Java or C/C++. I pity the fool who doesn't read his documentation.
Killer isn't it? Adding that extra > sign.
I don't know about you, but I like to see my bit-packed values in Hexadecimal. It's a heck of a lot easier to read than decimal. And what'dya'know? Java just happens to have a library for printing unsigned hexadecimal values.
Um, okaaaay. Would you like to explain to the class which overflow-detection scheme you can use in C/C++ that you can't use in Java? Remember, you've got the same bits in that 32-bit value. So unless you've got assembly hooks back to the processor to give you a heads up, I don't see how you could have a test in C that won't work in Java.
First off, you're a very bad boy for using the decimal value 65535 when your real intent is obviously to fill all 16 bits with 1's. You should be using 0xFFFF for clarity instead. Secondly, the compiler thinks you're a bad boy for assigning an integer value to a short. You should have done this:
short x = (short)65535;
(Actually, you should have done "short x = (short)0xFFFF", but one point at a time.)
Thirdly, why are you doing such a thing? Java extends all bytes and shorts to integers for operations. This is a feature that gets around problems caused by newbs screwing up byte alignment with pointless attempts at saving memory. Your processor is a 32-bit computational machine. It's poor form (and poor performance) to make it pretend to be a 16-bit machine.
Oh noes! Casting rules!
As in, the rules you read when you learn how to program the language. Unsurprisingly, casts are signed. So if you don't want to cast a number (which you should never, ever, ever be doing with a bit-packed number anyway) you should be doing bitwise casts on them:
x = (0xFFFF & y);
See above for further ranting about why you are using a short for working storage rather than an integer.
Our esteemed anonymous representative was trying to say that their method renders an antialiased scene by nature of the algorithm, not because an antialiasing routine was applied. In theory, this differs from traditional methods in that it makes the renderer simpler and takes fewer computations to achieve the desired result.
In reality, the possibility exists that their claims could be overblown as there are a variety of anti-aliasing routines for 3D rendering. They may be advertising the direct computation of anti-aliasing information over the downscaling methods. (e.g. anisotropic filtering and supersampling) It's hard to say without reading up on the rendering method they're using.
That would be the specific library, not Java. Java has multidimensional arrays, though they are actually arrays within arrays. (ad infinitum)
That is generally the fastest way to access image data. I don't know about you, but I've been using the formula (y * width + x) since before Java was even invented. (Actually, it was usually a high-performance variation that derived from the formula, but it was the same basic concept.) The formula is, and please take this with the utmost respect, an absolute requirement for anyone doing intricate graphics work.
FWIW, most programmers today never have to dive down to such a level. C/C++, Java, C#, Language of Choice(TM) all have libraries that abstract away low-level graphics operations. So unless you are writing a graphics library, you shouldn't need to deal with such things any longer.
Of course, in your case you were doing low-level graphics operations. If I were to hazard a guess, you were using the AWT Toolkit to load a JPG image, which you then extracted the pixel information from using a MemoryImageConsumer. (IIRC) Primitive stuff, intended for Applets. The BufferedImage and ImageIO libraries are much more useful these days.
byte a = (byte)0xFF;
This program will print out the correct result of -1: If you want to upconvert it to an int, don't cast it. Casting is a sign extended operation. Instead, you can OR the value. e.g.:
byte rgb = 0xFF0000;
byte a = (byte)0xFF;
rgb |= a;
Java makes you work a bit more at it, but it's nothing major. In most circumstances you *should* be using bitwise operations anyway. There are very few situations where you need to add an unsigned byte to a signed integer. (Most of them caused by a false sense of optimization or memory economy.) In those cases you use a (0xFF & a) operation to cast the byte without sign extending it.
Could have fooled me.
Java 1.4 added support for a direct-rendering scheme similar to DirectDraw. The primary difference is that surfaces are managed automatically by the JVM rather than being explicitly locked and unlocked.
JOGL introduced an official add-on for OpenGL support in Java, and was standardized under JSR-231. Several Java-based scenegraphs appeared shortly thereafter. The most popular are Xith3D and jMonkeyEngine.
Java3D has been an official add-on since about '98 (IIRC), but it was less useful because it hid access to OpenGL behind its scenegraph. As a result, it was discontinued shortly after the introduction of JOGL, only to be brought back as a Sun Open Source Project. It now supports the JOGL/JSR-231 standard.
Does that answer your question?
Do you even understand how signed values work? Signed and unsigned are the exact same thing, save for two major exceptions:
1. Sign-preserving operations. The only one I can think of off the top of my head is a signed right shift. (>>) Use a bitwise shift instead. (>>>)
2. When the result of computations are printed out. An unsigned value is printed as a larger positive number while a signed value is given a negative sign and inverted if the first bit is a 1, before being printed out.
Java has a very sophisticated graphics library. (see: java.awt.image.BufferedImage) It uses 32-bit ARGB values. Somehow, the sign doesn't seem to cause a problem.
Yes, because US law is stupidly simple on this point. If a file is downloadable on a website, who made the file available? Presumably, the website owner. Therefore he is giving you a right to a copy. Who transferred a secondary copy from the desktop to the laptop? Presumably, the owner of the computers. Who is on the hook in that situation? The owner of the machines.
Illegal downloading never enters into this argument. It's neither here nor there. GPL software has an initial distribution mechanism that is independent of the GPL. You can purchase a copy for download or on physical media, or you can download a copy for free. Doesn't matter. You don't need the GPL to own that initial copy.
Here. A download for you: http://games.datadino.com/wc1/wc1viewer-source.zi
There is no license anywhere in that file, nor on the homepage. Now tell me, what are your rights to that file?
No, you are NOT violating copyright law because you made a copy. You are violating the law because you are knowingly obtaining a copy from someone who does not have the rights to offer you that copy.
A legitimate defense is that any reasonable person under the circumstances of illegal distribution would have thought that the distribution was legal. (Which I believe was a defense used by a few surprised KaZaa users who had paid fees to KaZaa's parent company for the P2P software; but that may have been an invention of Wired's Michelle Delio. Very annoying when journalists don't provide sources.) If that defense breaks down, however, then the law treats the situation in a manner similar to that of knowingly receiving stolen goods. Basically, you knew about the infringement, therefore you are also guilty of the infringement.
Now will you please get this ridiculous idea out of your head that you need the GPL to download software? As I've been repeatedly stating, the GPL's language is very clear that it is predicated on the idea of NOT taking effect when the software is downloaded.
Considering that both the Wii and the DS are smash hits at the moment, I'd say that Nintendo is a "Two Trick Pony". Unless you count the continuing success of the Gameboy Advance. In which case Nintendo is a three trick pony. That is, unless you also count their unrivaled success with the Super Nintendo. In which case they're a four trick pony. Oh, but what about the original Gameboy? Make that a five trick pony. Six if you count the market-reviving, competition-stomping powerhouse that was the NES. Oh, but what about the games?!? Donkey Kong, Super Mario Bros., Mario 3, Zelda, Metroid, Starfox, DK:Country, Mario Kart, Link to the Past, FZero, Mario 64, Starfox 64, Ocarina of Time, FZero X, Metroid Prime-- oh to hell with it. I'll just give you a grand total.
By my count, Nintendo is a 3,421,978 trick pony.
I can certainly see your point. By my count Sony has innovated much more than Nintendo with a grand total of... erm... two tricks. 1.5 if you believe in Sony's (rather confusingly put) "more than 10 years" philosophy of console design.
Depends. Do they grow 50 stories tall after they link up?
Don't give them any ideas.
Wait... Did you say zord? As in "MegaZord"? As in "Giant Robot"?
Yeah, it was pretty common back in the days of floppy disks. It doesn't surprise me that a few companies extended the practice to early CD games. Unfortunately, the console folks tend to think of their media as indestructible for some reason or another. That was more or less true back in the days of cartridges, but it's sure as heck isn't true with optical discs.
Yet Nintendo still prints their "backups are not necessary nor authorized" warning in the manuals. (I imagine that the other console makers print something similar.) That's great. Tell it to a used copy of FZero GX I got that had no visible damage to the disc yet wouldn't function in a Gamecube or Wii.
And again, we go around in circles.
You are a legal owner of a copy of the software when you download it or receive it on disc. You do NOT need the GPL to become a legal owner.
Period.
This is standard copyright law.
Period.
It is legal because the software was provided by either the copyright holder or someone who agreed to the GPL distribution terms.
Period.
I can't make this any simpler. If it's not sinking in, then I'm afraid I cannot help you.
If you manage to understand that part of it, we'll go on to seeing if we can clear up your confusion on modifications.
A simple replacement program would do worlds of good. e.g. The ability to trade in the disk + a small processing fee (say, $5) for a new copy of just the optical disc. This wouldn't be all that different from vehicle extended warranties, which are intended to insure the life of your vehicle beyond the manufacturer's warranty.
This is a bit different. It's a way to convince the OS to give you more time slices than you'd normally be allocated. e.g. If you ran that program of yours twice at the same priority level, both instances should get ~50% of the CPU time. If one of the instances implemented this privilege boosting scheme however, it would get to hog all the CPU time while your other spinlocked program starved.
Using the "Troll" mod to Troll mod? How quaint. If anyone sees this in metamoderation, please do take care of the miscreant.
Whoa. Someone else who likes that shooter. Didn't expect to see that here.
Have you seen how much the Gamecube version of that game goes for these days? I've seen incredible prices on Amazon, well over $100 a piece. eBay isn't much better with used copies going for about $50. I can't help but think that Atari was a victim of bad timing. If they re-released it now, it would be a much greater success than it was back in 2003.
For the umpteenth time, the law explicitly provides for certain forms of copying. Your previous examples of loading a copy on the hard drive and RAM (which is what I was responding to) do not apply.
Section 117, Paragraph (a) of United States Code:
Read it, reread it, and read it again until it makes sense.
Sir, this is a dictionary perfect example of a "strawman argument". I would request that you cease such nonsensical arguments immediately, and please pay attention to what is actually being said.
I'll be honest with you, you're not making any sense at all. If you agree with these things, then why continue to invent scenarios for the GPL to kick in in which the GPL does NOT kick in?
I was actually quite clear on the circumstances regarding modification:
To add to that, any modifications you do that you don't share are effectively a no-op. Since no one ever sees them, there is no way for the terms of the GPL to apply.
In standard copyright parlance, modification of a computer program is an act of creating a derivative work. Now the copyright laws specifically state in Section 103 that only the owner of a copyright can prepare a derivative work. However, Section 107 explicitly curbs those rights per "fair use". Here's the section in its entirety:
See what I mean? You guys are just so forgiving.
Take a look at these games:
Ms. Pac Man
Jr. Pac Man
Stargate (aka Defender II)
Now tell me, was it really so impossible to make a Pac Man with the right maze and a character that turned his head, or a Defender in which the ship disappeared every time you fired?
I've programmed for the 2600. Its limitations are not what most people think they are. Travesties like PacMan and Defender only happened because a) Atari was churning its employees due to poor treatment and b) Atari never gave anyone enough time to do a really good job on a game.
The funny part is that third party titles regularly exceeded the graphics of Atari's games. The only problem is that very few third parties knew how to make a fun game.
ET really did get a bum rap. I know that it is everyone's favorite game to dislike, but the game wasn't as bad as everyone remembers it. A more sensible argument was that it missed the target market of action-game players that Atari had cultivated. Pushing an adventure game on them was probably a mistake, though it would have been less so if HSW had had a bit more time to tweak the gameplay. (Mostly to prevent you from falling in holes.)
Since E.T. was released right around the same time as the crash, its has been widely attributed as being the cause of the crash. I find this bit of urban mythology to be doubtful as E.T. didn't do nearly as bad as Pacman. (Relatively speaking.) In fact, many of the legends (e.g. there were more carts than consoles) were actually swiped from the story of Pacman and falsely applied to E.T.
While I'll agree that Atari wasn't exactly brimming with quality themselves, the market generally ignored their crud. Kids from the 80's don't even remember how bad Pacman or Defender were. They just remember that it was cool to have these games on a home console. (They were a surprisingly forgiving bunch!) However, Atari's quality snafus were nothing compared to the flood of garbage pouring out of US Games (a division of Quaker Oats!), Apollo, Xonox, Mythicon, Spectravision, Data Age, and Froggo. (Just to name a few.)
Eh? I believe I said the exact opposite. The market crashed because Atari didn't impose licensing restrictions. Today's console makers impose licensing restrictions to prevent that issue.
Have you seen many of them for sale in Walmart? The market crashed because of a glut of titles on the market. Not because people were modding their consoles so they could exchange homemade games with each other.
The only modern console I've ever seen commercial homebrew software for is the Dreamcast. And homebrewers only get away with it because Sega doesn't care anymore. The Dreamcast is dead to them.
There are commercial kits for modding and/or homebrewing, but that doesn't change the commercial market for games.
That doesn't matter. With nearly 200 million consoles strong, there are enough people who would buy these games to make them viable. Sales of over one million copies is still considered a success. Especially for the more casually-targeted games.
Ok, this one seems to have gone right past you. The price war was between Commodore and Texas Instrument computers. It was engineered by Tramiel to remove the price difference between computers and consoles. It was also timed to make computers dominant when consoles were at their lowest point. The gambit not only succeeded, but computers managed to fully replace consoles for a period of about 5 years.
Nintendo, Sony, and Microsoft can have a price war all they want. It won't replicate the situation that caused the console crash.
This: "Microsoft didn't fare much better, just barely edging out the Wii's sales."
:P
Is supposed to read: "Microsoft didn't fare much better, just barely edging out the GCN's sales."
Minor fubar on my part.
I don't think we really disagree. My point is that the PS2 got it start from being a cheap DVD player. Which catapulted it into the role of a casual gaming machine. Which has become a self-perpetuating engine of sales thanks to the large library of casual games.
The point in history I'm discussing is specifically the chicken and the egg solution that the PS2 used. You can't sell consoles unless you have a large library of good games. And you can't get game creators to make good games unless there is a customer base of consoles to target. Sony solved this with a good launch followed by a price drop that made it a cheap DVD player. We don't even think about it now as DVD players are so cheap, but all those games ended up on the console because Sony managed to get the console in the hands of consumers.
What Sony seems to have underestimated with the PS3 is that:
1. Not many people want a BluRay player.
2. $600 may be a bargain in relative terms, but it's a lousy value in absolute terms. Consumers only care about the absolute terms.
While you are correct, I think it's important to understand that the crash of '83 can't happen again. The factors that made it happen simply don't exist anymore. Those factors are: