Q_Who: Preprocessor is most useful feature, see for example enforcer idiom by Alexandrescu and Marginean, even if it's just for __LINE__ and __FILE__
I don't think the implication was that __LINE__ and __FILE__ are not useful. Right now they are implemented using a preprocessor, but there's no reason that has to be true. Why can't a compiler understand what line and file it is on without the need for a preprocessor? It sure can, though the language must support it. But the reason it's in the preprocessor and not C is because the C language was not designed with __LINE__ and __FILE__ in mind. With a modern language/compiler, you can include it in the design.
Q_Who: Complain about overloading functions
I agree, it sure sounds bad, but I've never actually run into problems personally. D does address this, though, in case you're curious. To quote: "In D, function overloading is simple. It matches exactly, it matches with implicit conversions, or it does not match. If there is more than one match, it is an error."
And the debugging problems with opacity though preprocessor macros can get pretty bad.....
Anyway, I'm all for getting rid of the preprocesor, as long as the functionality is retained. (e.g. We still need conditional compilation as long as there are subtle changes across operating systems.)
Careful with the double boxing. During the UPS strike several years back, my brother shipped his computer double boxed exactly like you suggest.
What arrived was a large box full of styrofoam peanuts, beat up to hell and back badly enough that there were holes, and openings at the seams. And that was it; no innner box with computer. He never got it back.
The message here is not to avoid the double boxing as that is still a good idea, but to:
1. Tape the fsck out of that outer box so it can't get open no matter what they do to it.
2. Insure the hell out of it to make up for the time you'll have to sink recovering everything.
3. Above all else, back up your important data first.
Oh, and ship in the original packaging if you can; that way you can avoid having to double box it.
Okay, you got me. It was a completely true statement, and it directly answered his question.
The reason I called it smartass is because I don't think it was the answer he was asking for, since I don't think I was the intended audience for the question.
You're right that it does still apply somewhat -- even sysadmins write scripts (or more) and should always leave their mark in the form of a comment.
Actually, no, I wasn't referring to yours in particular. Yours was quite well stated. I was referring to the fact that most of the highly-moderated comments at the time were "Of course you can't download ROMs, it ILLEGAL!!!!" It's not as though yours and the others were not correct or insightful, it's that they never actually stated the assumption that we were talking about downloading ROMs which the downloader does not own.
Certainly there are a great number of people downloading a great number of ROMS for which they never owned a physical version of. But there are legitimate reasons for downloading ones you do own. I have dozens of Amiga games I've bought, and with the right hardware/software, I could extract all those floppies to my Win32 hard drive and run them with an emulator. I'd rather not deal with my old Amiga hardware anymore.
The post by PainKilleR-CE was one of the only ones to present this argument, and although he (she?) seemed more sure of the copyright laws than I would be comfortable asserting, I felt it was still well phrased. The response to it appeared to be missing the point (although that was apparently just my own interpretation) so I felt like maybe I could help clarify some of his arguments. Enough of the meta-discussion, however... let's get back on topic.
As to your question about Black. First, we know what the RIAA's answer would be and can move on to fact and reason. If you have a cassette tape and download the MP3, and we make the assumption that the CD cost more, then you might consider that the CD cost more because it was higher quality, and it is very questionable whether or not you can legally download the higher quality MP3.
Now suppose I bought the CD and ripped it with full error correction, using EAC 0.9b5 and encoded with LAME3.9.0 -V 3 -b 112. Is that okay? I sure as hell hope so. Now instead of doing it myself, I found one ripped and encoded using the exact same software, and then I downloaded it. Is that legal? A little questionable, but I personally think it should be.
The ROM issue I usually view the same as the latter, not as the cassette tape one: one can assert that you can convert from an Amiga disc to a Win32.adf file, and be pretty sure about the legality. But if you've got the Amiga floppy, and a.adf file that wasn't converted by you but is a bit-for-bit match of the one your would have generated if you had done it yourself, does that make it illegal? Again, I really hope not, but that's just injecting my opinion where I don't have a definite answer. I can tell you I would have no moral qualms about it, though.
Part of the fuzziness is where you own the PS2 version of Baldur's Gate, and then download the XBOX version; this is more like your cassette tape example. The games are virtually identical, but not completely, and thus the legality is even less solid here.
Oh... sorry, then. I was just annoyed that most of the "insightful" comments in the topic were all of the opinion that owning a ROM was always piracy, no questions asked. Yours merely struck me because I finally found a comment that presented the opposite side of the story reasonably well, and it looked like you were trying to disagree with one of its less significant points.
Your question read more like incredulity to me, by the way. So again, I apologize.
I don't think I'm reading too much into it, but I believe what he was saying was that if you bought MarioBros for NES, then you download the SAME ROM as the one you already physically have on a cartridge, that's the same thing as extracting the ROM from your cartridge. Thus, if it's legal to extract the ROM from your cartridge, it's legal to download the same ROM from online. (Whether or not the law agrees may be a little unclear.)
Also, he did explicitly say MAME may be a different situation. The exception he pointed out was that some were released on other platforms. There are exact examples of this: many arcade machines (e.g. NEO-GEO?) use the same hardware as a home platform, and the ROM will be essentially unchanged between what the arcade had and the home version had. Thus if you owned the home version, the arcade ROM was the same under copyright law. But again, this was an exception he pointed out, not the rule.
I think you're trying to disagree with what was never said.
Yeah, sure! I put a checkin comment every time I modify code, along with my name and date. Future generations will know the exact time I introduced a bug just by looking at the source!
</smartass>
(Okay, so I'm a programmer, not a sysadmin. I guess your question doesn't really apply to me, unless you call uninstalling Clippy "leaving my mark"....:)
I assume you're facetiously pretending to be a conspiracy theorist (thus the smiley), but you somehow got modded +5 Informative anyway. I personally would have preferred +5 Funny, but no explaining mods sometimes.
But just to point out what someone who has not submitted articles before may not know (whether or not that is you): the submitter has no control over the "Valour writes" part. That part is up to the editor who posts the story, and the default is "[nick] writes...".
Thus, the best he could have done was:
Valour writes "I've written an in-depth review for my site, the Jem Report....."
But so fsking what? It's not like what he said was wrong, and if it seemed misleading it was only to reduce the amount of credit he got, not to take credit for someone else's work. If he really were making any attempt to cover it up, all he had to do was put in another nickname in the submission form, or submit it as an AC. Sheesh!
Is there a compiler other than gcc that can compile a Linux kernel and all the supporting utilities and libraries? Including monsters like XFree86.
That is a tall order, I'll grant you. I mentioned icc (Intel's Linux compiler) because I remember hearing (prolly on/.) that it could finally compile most, if not all, of the kernel. I'm not sure about other packages, but I imagine the kernel, with all its parts, is the hardest to accomplish.
Anyway, I did say icc wasn't necessarily the best example, exactly for the reason you mention. Others responses to my original post have mentioned other compilers, if you're curious.
I understand where you're coming from, but anytime I hear RMS talk about this, he does not make this distinction. His typical message is more of a blanket "It's not Linux, it's GNU/Linux. I wish the media would stop propagating these wild inaccuracies. Don't refer to the OS as Linux without the GNU!".
So you're right; it would be more accurate if he said something along the lines of "Red Hat is not a Linux OS, it is a GNU/Linux OS". I'm sure things like LRP that have to put a distro on a floppy use uClibc and busybox instead of the GNU glibc and command line tools, and they probably don't come with a compiler (gcc) either. Would he still want to call these "GNU/Linux"?
Text editors: vi, nedit Shells: zsh, tcsh Compiler: icc (not a great example, but nevertheless...) Linker: not sure -- is there anything other than ld? Debugger: there are others like totalview that cost money; any others? C Library: uClibc Standard UNIX tools: busybox covers many Desktop Environment: KDE
I think one could make a quite reasonable Linux distro without much GNU software. I'm not saying someone has quite yet (I don't know of one), so your point is still valid, but just because you consider grep as part of the OS doesn't mean is has to be the GNU version.
Just a data point for ya: (For reference, I use 3 of the top 5 in the list, though only one is truly in production mode right now).
In my experience, the majority of the codes running on them are C, but there is still plenty of FORTRAN. But it's typically the newer ones that are C, and older ones that are FORTRAN, and the older ones typically are not using much beyond F77.
#2 (Q at LANL) and #4 (White at LLNL), and others, are doing classified work, but they're still on this list. But you're pretty much right if you meant that these are all unclassified architectures.
Interestingly, though, things the NSA has wouldn't be likely to show up on this list, as the benchmarks are suited towards MPP style machines. NSA is more likely to have vector machines than large numbers of scalar processors.
Also you can do searches on the Playstation web site for 2 player games. A lot of sports games appear, but it gets you a list.
Hey, that's pretty cool.... Wish I'd known about that earlier. It's obviously not perfect because doesn't say whether it's cooperative or competitive, but it would at least have given me a shorter list to start from.
Really? That's good to know. Forgive me 'cuz I'm not used to the terminology, but: Rogue Squadron II is the GameCube Rogue Leader??
(The reason I ask is there is also Battle for Naboo, Starfighter, and Jedi Starfighter. I might be forgetting one, too. But I don't think Rogue Leader was made for any platform other than GC....)
Sure. If you're talking about BG:DA for the PS2, I think I actually remember having to turn on the damage number popups. Anyway, the setting is in the options accessible from the start menu.
Really, almost any game that *supports* co-op is good co-op. Go to the store and look at the back, often it'll say.
Ya know, I've tried that, but unfortunately I haven't come up with much. One problem, especially with the PS2, is that there are a whole lot of games on the shelves, and there are many more that have been pushed off of retail stores but you can still get online. Also, some games that claim to have a 2-player cooperative mode only have it for a limited portion of the game or for an entirely different sub-game than the main one. I've tried going checking out review sites like GameSpot, but they don't really list that specifically, and reviewers don't necessarily care about it.
One specific case: Halo. I've heard all the hype about how greate the game is, but I never hear about the cooperative mode. (I know it may be because I'm deaf and blind, but probably moreso because I don't yet own an XBox.)
Scary. Not just your comment, but a bunch of responses to it. I feel the need to respond if only to give a differing opinion.
I started programming when I was 7 years old. Atari 1200XL. Moved onto a Commodore 64. Then an Amiga. Then an IBM PC (8086/8088). Then more modern 386/486. An itty bitty bit of Macs. Went to college (BSCS), did the whole Sun/IRIX/HPUX thing for four years. Got a job at a National Laboratory programming. Did that for a couple years. Now back in grad school in CS (MS) while working. I've done BASIC, C, C++, Java, Python, Perl, and several others I'm embarrased to mention (though they end in -TRAN and -BOL). Programming in school and programming at work. When I have free time, I often write programs for fun or for utility. It's been twenty years. I will never get burnt out on it. Many of the people in CS in grad school I know are the same way.
I hate to make the analogy because it sounds presumptuous, but for me it's fun and creative, kind of like art. I know there are many people out there who chose programming because it was a good living. But they couldn't have enjoyed it too much to begin with. If I hear someone say they're burnt out, I wonder if they fall into this category. Can you imagine an artist say "That's it. I'm burnt out. I've painted for three years professionally, and now I hate it."? If so, then maybe they never really were an artist.
Sure, there are some tedious parts like debugging, but even that can be rewarding. And certain projects can suck your brains out; imagine working on a huge mural with 10 other artists for several years. Certain projects can get old. But while you're doing that project, you aren't necessarily thinking that you hate art (programming), but maybe instead that you're still itching to paint (code) something you want to work on instead of the project you're sick of.
If you've programmed some, and said to yourself, "Hey, this is slick! Look at this code I brought to life!", you might have it in you. If you wrote something and said "Glad that's over, now gimme my paycheck/diploma", then you might want to reconsider.
I realize the root was probably a troll (the AC, not you). Also, the submitter was technically asking about nearby frames. Realizing that, however, I'll respond anyway, because I feel the technique is at least worth a mention:
There is nevertheless a form of super-resolution which works on standalone single frames. It depends on what you mean by "additional detail". Normally when magnifying images you would use nearest-neighbor, or better yet, bilinear interpolation. But a magnification using these methods will still look blocky.
Now suppose you first detect the edges in your lo-res image. When you magnify, use that information to determine which pieces of the newly created pixels should be colored what. You can use a similar concept for textured areas without edges. The result? Through some simple assumptions, you get much better magnification than through other schemes.
If a star in your original image is a 5-pixel plus pattern, a super-resolution image might turn it into a circle. Though not strictly accurate, this is in fact not a bad result in many situations. However, you're right that there is really no more detail; if a star was not visible in the original image, it never will be.
Maybe somebody subjected you to one of my favorite old tricks. Take one corner off of a solved cube and rotate it so that the colors don't match the rest of the cube. Reassemble in this orientation. Presto: unsolveable cube.
Kinda funny -- I've inadvertently subjected myself to this same trick as a child. It always took so long to scramble the thing, it was easier to take it apart and put it back together in random order. Little did I realize there was a very good chance of creating an unsolvable cube.
Furthermore, I went so far as to buy a "how to solve the rubik's cube" book. Followed every goddamn step in that thing, and was pissed when it wasn't working. Eventually I tried it on my sibling's and it worked, and I came to the conclusion that mine was defective. Not sure how long it took me to figure out how mine became defective, but the blame was fully mine.:)
Gotta say, trying to solve an unsolveable puzzle sure kept me busy. It may have gotten my frustration tolerance up high enough that I can stand to debug those really nasty programs....
1. You're absolutely right that there is no substitute for good testing. Test, test, and then set up a test suite, and then run that test suite every night. Maintain and add to that test suite as you write more code. But I don't think that's a complete solution.
2. It's hard to test everything, even if you are religious about it. The bugs I was describing are nefarious in that you can use the program, even with testing, and not realize they are happening until someone uses your program or library in a way you didn't think about.
3. For my schoolwork, my assignments are on the order you describe -- maybe 5-10 thousand lines on average. For these, I have almost never needed it. For my full time job, I work on projects ranging from 0.5 to 2 million lines of code. Those are the situations where it's really, really helpful. Why? Because:
4. For one reason, in large projects you didn't write most of that code yourself, and it's not always obvious where to start looking and what the code you're looking at is supposed to be doing.
5. In addition, those kinds of bugs are the ones that don't usually crash your code right away. You might get a segfault thousands of lines of execution later.
6. Even worse, these bugs will sometimes trash the stack, and you can't even get a good core dump. A good memory checker will find the problem where it started, not where it caused the crash.
7. Lastly, I've never used valgrind, but I have used purify; it may be that valgrind is less complete. (It is, however, thousands of dollars less expensive, and that makes it accessible to most everyone.)
I'm sure it's harder to accomplish this for kernel level code (it's primarily OSes being pointed at right here) but you can think everything is working hunkey-dorey and not realize something is going wrong under the covers.
Most errors of this can be found with testing under tools like valgrind or Rational's purify. I'm sure there are others (I've heard of ParaSoft Insure++, ATOM Third Degree, CodeGaurd, and ZeroFault), but the quality of these tools really matters.
The issue is that tiny errors can cause crashes intermittently, and not immediately. For example: uninitialized memory reads -- usually not a problem, but if this value is ever actually used, it will be. array bounds reads -- never acceptable, but depending on the structure of memory, may not always cause an immediate crash. array bounds writes -- like ABRs, may not be immediately fatal, but these are going to crash your code sooner or later.
Since they don't always cause an immediate crash, these errors are likely to creep in to released code without use of one of these tools. And if you want to know why we shouldn't always run programs in an environment that checks these kinds of things, try it once; you'll notice a speed hit of usually an order of magnitude. C/C++ is a perfectly acceptable language -- not all debugging has to be done by the compiler/interpreter or only after you notice a problem.
Slashdot Mirror
Q_Who: Preprocessor is most useful feature, see for example enforcer idiom by Alexandrescu and Marginean, even if it's just for __LINE__ and __FILE__
I don't think the implication was that __LINE__ and __FILE__ are not useful. Right now they are implemented using a preprocessor, but there's no reason that has to be true. Why can't a compiler understand what line and file it is on without the need for a preprocessor? It sure can, though the language must support it. But the reason it's in the preprocessor and not C is because the C language was not designed with __LINE__ and __FILE__ in mind. With a modern language/compiler, you can include it in the design.
Q_Who: Complain about overloading functions
I agree, it sure sounds bad, but I've never actually run into problems personally. D does address this, though, in case you're curious. To quote: "In D, function overloading is simple. It matches exactly, it matches with implicit conversions, or it does not match. If there is more than one match, it is an error."
And the debugging problems with opacity though preprocessor macros can get pretty bad.....
Anyway, I'm all for getting rid of the preprocesor, as long as the functionality is retained. (e.g. We still need conditional compilation as long as there are subtle changes across operating systems.)
This would be redundant as others have suggested it, but I've got a link:
Build a beowulf cluster of PS2 machines.
Careful with the double boxing. During the UPS strike several years back, my brother shipped his computer double boxed exactly like you suggest.
What arrived was a large box full of styrofoam peanuts, beat up to hell and back badly enough that there were holes, and openings at the seams. And that was it; no innner box with computer. He never got it back.
The message here is not to avoid the double boxing as that is still a good idea, but to:
1. Tape the fsck out of that outer box so it can't get open no matter what they do to it.
2. Insure the hell out of it to make up for the time you'll have to sink recovering everything.
3. Above all else, back up your important data first.
Oh, and ship in the original packaging if you can; that way you can avoid having to double box it.
Okay, you got me. It was a completely true statement, and it directly answered his question.
The reason I called it smartass is because I don't think it was the answer he was asking for, since I don't think I was the intended audience for the question.
You're right that it does still apply somewhat -- even sysadmins write scripts (or more) and should always leave their mark in the form of a comment.
Actually, no, I wasn't referring to yours in particular. Yours was quite well stated. I was referring to the fact that most of the highly-moderated comments at the time were "Of course you can't download ROMs, it ILLEGAL!!!!" It's not as though yours and the others were not correct or insightful, it's that they never actually stated the assumption that we were talking about downloading ROMs which the downloader does not own.
.adf file, and be pretty sure about the legality. But if you've got the Amiga floppy, and a .adf file that wasn't converted by you but is a bit-for-bit match of the one your would have generated if you had done it yourself, does that make it illegal? Again, I really hope not, but that's just injecting my opinion where I don't have a definite answer. I can tell you I would have no moral qualms about it, though.
Certainly there are a great number of people downloading a great number of ROMS for which they never owned a physical version of. But there are legitimate reasons for downloading ones you do own. I have dozens of Amiga games I've bought, and with the right hardware/software, I could extract all those floppies to my Win32 hard drive and run them with an emulator. I'd rather not deal with my old Amiga hardware anymore.
The post by PainKilleR-CE was one of the only ones to present this argument, and although he (she?) seemed more sure of the copyright laws than I would be comfortable asserting, I felt it was still well phrased. The response to it appeared to be missing the point (although that was apparently just my own interpretation) so I felt like maybe I could help clarify some of his arguments. Enough of the meta-discussion, however... let's get back on topic.
As to your question about Black. First, we know what the RIAA's answer would be and can move on to fact and reason. If you have a cassette tape and download the MP3, and we make the assumption that the CD cost more, then you might consider that the CD cost more because it was higher quality, and it is very questionable whether or not you can legally download the higher quality MP3.
Now suppose I bought the CD and ripped it with full error correction, using EAC 0.9b5 and encoded with LAME3.9.0 -V 3 -b 112. Is that okay? I sure as hell hope so. Now instead of doing it myself, I found one ripped and encoded using the exact same software, and then I downloaded it. Is that legal? A little questionable, but I personally think it should be.
The ROM issue I usually view the same as the latter, not as the cassette tape one: one can assert that you can convert from an Amiga disc to a Win32
Part of the fuzziness is where you own the PS2 version of Baldur's Gate, and then download the XBOX version; this is more like your cassette tape example. The games are virtually identical, but not completely, and thus the legality is even less solid here.
Oh... sorry, then. I was just annoyed that most of the "insightful" comments in the topic were all of the opinion that owning a ROM was always piracy, no questions asked. Yours merely struck me because I finally found a comment that presented the opposite side of the story reasonably well, and it looked like you were trying to disagree with one of its less significant points.
Your question read more like incredulity to me, by the way. So again, I apologize.
I don't think I'm reading too much into it, but I believe what he was saying was that if you bought MarioBros for NES, then you download the SAME ROM as the one you already physically have on a cartridge, that's the same thing as extracting the ROM from your cartridge. Thus, if it's legal to extract the ROM from your cartridge, it's legal to download the same ROM from online. (Whether or not the law agrees may be a little unclear.)
Also, he did explicitly say MAME may be a different situation. The exception he pointed out was that some were released on other platforms. There are exact examples of this: many arcade machines (e.g. NEO-GEO?) use the same hardware as a home platform, and the ROM will be essentially unchanged between what the arcade had and the home version had. Thus if you owned the home version, the arcade ROM was the same under copyright law. But again, this was an exception he pointed out, not the rule.
I think you're trying to disagree with what was never said.
Yeah, sure! I put a checkin comment every time I modify code, along with my name and date. Future generations will know the exact time I introduced a bug just by looking at the source!
:)
</smartass>
(Okay, so I'm a programmer, not a sysadmin. I guess your question doesn't really apply to me, unless you call uninstalling Clippy "leaving my mark"....
I assume you're facetiously pretending to be a conspiracy theorist (thus the smiley), but you somehow got modded +5 Informative anyway. I personally would have preferred +5 Funny, but no explaining mods sometimes.
But just to point out what someone who has not submitted articles before may not know (whether or not that is you): the submitter has no control over the "Valour writes" part. That part is up to the editor who posts the story, and the default is "[nick] writes...".
Thus, the best he could have done was:
Valour writes "I've written an in-depth review for my site, the Jem Report....."
But so fsking what? It's not like what he said was wrong, and if it seemed misleading it was only to reduce the amount of credit he got, not to take credit for someone else's work. If he really were making any attempt to cover it up, all he had to do was put in another nickname in the submission form, or submit it as an AC. Sheesh!
So make a distribution and call it GNU!
:)
That has got to be one of the best suggestions I've seen today.
Is there a compiler other than gcc that can compile a Linux kernel and all the supporting utilities and libraries? Including monsters like XFree86.
/.) that it could finally compile most, if not all, of the kernel. I'm not sure about other packages, but I imagine the kernel, with all its parts, is the hardest to accomplish.
That is a tall order, I'll grant you. I mentioned icc (Intel's Linux compiler) because I remember hearing (prolly on
Anyway, I did say icc wasn't necessarily the best example, exactly for the reason you mention. Others responses to my original post have mentioned other compilers, if you're curious.
I understand where you're coming from, but anytime I hear RMS talk about this, he does not make this distinction. His typical message is more of a blanket "It's not Linux, it's GNU/Linux. I wish the media would stop propagating these wild inaccuracies. Don't refer to the OS as Linux without the GNU!".
So you're right; it would be more accurate if he said something along the lines of "Red Hat is not a Linux OS, it is a GNU/Linux OS". I'm sure things like LRP that have to put a distro on a floppy use uClibc and busybox instead of the GNU glibc and command line tools, and they probably don't come with a compiler (gcc) either. Would he still want to call these "GNU/Linux"?
At the risk of this sounding like flamebait...
Text editors: vi, nedit
Shells: zsh, tcsh
Compiler: icc (not a great example, but nevertheless...)
Linker: not sure -- is there anything other than ld?
Debugger: there are others like totalview that cost money; any others?
C Library: uClibc
Standard UNIX tools: busybox covers many
Desktop Environment: KDE
I think one could make a quite reasonable Linux distro without much GNU software. I'm not saying someone has quite yet (I don't know of one), so your point is still valid, but just because you consider grep as part of the OS doesn't mean is has to be the GNU version.
Any additions, anyone? Changes? Criticisms?
Just a data point for ya: (For reference, I use 3 of the top 5 in the list, though only one is truly in production mode right now).
In my experience, the majority of the codes running on them are C, but there is still plenty of FORTRAN. But it's typically the newer ones that are C, and older ones that are FORTRAN, and the older ones typically are not using much beyond F77.
#2 (Q at LANL) and #4 (White at LLNL), and others, are doing classified work, but they're still on this list. But you're pretty much right if you meant that these are all unclassified architectures.
Interestingly, though, things the NSA has wouldn't be likely to show up on this list, as the benchmarks are suited towards MPP style machines. NSA is more likely to have vector machines than large numbers of scalar processors.
Also you can do searches on the Playstation web site for 2 player games. A lot of sports games appear, but it gets you a list.
Hey, that's pretty cool.... Wish I'd known about that earlier. It's obviously not perfect because doesn't say whether it's cooperative or competitive, but it would at least have given me a shorter list to start from.
Really? That's good to know. Forgive me 'cuz I'm not used to the terminology, but: Rogue Squadron II is the GameCube Rogue Leader??
(The reason I ask is there is also Battle for Naboo, Starfighter, and Jedi Starfighter. I might be forgetting one, too. But I don't think Rogue Leader was made for any platform other than GC....)
Sure. If you're talking about BG:DA for the PS2, I think I actually remember having to turn on the damage number popups. Anyway, the setting is in the options accessible from the start menu.
Really, almost any game that *supports* co-op is good co-op. Go to the store and look at the back, often it'll say.
Ya know, I've tried that, but unfortunately I haven't come up with much. One problem, especially with the PS2, is that there are a whole lot of games on the shelves, and there are many more that have been pushed off of retail stores but you can still get online. Also, some games that claim to have a 2-player cooperative mode only have it for a limited portion of the game or for an entirely different sub-game than the main one. I've tried going checking out review sites like GameSpot, but they don't really list that specifically, and reviewers don't necessarily care about it.
One specific case: Halo. I've heard all the hype about how greate the game is, but I never hear about the cooperative mode. (I know it may be because I'm deaf and blind, but probably moreso because I don't yet own an XBox.)
Scary. Not just your comment, but a bunch of responses to it. I feel the need to respond if only to give a differing opinion.
I started programming when I was 7 years old. Atari 1200XL. Moved onto a Commodore 64. Then an Amiga. Then an IBM PC (8086/8088). Then more modern 386/486. An itty bitty bit of Macs. Went to college (BSCS), did the whole Sun/IRIX/HPUX thing for four years. Got a job at a National Laboratory programming. Did that for a couple years. Now back in grad school in CS (MS) while working. I've done BASIC, C, C++, Java, Python, Perl, and several others I'm embarrased to mention (though they end in -TRAN and -BOL). Programming in school and programming at work. When I have free time, I often write programs for fun or for utility. It's been twenty years. I will never get burnt out on it. Many of the people in CS in grad school I know are the same way.
I hate to make the analogy because it sounds presumptuous, but for me it's fun and creative, kind of like art. I know there are many people out there who chose programming because it was a good living. But they couldn't have enjoyed it too much to begin with. If I hear someone say they're burnt out, I wonder if they fall into this category. Can you imagine an artist say "That's it. I'm burnt out. I've painted for three years professionally, and now I hate it."? If so, then maybe they never really were an artist.
Sure, there are some tedious parts like debugging, but even that can be rewarding. And certain projects can suck your brains out; imagine working on a huge mural with 10 other artists for several years. Certain projects can get old. But while you're doing that project, you aren't necessarily thinking that you hate art (programming), but maybe instead that you're still itching to paint (code) something you want to work on instead of the project you're sick of.
If you've programmed some, and said to yourself, "Hey, this is slick! Look at this code I brought to life!", you might have it in you. If you wrote something and said "Glad that's over, now gimme my paycheck/diploma", then you might want to reconsider.
I realize the root was probably a troll (the AC, not you). Also, the submitter was technically asking about nearby frames. Realizing that, however, I'll respond anyway, because I feel the technique is at least worth a mention:
There is nevertheless a form of super-resolution which works on standalone single frames. It depends on what you mean by "additional detail". Normally when magnifying images you would use nearest-neighbor, or better yet, bilinear interpolation. But a magnification using these methods will still look blocky.
Now suppose you first detect the edges in your lo-res image. When you magnify, use that information to determine which pieces of the newly created pixels should be colored what. You can use a similar concept for textured areas without edges. The result? Through some simple assumptions, you get much better magnification than through other schemes.
If a star in your original image is a 5-pixel plus pattern, a super-resolution image might turn it into a circle. Though not strictly accurate, this is in fact not a bad result in many situations. However, you're right that there is really no more detail; if a star was not visible in the original image, it never will be.
Maybe somebody subjected you to one of my favorite old tricks. Take one corner off of a solved cube and rotate it so that the colors don't match the rest of the cube. Reassemble in this orientation. Presto: unsolveable cube.
:)
Kinda funny -- I've inadvertently subjected myself to this same trick as a child. It always took so long to scramble the thing, it was easier to take it apart and put it back together in random order. Little did I realize there was a very good chance of creating an unsolvable cube.
Furthermore, I went so far as to buy a "how to solve the rubik's cube" book. Followed every goddamn step in that thing, and was pissed when it wasn't working. Eventually I tried it on my sibling's and it worked, and I came to the conclusion that mine was defective. Not sure how long it took me to figure out how mine became defective, but the blame was fully mine.
Gotta say, trying to solve an unsolveable puzzle sure kept me busy. It may have gotten my frustration tolerance up high enough that I can stand to debug those really nasty programs....
Well, yes, kind of.
1. You're absolutely right that there is no substitute for good testing. Test, test, and then set up a test suite, and then run that test suite every night. Maintain and add to that test suite as you write more code. But I don't think that's a complete solution.
2. It's hard to test everything, even if you are religious about it. The bugs I was describing are nefarious in that you can use the program, even with testing, and not realize they are happening until someone uses your program or library in a way you didn't think about.
3. For my schoolwork, my assignments are on the order you describe -- maybe 5-10 thousand lines on average. For these, I have almost never needed it. For my full time job, I work on projects ranging from 0.5 to 2 million lines of code. Those are the situations where it's really, really helpful. Why? Because:
4. For one reason, in large projects you didn't write most of that code yourself, and it's not always obvious where to start looking and what the code you're looking at is supposed to be doing.
5. In addition, those kinds of bugs are the ones that don't usually crash your code right away. You might get a segfault thousands of lines of execution later.
6. Even worse, these bugs will sometimes trash the stack, and you can't even get a good core dump. A good memory checker will find the problem where it started, not where it caused the crash.
7. Lastly, I've never used valgrind, but I have used purify; it may be that valgrind is less complete. (It is, however, thousands of dollars less expensive, and that makes it accessible to most everyone.)
I'm sure it's harder to accomplish this for kernel level code (it's primarily OSes being pointed at right here) but you can think everything is working hunkey-dorey and not realize something is going wrong under the covers.
Most errors of this can be found with testing under tools like valgrind or Rational's purify. I'm sure there are others (I've heard of ParaSoft Insure++, ATOM Third Degree, CodeGaurd, and ZeroFault), but the quality of these tools really matters.
The issue is that tiny errors can cause crashes intermittently, and not immediately. For example:
uninitialized memory reads -- usually not a problem, but if this value is ever actually used, it will be.
array bounds reads -- never acceptable, but depending on the structure of memory, may not always cause an immediate crash.
array bounds writes -- like ABRs, may not be immediately fatal, but these are going to crash your code sooner or later.
Since they don't always cause an immediate crash, these errors are likely to creep in to released code without use of one of these tools. And if you want to know why we shouldn't always run programs in an environment that checks these kinds of things, try it once; you'll notice a speed hit of usually an order of magnitude. C/C++ is a perfectly acceptable language -- not all debugging has to be done by the compiler/interpreter or only after you notice a problem.
Anyway, hope that wasn't too pedantic....