Last week, CowboyNeal said: "Mr. Schwartz, if you're reading this, feel free to send us one with "Attn: CowboyNeal" on the label."
The story is that Schwartz has replied with: "to the folks at slashdot, send me your contact data, we're happy to send a Niagara system for you to take a look at. Something tells me you fit the target demographic perfectly... (no floating point, heavy threading, etc.)"
I seem to remember in the early hype about OOP that OOP would end the role of the programmer. OOP was supposed to lead to a utopia where the end user would be grabbing and assembling objects to customize their environment and that the distinction between programmer and Joe Public would blur.
No, that was 4GL. OOP was supposed to make programming more structured, easier to manage, and quicker to code. While many programmers will swear up and down that it has achieved these goals, researchers were never able to quantify any performance boosts in OOP development.
Some evil voice inside me says that if you increase the number of monkeys, random code generation still won't scale, the number of possible codes increases exponentially with code length.
That evll voice wouldn't be named Gene Ahmdal would it?
(Yes, yes, I know. Ahmdal's law was about computer programs. But you have to admit that it applies this situation amazingly well.)
Anyone remember back when every PC owner was expected to know at least a little BASIC? Back then computers were used for custom programs just about as much as they were used for shrink-wrapped applications. And if you didn't have the skills to write your processing program in BASIC, you could always hire someone to do it quickly and cheaply. (Program requirements weren't exactly high back then, so finishing a program in a day or two was quite common.) The question is, what happened to those days?
I suppose part of it was that shrink wrapped software got better. Where as you originally might have had trouble finding the software you needed, today you can get software for just about anything! The other part of the problem was that programming became far more complex of a task. Instead of just taking data in and spitting out a report, it now has to provide a cool GOOEY interface (MMmmm... chocolate), and real-time interactivity. These types of features are not so easily grasped by the average person, and require training to master. Thus programming has been squarly placed in the hands of experts.
If Brian Behlendorf wants non-developers to write code, he's better have another BASIC up his sleeve. (AJAX BASIC? Hmmm... I might have code like that lying around...) Because I don't think I could possibly take another round of Fourth Generation Languages.
P.S. Excel VBA was a lousy attempt at getting non-coders to program. Don't do that to us again. Please. Make it truly home and SOHO focused like BASIC was.
Thank you for your wonderful offer. However, I feel that I must in good conscience, decline. I will not rename myself or my first born son to "BOTS", nor will I chisel the tagline of your new game "9Dragons" onto my great grandfather's tombstone. In fact, many of my collegues find your practices quite reprehensible, and will not support your company if you continue them. Thank you for your interest, and I hope that we won't do business again in the future.
...we're supposed to get worked up over a leather case for an iPod all while Slashdot continues to ignore Jonathan Schwartz's offer of free hardware for Slashdot? I must be missing something.
A friend gave me some basic info, and I figured out the rest. My first program to use it was a stereogram generator. A friend got me some sample code that did it. I think they got it from Tricks of the Graphics Gurus, although I'm not sure.
Ah hah! See, you were not without your resources. Many of whom were obviously sharing their experiences gleened from sources such as TGPG. Sadly, I had no such resources, and I know I wasn't alone. There simply wasn't anyone in my nearby area who had the experience and understanding to provide such info on the IBM PC. I had to pull myself up by my bootstraps, as it were.:(
Oh, and neither of us are indicitive of the education level of most would-be game programmers. Just because we had an interest in such things, and spent much of our lives in pursuit of those interest, doesn't mean that *most* would-be game programmers didn't get into PC technology until a later date.
You know, I'm not sure where I learned assembly from or when. I think I started learning from Borland compiler dumps, but didn't really get very into it then. I forget when I did.
Probably the same way I did. RTFM.:-)
LaMothe described high performance 3D engines?
I didn't say that LaMothe did. I said that I would be extremely surprised if you did far in advance of the industry. Again, there were NO fully 3D games with full texture mapping on the market in 1994. Zip, zero, zilch, none, nada. The fact that LaMothe didn't cover them is not surprising. (Why do I have to keep repeating this?)
But he didn't give you a good enough foundation to work with - only 320x200 if I remember right.
That's not a good foundation? You've got a surface. It's yeah big. Now we investigate drawing to it. Who the hell cares if it's 320x200 or 320x240? Learning about bank switching the memory is offtopic to a foundation because it completely confuses the issue. Why would you start someone with a "BTW, ignore this code, and this code, and this code, and that code, because it does some bank switching that we'll get to later" when you can simply give them a flat memory model to work from?
In addition, Mode X was a complete non-starter. Quake used it, and that was about it. SuperVGA cards were already popular at the time, and ended up being the way of the future. What did an education in Mode X provide that was actually long lasting? The only answer I have is absolutely nothing. On the other hand, TGPG's more abstract discussion about video scanning, page flipping, pallettes, and other general graphics concepts still lives on in modern graphics libraries. So there are more pixels, big whoop. Just change the values for screen width and screen height and you're done.
Not true. Not only was it standard on every raytracer at the time and most graphics editing programs
And what, exactly, did Ray Tracers have to do with game programming? Let me ask this again, since I seem to keep having to repeat it: What did Ray Tracers have to do with game programming?
You're going off on wild tangents, Rei, then using those tangents to justify your position. That's just not okay.
the Sega Genesis (1988) used antialiasing internally
You did *not* just say that. The Sega Genesis was capable of 4 Graphics Planes (2 scrolling playfields, 1 sprite plane, 1 'window' plane), up to 80 on-screen sprites, and 512 colors. There were no anti-aliasing features in the hardware and no room for any in the software. Unless you happen to count blurry output to the screen, that is. (Which was not intentional, I assure you.) The Genesis's graphics chip was really just an update to the VDP from the Sega Master System.
of course Abrash used it in the Commander Keen series
Ok, now I'm just going for the Princess Bride quote.
Rei: Commander Keen has anti-aliasing. AKAImBatman: You keep using that word. I do not think it means what you think it means.
That's your opinion, but just about all the "man on the street" reviewers are saying the exact opposite. They all think the game is a lot of fun, and that the Guitar is a necessary control component rather than a "gimmick".
I've played the game myself, and I must say that there's an addictive quality to it. You can really get into the idea that you're "playing" the guitar (despite the fact that you're doing no such thing), and soon find yourself jamming to the music. It's not the all time best game ever, but it does stand out as a game that was made to be fun rather than cutting edge.
At the very least, it's a refreshing change from the massive libraries of junk that the market has been releasing as of late.
No problem! However, next time you might consider just linking to your journal entry instead. There's no real reason to replicate all the info here.:-)
On another topic, I take it from your nick that you're a fan of Jeffrey Carver? I don't see too many folks who've read "Eternity's End", despite the fact that it's one of the greatest SciFi works of all time. (IMHO, of course.)
Mr. Hosiah, if you want an actual reply to your posts, you should try coming across like an intelligent individual rather than a raving troll. I am fully capable of defending my position, but I will NOT continue a conversation in the face of such uncalled for hostilities.
We can discuss the matter of modern distros (of which I am quite experienced in, thank you very much), or you can continue to lower your IQ by spitting flaming insules. It's your call.
First off, to sum up the below: from my viewpoint, TGPG covered almost nothing that I didn't already know in seventh grade,
Putting aside the fact that I *was* in seventh grade in 94, not everyone was in the same league, or even is today.:-)
with only a couple exceptions - and I had never read a programming book (apart from an intro to C) before that.
I find it a little hard to believe that you had zero resources, yet still knew how to load PCX files, kick the system into Mode 13h, understood assembly language, and could write up a high performance 3D graphics engine with proper depth sorting with nothing more than the Borland graphics library. (raises eyebrow) That would be quite an achievement. I have a feeling that you were programming WITH resources long before you got to C.
From 8 to 12 years old, a GW-BASIC manual and a few Usborne books containing type-it-yourself BASIC programs (that were for obscure BASIC dialects) were my only companions. If I didn't have so much other info stuffed in my head, I could probably recite you the entire GW-BASIC manual from memory.:-)
At 12 years old I learned C from a rather fat book on the subject. But there was nothing forthcoming after that. I knew C and some assembler (from reading the manual), but I would acquire myself a copy of the Pink Shirt book (Peter Norton's guide to programming the PC) until several years later. Picking up a copy of TGPG was a God-send. A solid, theoretical foundation from which to work from was what it gave me. I could finally stop looking for the magical shareware disk with the code I needed. (Yes, I actually wrote the Shareware Association and asked them if they had any code or recommendations demonstrating image loaders and scrolling code. I feel a little sheepish about that now, but what was a kid supposed to do?)
I spent quite a bit of hard-earned money on TGPG ($50 out of my take home of about $200 monthly from working at the local McD's!)
Please define what you mean by video scanning.
I mean a complete theory of operation of how video screens work. Understanding that is key to video gaming. Did you know that the Atari 2600 only buffered a single scanline? And not very well at that. You had three pixels for every one clock cycle, so you had to work out the scanline during the HSync and while it was drawing. You had about 20 bits for the entire line of the playfield, plus a byte for each of the two sprites, and a bit for a ball. Not much to work with, but even the Nintendo and Super Nintendo didn't improve upon this design all that much.:-)
I only brought up mode X to give an example of the depth of his knowledge on the subject of how video cards work compared to LaMothe. I was going on the assumption that you were referring to topics related to syncing with the scan rate of the monitor, which he gets into quite well in Zen.
LaMothe mentioned Mode X as well. He just didn't get into it because he was building a foundation, not trying to teach you every modern trick. With a foundation, you can figure out many of the other tricks yourself. Heck, I'd figured out Perspective Affine Texture Mapping before it became a term in the industry (without reading Abrash, mind you).
Oh really? Where in TGPG did they cover Wu antialiasing, the cornerstone of all modern sprite smooth scaling? Where did they cover much of *anything* about stretching, especially the issues involved in mapping to polys (and not only the technical ones, but also the practical ones)?
Antialiasing wasn't covered, because it was too costly to perform on the hardware of 1994. The chapter on 2D graphics, however, covered scaling, stretching, skewing, rotating, etc. The poly mapping (which was actually not truly covered, you're thinking of the sliver scaling) was in the chapter on raycasting.
Irregardless, check out "Predeterming Visibility Priority in 3-D Scenes" SIGGRAPH '79, pp 175-181. That's 1979. It wa
Facts? Oh, yes, facts! Well, don't worry. Dan Brown knows about lots of facts that the rest of us don't. (*wink* *wink* *nudge* *nudge*) Why, I expect that at this very moment, he's travelling in an X-33 to the homes of the authors of The Holy Blood and the Holy Grail where he will fire Ice Bullets at the authors through open windows. Then, safe in the knowledge that no one can figure out what he's done, he'll fly back in the X-33. Hopefully, he'll avoid detection by the super-secret US radar net put around the world to detect super-secret planes like the X-33. Otherwise the Delta Force might chase him in their Pulse Jet Aurora and try to fire antimatter warheads at him. (Shh! Don't let anyone know I told you this! As far as anyone else knows, Antimatter has never been produced in the lab!)
He will, of course, escape the Delta Force and their nasty Antimatter warheads by travelling through secret Illuminati tunnels meant to infiltrate the Freemasons. After his escape, he'll hire a Hassassin to go back to scene of the crime and burn ambigrams into the chests of the victims (which no one has yet managed to replicate, which is why they're not in the book, no siree!) so that the cops will think that it's a killing by the Illuminati. (Huh?)
Then he'll sit down with the girl (wait, were did she come in?) and have a nice cup of tea. At CERN. Where they build cool stuff, but apparently the whole world doesn't know about it. Really.
1. That's not true. Linux has had a number of viruses, personal experience not-withstanding.
2. Most people don't even know they have viruses. Why would they want to get rid of them?
3. The public has been told that his majesty Sir William Gates III will use his amazing programming powers to personally make those bad people go away in the next version of Windows.
So again, the question is not what Linux takes away, but what it can add that the average consumer will want.
I hate when people gripe about generalized "academics" just because they're not familiar with the topic being discussed.
He's not griping about Academics in general. He's griping about people who overcomplicate their language as an alternative to content. Academics can be some of the worst because they try hard to gain funding or credibility even when they're fresh out of things to say or invent. So they overcomplicate their speech to intentionally make a mountain out of a mole hill. Not all academics, mind you, but they are in the best position to abuse the English language for their own purposes.
P.S. Yes, I actually understand those papers. They're understandable because they use the technical terminology as necessary, not just because they can.
P.P.S. On the other hand, why are they all prefixed with "Novel"? I mean, if they're novel technologies, shouldn't that be a determination made by the reader? Did NASA's contractors run out of adjectives or something? Or are they writing a novel on technologies that the novel will make appear quite novel in their otherwise non-noval applications in a novel new field? That is a novel idea!:-P
It's harder to go out on a limb and go open source if you are the person making decisions.
The real reason why the general public isn't moving to Linux is simple: Nobody wants Linux.
Now before you string me up by my pinky toes, listen to me for a moment. Consumers don't purchase something they don't want or need. If you go into the store and see a flashlight, you won't pick it up unless you have no flashlight and absolutely NEED one. And even then you'll probably look for the cheapest one that meets your needs. One of those needs may be familiarity. If Brand Y is cheaper than Brand X, but you can't figure out how to turn it on without a manual, you're going to purchase Brand X.
Now consider for a moment that you're walking by the flashlights and see one that loudly proclaims "No Batteries needed!", "Super Bright Halogen Performance", "Tiny, Palm fitting size!", and "Laser Guided Beam!" Suddenly that flashlight is appealing to your baser instinct of "cool". Even if you don't need a flashlight at the moment, you're going to pick it up, look it over, and perhaps even convince yourself that you need a new flashlight. Then you'll get it home and read the manual to figure out how to turn the blasted thing on. You're then going to share your experience with your friends and family who may catch your enthusiasm and grab one of the new flashlights next time they're in the market. (Consider the fact that ThinkGeek has made an entire market out of "cool" objects that you don't need.)
Linux appeals to techies who want to try a new OS, but it doesn't universally impress people as being "so cool they need it". Ergo, they don't need it, so they don't get it. (It's really a matter of they don't *want* it, but they think in terms of needs.)
The same thing happened to Microsoft when they tried to get people to move to Windows. No one wanted the Microsoft Kool-aid. DOS worked just fine, and no one was going to switch to windows unless they had applications that required it to run. (And they usually grumbled about that.)
Enter Windows 95. Microsoft convinced the public at large that Windows 95 was SO important, that thousands of customers who didn't even have computers lined up to purchase this wonder-product. Sure, they were disappointed when they realized they needed a computer, but the millions of others who already had one, happily installed Windows. (Some even purchased expensive memory or hard drive upgrades just to run Windows 95.) Whether Win95 lived up to the hype or not is a different matter, but consumers were enamored with exploring the new features in this OS. (Almost) All of their old programs ran, and they could run these snazzy new Win95 apps that looked nothing like those ugly old Win3.1 apps. It was a revolution!
So what does Linux give consumers to make them want it? Cool features that Windows doesn't have? Not really. (At least, none that the consumer sees.) Pretty graphics? Nope. Linux lags behind, often showing ugly text screens. How about "killer apps" that exist nowhere else? Nope. Either they're ported to Windows, or they're just a rip-off of something consumers already have. So what does Linux have that makes the average consumer WANT it?
Absolutely nothing.
That's why I suggested technology to take Linux far out into the lead. If Linux can get there before Microsoft and Apple, it might actually have something to offer consumers that would make them want it. Otherwise it will continue to lag behind as the red-haired step child of the Desktop world.
Rei, he's trolling. He looked at my sig (a suggestion for improving the state of disparate formats) and instead of joining in the discussion over there, decided to add a bunch of throw-away comments about "Java Suxorz!" in an attempt to get fed.
Abrash went much more in depth. Remember, Abrash was the first person to publish Mode X, and possibly the first to ever encounter it (he takes caution to credit anyone who might have discovered it before him but kept it to themselves).
No he didn't. He went into cute tricks type of depth that only mattered at the time. Mode X is irrelevant to Video Scanning. That's merely a matter of reprogramming the VGA card, something that the card wasn't supposed to be able to do. (Unix Framebuffers were usually reprogrammable rather than having a fixed set of "modes", so it was not a new idea. Just a hack to let the VGA card do the same thing.) What LaMothe taught was how the video subsystem worked. That "how" stretches back to the very beginning of video games, where the core idea was just to produce a scan signal that represented the game. Fast forward from 1975 to 2006 and you find that the scan signal is just as important, we've just been abstracted away from it. For game developers, this can actually be detremental to their ability to produce games.
With what I learned from LaMothe, I was able to build upon that knowledge, and learn to work with the game system rather than against it.
Abrash was much more in depth, and also this is much more irrelevant now. This is the guy who wrote the sprite engine for the Commander Keen games.
Sprites are not irrelevant. There are still many 2D games that use the original concept. 3D games use the concept as well, except they're usually upgraded to 3D models (aka "actors") rather than 2D images. The cutesy tricks that Abrash taught, however, are out of date. For example, what good are compiled sprites* to anyone? Given a modern graphics pipeline, they're guaranteed to be slower than just pumping the RGB data. That was fun stuff to read in Dr. Dobbs, but not really anything that has stuck with us.
The key is to learn the basic concepts, and build yourself a foundation. The actual implementations are transient, and just not important in the long run.
Abrash's 3d mathematics sections were *far* superior, even getting into B-trees.
As I said, Abrash's book was 2 years after Tricks of the Game Programming Gurus. Quake didn't exist yet, ergo true 3D engines were pretty rare in gaming. (Doom used BSP trees, but that was something of a secret when it first came out.) I actually learned about BSP trees through the Internet before '96, and the follow up to LaMothe's book (More Tricks of the Game Programming Gurus) covered the concept. (The follow-up had a lot of good info, but it lacked the solid foundation the first book gave. Plus, it wasn't written by LaMothe.)
Perhaps you're not remembering the book well, but that is what he taught: optimize only the core loops, and apply what he refers to as both "left brain" and "right brain" optimizations.
I also remember how much time he spent on the low-level optimizations in his books. He tried to explain how to properly optimize, but he then took the reader through all the complex low-level optimizations, and focused very heavily on them. The result is that the take away for many developers was too fixated on the low-level rather than the high level. The consideration of (using an oversimplified example) inventing the Portal Engine as a way of eliminating the need for BSP trees was downplayed in favor of looking only as ways of making the BSP tree faster. LaMothe drilled in the idea, "A 12 year old may invent a better algorithm than a PHD in mathematics, just because he doesn't know any better." (From memory, so I may be paraphrasing.)
I'm not saying that Abrash's writings weren't useful. For their time, they were exceptionally useful for the area of expertise that Abrash wanted to cover. But get outside of that area and suddenly you realize that you have no foundation to build on. Thus his books were best to read if you already *had* a foundation and just needed some inspiration to improve yo
A game is _not_ just the code implementing it, and what made, say, KOTOR fun _isn't_ the clever lightsaber rendering code or the NPC dialogue code.
I'm not saying it is. However, the the graphics, the way the dialog works, the interaction between the characters, the mechanics of the game, etc, etc, etc. are all key to making it "fun". Any idiot can say, "I think we should have a game where the player can be a Jedi Knight. He can interact with other Knights, jump in an X-Wing, and handle his Light Saber like a real Jedi!"
The problem of Game Design is taking that abstract concept and executing it as a living, breathing game that will entertain the players. Just as an architect can't design a building if he doesn't know how to keep it from being architecturally unsound, someone without experience in development can't know how to make the mechanics of a game work. Simply throwing around terminology with explanations won't provide the combination of experience and creativity necessary. It will only allow you to write a high sounding resume.
I see no problem separating a tradesmaster from a completely _unrelated_ trade. The architect who designed a bank building is _not_ an expert on banking or economics.
Except that game design is NOT unrelated to game development. The designer of the bank building doesn't know how a bank works. However, he does know how to build a structure, and he's going to work with the banker to learn what the needs are. Working with the banker, he's going to learn that there is a much greater need to move cars through the drive-up than through the lobby. The lobby actually needs to devote more space to sitting down with customers to discuss loans and new accounts. So the designer takes this information and applies engineering principles to optimize these different needs, and looks at the entire pipeline to make sure each of these needs are met. This may not actually mean "bigger == better". In fact, the problem may be that the tellers have too much space to work with, and need things closer to move the traffic through quicker. It may mean that the filing department is too far from the lobby to be effective in handling loans and new accounts. It may mean that a lot of adjustments need to be made that only someone skilled in engineering can account for.
Now what would happen if the bank manager was asked to design the building? Well, he'd probably think that it needed a drive-up, a place for communicating with customers, a spot for the vault, etc. But he wouldn't understand the engineering side of things, and would thus fail to optimize any paths. In fact, he may create quite a few bottlenecks through naively filling in sections with the individual components. He might make the drive-up larger, thereby exasperating the large work area problem he had before. He might move the filing area even farther away in an attempt to increase the lobby volume. He might do a lot of things that are counterproductive to his actual goal. Why? Because he's not an engineer.
You don't ask a person inexperienced with gaming technology to design a game any more than you ask a bank manager to design a building. It's just that simple.
Slashdot Mirror
Dude, pay more attention.
Last week, CowboyNeal said: "Mr. Schwartz, if you're reading this, feel free to send us one with "Attn: CowboyNeal" on the label."
The story is that Schwartz has replied with: "to the folks at slashdot, send me your contact data, we're happy to send a Niagara system for you to take a look at. Something tells me you fit the target demographic perfectly... (no floating point, heavy threading, etc.)"
Kapesh?
I seem to remember in the early hype about OOP that OOP would end the role of the programmer. OOP was supposed to lead to a utopia where the end user would be grabbing and assembling objects to customize their environment and that the distinction between programmer and Joe Public would blur.
No, that was 4GL. OOP was supposed to make programming more structured, easier to manage, and quicker to code. While many programmers will swear up and down that it has achieved these goals, researchers were never able to quantify any performance boosts in OOP development.
s/Ahmdal/Amdahl/g
Stupid Internet.
Some evil voice inside me says that if you increase the number
of monkeys, random code generation still won't scale,
the number of possible codes increases exponentially with
code length.
That evll voice wouldn't be named Gene Ahmdal would it?
(Yes, yes, I know. Ahmdal's law was about computer programs. But you have to admit that it applies this situation amazingly well.)
Remember when we used to insert pauses or slow down programs with a loop like this:For really fast computers:These days we'd hang any programmer we found pulling that stunt.
I submitted a story twice. The first time it was outright rejected. The second time it was left in Pending for days. It's still in pending. :-/
Anyone remember back when every PC owner was expected to know at least a little BASIC? Back then computers were used for custom programs just about as much as they were used for shrink-wrapped applications. And if you didn't have the skills to write your processing program in BASIC, you could always hire someone to do it quickly and cheaply. (Program requirements weren't exactly high back then, so finishing a program in a day or two was quite common.) The question is, what happened to those days?
I suppose part of it was that shrink wrapped software got better. Where as you originally might have had trouble finding the software you needed, today you can get software for just about anything! The other part of the problem was that programming became far more complex of a task. Instead of just taking data in and spitting out a report, it now has to provide a cool GOOEY interface (MMmmm... chocolate), and real-time interactivity. These types of features are not so easily grasped by the average person, and require training to master. Thus programming has been squarly placed in the hands of experts.
If Brian Behlendorf wants non-developers to write code, he's better have another BASIC up his sleeve. (AJAX BASIC? Hmmm... I might have code like that lying around...) Because I don't think I could possibly take another round of Fourth Generation Languages.
P.S. Excel VBA was a lousy attempt at getting non-coders to program. Don't do that to us again. Please. Make it truly home and SOHO focused like BASIC was.
Thank you for your wonderful offer. However, I feel that I must in good conscience, decline. I will not rename myself or my first born son to "BOTS", nor will I chisel the tagline of your new game "9Dragons" onto my great grandfather's tombstone. In fact, many of my collegues find your practices quite reprehensible, and will not support your company if you continue them. Thank you for your interest, and I hope that we won't do business again in the future.
Sincerely,
Your Customers
Reference 1
Reference 2
...we're supposed to get worked up over a leather case for an iPod all while Slashdot continues to ignore Jonathan Schwartz's offer of free hardware for Slashdot? I must be missing something.
Ah, that's too bad. It really is a great book.
;-)
Just in case anyone else thinks the same, the "cybers" are a race in his book, and "riggers" are hyperspace pilots.
Cool hobby, BTW. You don't see too many geeks parachuting.
A friend gave me some basic info, and I figured out the rest. My first program to use it was a stereogram generator. A friend got me some sample code that did it. I think they got it from Tricks of the Graphics Gurus, although I'm not sure.
:(
:-)
Ah hah! See, you were not without your resources. Many of whom were obviously sharing their experiences gleened from sources such as TGPG. Sadly, I had no such resources, and I know I wasn't alone. There simply wasn't anyone in my nearby area who had the experience and understanding to provide such info on the IBM PC. I had to pull myself up by my bootstraps, as it were.
Oh, and neither of us are indicitive of the education level of most would-be game programmers. Just because we had an interest in such things, and spent much of our lives in pursuit of those interest, doesn't mean that *most* would-be game programmers didn't get into PC technology until a later date.
You know, I'm not sure where I learned assembly from or when. I think I started learning from Borland compiler dumps, but didn't really get very into it then. I forget when I did.
Probably the same way I did. RTFM.
LaMothe described high performance 3D engines?
I didn't say that LaMothe did. I said that I would be extremely surprised if you did far in advance of the industry. Again, there were NO fully 3D games with full texture mapping on the market in 1994. Zip, zero, zilch, none, nada. The fact that LaMothe didn't cover them is not surprising. (Why do I have to keep repeating this?)
But he didn't give you a good enough foundation to work with - only 320x200 if I remember right.
That's not a good foundation? You've got a surface. It's yeah big. Now we investigate drawing to it. Who the hell cares if it's 320x200 or 320x240? Learning about bank switching the memory is offtopic to a foundation because it completely confuses the issue. Why would you start someone with a "BTW, ignore this code, and this code, and this code, and that code, because it does some bank switching that we'll get to later" when you can simply give them a flat memory model to work from?
In addition, Mode X was a complete non-starter. Quake used it, and that was about it. SuperVGA cards were already popular at the time, and ended up being the way of the future. What did an education in Mode X provide that was actually long lasting? The only answer I have is absolutely nothing. On the other hand, TGPG's more abstract discussion about video scanning, page flipping, pallettes, and other general graphics concepts still lives on in modern graphics libraries. So there are more pixels, big whoop. Just change the values for screen width and screen height and you're done.
Not true. Not only was it standard on every raytracer at the time and most graphics editing programs
And what, exactly, did Ray Tracers have to do with game programming? Let me ask this again, since I seem to keep having to repeat it: What did Ray Tracers have to do with game programming?
You're going off on wild tangents, Rei, then using those tangents to justify your position. That's just not okay.
the Sega Genesis (1988) used antialiasing internally
You did *not* just say that. The Sega Genesis was capable of 4 Graphics Planes (2 scrolling playfields, 1 sprite plane, 1 'window' plane), up to 80 on-screen sprites, and 512 colors. There were no anti-aliasing features in the hardware and no room for any in the software. Unless you happen to count blurry output to the screen, that is. (Which was not intentional, I assure you.) The Genesis's graphics chip was really just an update to the VDP from the Sega Master System.
of course Abrash used it in the Commander Keen series
Ok, now I'm just going for the Princess Bride quote.
Rei: Commander Keen has anti-aliasing.
AKAImBatman: You keep using that word. I do not think it means what you think it means.
That's your opinion, but just about all the "man on the street" reviewers are saying the exact opposite. They all think the game is a lot of fun, and that the Guitar is a necessary control component rather than a "gimmick".
I've played the game myself, and I must say that there's an addictive quality to it. You can really get into the idea that you're "playing" the guitar (despite the fact that you're doing no such thing), and soon find yourself jamming to the music. It's not the all time best game ever, but it does stand out as a game that was made to be fun rather than cutting edge.
At the very least, it's a refreshing change from the massive libraries of junk that the market has been releasing as of late.
I was convinced that this had to be a joke. But here it is. Go figure.
No problem! However, next time you might consider just linking to your journal entry instead. There's no real reason to replicate all the info here. :-)
On another topic, I take it from your nick that you're a fan of Jeffrey Carver? I don't see too many folks who've read "Eternity's End", despite the fact that it's one of the greatest SciFi works of all time. (IMHO, of course.)
Here you go.
:-)
There are plenty of other companies that sell Linux an (sic) no-OS machines.
http://www.addonshop.com/
http://www.emperorlinux.com/
http://www.ibexpc.com/
http://www.koobox.com/
http://www.linare.com/
http://www.linspire.com/
http://www.linuxcertified.com/
http://www.linuxsyscorp.com/
http://www.microtelpc.com/
http://www.outpost.com/
http://shoprcubed.com/
http://www.sub300.com/
http://www.systemax.com/divisions.htm
http://www.walmart.com/
http://tuxmobil.org/reseller.html
http://www.us.debian.org/distrib/pre-installed
http://www.linux.org/vendor/system/index.html
http://tuxmobil.org/ (general information)
Slashdot's lameness filter is actually pretty... well... lame. Defeating it is usually as easy as adding more text. You know, like this sentence.
Mr. Hosiah, if you want an actual reply to your posts, you should try coming across like an intelligent individual rather than a raving troll. I am fully capable of defending my position, but I will NOT continue a conversation in the face of such uncalled for hostilities.
We can discuss the matter of modern distros (of which I am quite experienced in, thank you very much), or you can continue to lower your IQ by spitting flaming insules. It's your call.
First off, to sum up the below: from my viewpoint, TGPG covered almost nothing that I didn't already know in seventh grade,
:-)
:-)
:-)
Putting aside the fact that I *was* in seventh grade in 94, not everyone was in the same league, or even is today.
with only a couple exceptions - and I had never read a programming book (apart from an intro to C) before that.
I find it a little hard to believe that you had zero resources, yet still knew how to load PCX files, kick the system into Mode 13h, understood assembly language, and could write up a high performance 3D graphics engine with proper depth sorting with nothing more than the Borland graphics library. (raises eyebrow) That would be quite an achievement. I have a feeling that you were programming WITH resources long before you got to C.
From 8 to 12 years old, a GW-BASIC manual and a few Usborne books containing type-it-yourself BASIC programs (that were for obscure BASIC dialects) were my only companions. If I didn't have so much other info stuffed in my head, I could probably recite you the entire GW-BASIC manual from memory.
At 12 years old I learned C from a rather fat book on the subject. But there was nothing forthcoming after that. I knew C and some assembler (from reading the manual), but I would acquire myself a copy of the Pink Shirt book (Peter Norton's guide to programming the PC) until several years later. Picking up a copy of TGPG was a God-send. A solid, theoretical foundation from which to work from was what it gave me. I could finally stop looking for the magical shareware disk with the code I needed. (Yes, I actually wrote the Shareware Association and asked them if they had any code or recommendations demonstrating image loaders and scrolling code. I feel a little sheepish about that now, but what was a kid supposed to do?)
I spent quite a bit of hard-earned money on TGPG ($50 out of my take home of about $200 monthly from working at the local McD's!)
Please define what you mean by video scanning.
I mean a complete theory of operation of how video screens work. Understanding that is key to video gaming. Did you know that the Atari 2600 only buffered a single scanline? And not very well at that. You had three pixels for every one clock cycle, so you had to work out the scanline during the HSync and while it was drawing. You had about 20 bits for the entire line of the playfield, plus a byte for each of the two sprites, and a bit for a ball. Not much to work with, but even the Nintendo and Super Nintendo didn't improve upon this design all that much.
I only brought up mode X to give an example of the depth of his knowledge on the subject of how video cards work compared to LaMothe. I was going on the assumption that you were referring to topics related to syncing with the scan rate of the monitor, which he gets into quite well in Zen.
LaMothe mentioned Mode X as well. He just didn't get into it because he was building a foundation, not trying to teach you every modern trick. With a foundation, you can figure out many of the other tricks yourself. Heck, I'd figured out Perspective Affine Texture Mapping before it became a term in the industry (without reading Abrash, mind you).
Oh really? Where in TGPG did they cover Wu antialiasing, the cornerstone of all modern sprite smooth scaling? Where did they cover much of *anything* about stretching, especially the issues involved in mapping to polys (and not only the technical ones, but also the practical ones)?
Antialiasing wasn't covered, because it was too costly to perform on the hardware of 1994. The chapter on 2D graphics, however, covered scaling, stretching, skewing, rotating, etc. The poly mapping (which was actually not truly covered, you're thinking of the sliver scaling) was in the chapter on raycasting.
Irregardless, check out "Predeterming Visibility Priority in 3-D Scenes" SIGGRAPH '79, pp 175-181. That's 1979. It wa
So when you boot the machine, you see absolutely no text scrolling by on ANY user distro?
That's what I thought. Like it or not, the "standard" is graphical from beginning to end. If people see the wonderful lines of:
SMTP Starting... [OK]
USB Starting... [OK]
Mouse Starting... [OK]
ECP Starting... [FAIL]
X11 Start... [OK]
They just feel like it's not professional. And when they see those FAILs in bright red, they get especially uneasy.
how can someone claim copyright on facts?
Facts? Oh, yes, facts! Well, don't worry. Dan Brown knows about lots of facts that the rest of us don't. (*wink* *wink* *nudge* *nudge*) Why, I expect that at this very moment, he's travelling in an X-33 to the homes of the authors of The Holy Blood and the Holy Grail where he will fire Ice Bullets at the authors through open windows. Then, safe in the knowledge that no one can figure out what he's done, he'll fly back in the X-33. Hopefully, he'll avoid detection by the super-secret US radar net put around the world to detect super-secret planes like the X-33. Otherwise the Delta Force might chase him in their Pulse Jet Aurora and try to fire antimatter warheads at him. (Shh! Don't let anyone know I told you this! As far as anyone else knows, Antimatter has never been produced in the lab!)
He will, of course, escape the Delta Force and their nasty Antimatter warheads by travelling through secret Illuminati tunnels meant to infiltrate the Freemasons. After his escape, he'll hire a Hassassin to go back to scene of the crime and burn ambigrams into the chests of the victims (which no one has yet managed to replicate, which is why they're not in the book, no siree!) so that the cops will think that it's a killing by the Illuminati. (Huh?)
Then he'll sit down with the girl (wait, were did she come in?) and have a nice cup of tea. At CERN. Where they build cool stuff, but apparently the whole world doesn't know about it. Really.
How about NO VIRUSES?
1. That's not true. Linux has had a number of viruses, personal experience not-withstanding.
2. Most people don't even know they have viruses. Why would they want to get rid of them?
3. The public has been told that his majesty Sir William Gates III will use his amazing programming powers to personally make those bad people go away in the next version of Windows.
So again, the question is not what Linux takes away, but what it can add that the average consumer will want.
I hate when people gripe about generalized "academics" just because they're not familiar with the topic being discussed.
:-P
He's not griping about Academics in general. He's griping about people who overcomplicate their language as an alternative to content. Academics can be some of the worst because they try hard to gain funding or credibility even when they're fresh out of things to say or invent. So they overcomplicate their speech to intentionally make a mountain out of a mole hill. Not all academics, mind you, but they are in the best position to abuse the English language for their own purposes.
P.S. Yes, I actually understand those papers. They're understandable because they use the technical terminology as necessary, not just because they can.
P.P.S. On the other hand, why are they all prefixed with "Novel"? I mean, if they're novel technologies, shouldn't that be a determination made by the reader? Did NASA's contractors run out of adjectives or something? Or are they writing a novel on technologies that the novel will make appear quite novel in their otherwise non-noval applications in a novel new field? That is a novel idea!
It's harder to go out on a limb and go open source if you are the person making decisions.
The real reason why the general public isn't moving to Linux is simple: Nobody wants Linux.
Now before you string me up by my pinky toes, listen to me for a moment. Consumers don't purchase something they don't want or need. If you go into the store and see a flashlight, you won't pick it up unless you have no flashlight and absolutely NEED one. And even then you'll probably look for the cheapest one that meets your needs. One of those needs may be familiarity. If Brand Y is cheaper than Brand X, but you can't figure out how to turn it on without a manual, you're going to purchase Brand X.
Now consider for a moment that you're walking by the flashlights and see one that loudly proclaims "No Batteries needed!", "Super Bright Halogen Performance", "Tiny, Palm fitting size!", and "Laser Guided Beam!" Suddenly that flashlight is appealing to your baser instinct of "cool". Even if you don't need a flashlight at the moment, you're going to pick it up, look it over, and perhaps even convince yourself that you need a new flashlight. Then you'll get it home and read the manual to figure out how to turn the blasted thing on. You're then going to share your experience with your friends and family who may catch your enthusiasm and grab one of the new flashlights next time they're in the market. (Consider the fact that ThinkGeek has made an entire market out of "cool" objects that you don't need.)
Linux appeals to techies who want to try a new OS, but it doesn't universally impress people as being "so cool they need it". Ergo, they don't need it, so they don't get it. (It's really a matter of they don't *want* it, but they think in terms of needs.)
The same thing happened to Microsoft when they tried to get people to move to Windows. No one wanted the Microsoft Kool-aid. DOS worked just fine, and no one was going to switch to windows unless they had applications that required it to run. (And they usually grumbled about that.)
Enter Windows 95. Microsoft convinced the public at large that Windows 95 was SO important, that thousands of customers who didn't even have computers lined up to purchase this wonder-product. Sure, they were disappointed when they realized they needed a computer, but the millions of others who already had one, happily installed Windows. (Some even purchased expensive memory or hard drive upgrades just to run Windows 95.) Whether Win95 lived up to the hype or not is a different matter, but consumers were enamored with exploring the new features in this OS. (Almost) All of their old programs ran, and they could run these snazzy new Win95 apps that looked nothing like those ugly old Win3.1 apps. It was a revolution!
So what does Linux give consumers to make them want it? Cool features that Windows doesn't have? Not really. (At least, none that the consumer sees.) Pretty graphics? Nope. Linux lags behind, often showing ugly text screens. How about "killer apps" that exist nowhere else? Nope. Either they're ported to Windows, or they're just a rip-off of something consumers already have. So what does Linux have that makes the average consumer WANT it?
Absolutely nothing.
That's why I suggested technology to take Linux far out into the lead. If Linux can get there before Microsoft and Apple, it might actually have something to offer consumers that would make them want it. Otherwise it will continue to lag behind as the red-haired step child of the Desktop world.
Rei, he's trolling. He looked at my sig (a suggestion for improving the state of disparate formats) and instead of joining in the discussion over there, decided to add a bunch of throw-away comments about "Java Suxorz!" in an attempt to get fed.
:-P
* AKAImBatman plants a sign in the ground
DON'T FEED THE TROLLS
Abrash went much more in depth. Remember, Abrash was the first person to publish Mode X, and possibly the first to ever encounter it (he takes caution to credit anyone who might have discovered it before him but kept it to themselves).
No he didn't. He went into cute tricks type of depth that only mattered at the time. Mode X is irrelevant to Video Scanning. That's merely a matter of reprogramming the VGA card, something that the card wasn't supposed to be able to do. (Unix Framebuffers were usually reprogrammable rather than having a fixed set of "modes", so it was not a new idea. Just a hack to let the VGA card do the same thing.) What LaMothe taught was how the video subsystem worked. That "how" stretches back to the very beginning of video games, where the core idea was just to produce a scan signal that represented the game. Fast forward from 1975 to 2006 and you find that the scan signal is just as important, we've just been abstracted away from it. For game developers, this can actually be detremental to their ability to produce games.
With what I learned from LaMothe, I was able to build upon that knowledge, and learn to work with the game system rather than against it.
Abrash was much more in depth, and also this is much more irrelevant now. This is the guy who wrote the sprite engine for the Commander Keen games.
Sprites are not irrelevant. There are still many 2D games that use the original concept. 3D games use the concept as well, except they're usually upgraded to 3D models (aka "actors") rather than 2D images. The cutesy tricks that Abrash taught, however, are out of date. For example, what good are compiled sprites* to anyone? Given a modern graphics pipeline, they're guaranteed to be slower than just pumping the RGB data. That was fun stuff to read in Dr. Dobbs, but not really anything that has stuck with us.
The key is to learn the basic concepts, and build yourself a foundation. The actual implementations are transient, and just not important in the long run.
Abrash's 3d mathematics sections were *far* superior, even getting into B-trees.
As I said, Abrash's book was 2 years after Tricks of the Game Programming Gurus. Quake didn't exist yet, ergo true 3D engines were pretty rare in gaming. (Doom used BSP trees, but that was something of a secret when it first came out.) I actually learned about BSP trees through the Internet before '96, and the follow up to LaMothe's book (More Tricks of the Game Programming Gurus) covered the concept. (The follow-up had a lot of good info, but it lacked the solid foundation the first book gave. Plus, it wasn't written by LaMothe.)
Perhaps you're not remembering the book well, but that is what he taught: optimize only the core loops, and apply what he refers to as both "left brain" and "right brain" optimizations.
I also remember how much time he spent on the low-level optimizations in his books. He tried to explain how to properly optimize, but he then took the reader through all the complex low-level optimizations, and focused very heavily on them. The result is that the take away for many developers was too fixated on the low-level rather than the high level. The consideration of (using an oversimplified example) inventing the Portal Engine as a way of eliminating the need for BSP trees was downplayed in favor of looking only as ways of making the BSP tree faster. LaMothe drilled in the idea, "A 12 year old may invent a better algorithm than a PHD in mathematics, just because he doesn't know any better." (From memory, so I may be paraphrasing.)
I'm not saying that Abrash's writings weren't useful. For their time, they were exceptionally useful for the area of expertise that Abrash wanted to cover. But get outside of that area and suddenly you realize that you have no foundation to build on. Thus his books were best to read if you already *had* a foundation and just needed some inspiration to improve yo
A game is _not_ just the code implementing it, and what made, say, KOTOR fun _isn't_ the clever lightsaber rendering code or the NPC dialogue code.
I'm not saying it is. However, the the graphics, the way the dialog works, the interaction between the characters, the mechanics of the game, etc, etc, etc. are all key to making it "fun". Any idiot can say, "I think we should have a game where the player can be a Jedi Knight. He can interact with other Knights, jump in an X-Wing, and handle his Light Saber like a real Jedi!"
The problem of Game Design is taking that abstract concept and executing it as a living, breathing game that will entertain the players. Just as an architect can't design a building if he doesn't know how to keep it from being architecturally unsound, someone without experience in development can't know how to make the mechanics of a game work. Simply throwing around terminology with explanations won't provide the combination of experience and creativity necessary. It will only allow you to write a high sounding resume.
I see no problem separating a tradesmaster from a completely _unrelated_ trade. The architect who designed a bank building is _not_ an expert on banking or economics.
Except that game design is NOT unrelated to game development. The designer of the bank building doesn't know how a bank works. However, he does know how to build a structure, and he's going to work with the banker to learn what the needs are. Working with the banker, he's going to learn that there is a much greater need to move cars through the drive-up than through the lobby. The lobby actually needs to devote more space to sitting down with customers to discuss loans and new accounts. So the designer takes this information and applies engineering principles to optimize these different needs, and looks at the entire pipeline to make sure each of these needs are met. This may not actually mean "bigger == better". In fact, the problem may be that the tellers have too much space to work with, and need things closer to move the traffic through quicker. It may mean that the filing department is too far from the lobby to be effective in handling loans and new accounts. It may mean that a lot of adjustments need to be made that only someone skilled in engineering can account for.
Now what would happen if the bank manager was asked to design the building? Well, he'd probably think that it needed a drive-up, a place for communicating with customers, a spot for the vault, etc. But he wouldn't understand the engineering side of things, and would thus fail to optimize any paths. In fact, he may create quite a few bottlenecks through naively filling in sections with the individual components. He might make the drive-up larger, thereby exasperating the large work area problem he had before. He might move the filing area even farther away in an attempt to increase the lobby volume. He might do a lot of things that are counterproductive to his actual goal. Why? Because he's not an engineer.
You don't ask a person inexperienced with gaming technology to design a game any more than you ask a bank manager to design a building. It's just that simple.