Out in the console games development market, there's one real serious tool: a hardware profiler. Basiclly, it's a heavily modified PSX with bus analyzers tacked on so that it can snoop and tell *exactly* where the slowdowns are. Is it a cache miss? Is it the GPU hammering on things? There's none of the "this function is slow" -- it points out *why*.
You should not rely on profilers from the beginning of writing code, but you they're no cure-all either. A profiler can't tell you to use quicksort over a bubblesort. It just says what is slow, and it's up to the programmers to find a faster way to do things.
The most recent x86 profiler I've used was Intel's VTune (AMD's free tool at http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_3604,00.html was so-so at best for my use). Those apps don't do any of the fancy bus analysis, etc. Still, I'd suspect they're better than nothing.
I know this is going to sound like flamebait, but C++ *does* make it very easy to shoot yourself in the foot with regards to performance. If you don't set up all your operators to properly take consts, if you forget to set things up, it can kill performance. If you rely on a *lot* of small functions, you can either (1) blow out the cache with a larger executable (more likely on consoles), or (2) forget to inline a few, and kill your performance with lots of *tiny* calls that probably won't show up under VTune. The slowness of various compilers makes people afraid of putting a lot of small functions in headers where they belong, as any change would force a slow, full rebuild.
I've seen C++ compilers decide to inline a 4x4 matrix copy by unrolling a loop to read/write the first 12 elements, then call the Vector4 copy constructor. Worst of all worlds. Replacing that with a memcpy was a huge win. But, the only way one would know *how* to fix that is to be able to look at the disassembly.
This article, while a good read, more or less neglects the Japanese videogame industry. There's tons of games pumped out each year, some with amazing amounts of creativity. Yes, a fair amount of the software is derivative sequels. But, I'll put the guys at Nintendo, Sega, Sony (Gran Turismo) up as some of the best game designers around.
Nathan Mates
[And yes, I do work in the games industry.]
Will he post any changes? Will the Russkies? Will the Chinese Communists? Enquiring minds want to know.:)
Consider the limitations
on
PS2 As PC
·
· Score: 3
The PS2 is a game console first, which means it's got a lot of limitations built in. Games are used to these limitations right off the bat, as they'll take the tradeoffs for a very limited compatability problem-- if it works on one PS2, it'll (usually) work on all.
First off, game programmers (of which I am one, and I've got a development box for one of the top name consoles this Christmas at my desk at work) always gripe about lack of RAM. However, we're used to it.
Most unix/linux desktop/workstation applications are *NOT* programmed with a concern for memory. [Embedded applications are a completely different area, but most linux coders are not working on that.] Virtual memory has always been an option for traditional unix development, so the big RAM hogs like X, gcc, and web browsers just run a little slower on older boxes.
On the other hand, the PS2 has 32MB RAM, and I highly doubt there'll ever be any virtual memory. If you want to use the HD (which'll be in maybe 5% of PS2s, tops), programmers will have to explicitly manage all RAM and swapping. That's a huge paradigm shift from traditional unix desktop/workstation programming, which is where 99+% of linux types work on.
32MB of RAM on the PS2 isn't gonna be enough to drop X on it, in my opinion, let alone a ported browser. A ground-up rewrite with a stripped down custom-built GUI (Qt, even though that gives some people the fits) is the only reasonable solution. Plus, the resolution of a TV is just plain lousy. No beans about it. People aren't going to want to use it for reading stuff for long.
Next, there's the market for addons for game consoles has historically been *very* limited. In the games business, one rule of thumb I've heard is that you can assume that maybe only 5-10% of customers will have any peripheral (ram, input, bolt-ons like the Sega 32X) not bundled with the box. Unless Sony sells a PS2 with a HD and a keyboard, you're talking about a very niche market here.
Finally, as I mentioned above, there's a different programming mentality between console game programmers and desktop/workstation types. Game programmers are used to precalculating, preconverting, doing as much work as possible to code and assets long before it gets to the console.
We do not develop on a console, for that console-- we don't run gcc on a PS2. gcc is one of the really bad offenders in assuming it's got as much ram/virtual memory as it wants. We run gcc on a host PC, and use that to cross-compile code. Same with all the art tools, sound/music, etc. There's a ton of work needed to get things done, and consolers are optimized for gameplay, not development.
Shipping a PS2 with "linux" on it means that they'll have to axe gcc (and lots of other development tools, I'm not singling it out), as there's no realistic way they're going to run on the PS2, building for the PS2. Is unix without a compiler really unix? In my mind, nope. I want the power to tweak out anything on my system, and run what I write. Consoles can't do that.
I can't stand the flicker of flourescent lights either. At least with computer monitors, we've had the option of getting from 60Hz (which is "good enough" for some) to 75+Hz, which is far better. Those that claim the human eye can't see past 30fps are just plain wrong.
So, an idea I've had recently is this: why not just overclock flourescents? Running at 120Hz (a 2:1 rate) would probably make them far less annoying to most people. While there may be an energy crisis in CA, more people (like me) might consider them if they weren't so darn headache-inducing.
Talking between two pieces of hardware is the simplest of problems. Useful communication between applications is *far* more difficult, and will only really happen if the same game exists on both ends.
This is realistically the last summer for the Dreamcast. Not many games at all will come out for it after the Christmas season with MS and Nintendo's game boxes taking up all the attention. I can't imagine PS2 games coming out next year along with a DC "port" just so that a few more people can play online.
So, a few games that are created this summer might play between the PS2 and DC, along with Sega's Phantasy Star Online. Realistically, that's at most 5 games that support this. News, but irrelevant news.
FSAA does have huge wins, especially when a games maximum resolution is limited. For example, Escape From Monkey Island (Lucasarts, 2000) is locked to 640x480. The difference between regular and FSAA on my Geforce 2MX at home was highly apparent on my 19" monitor. After turning it on, I couldn't bear to go back.
Sure, FSAA'ing a 1600x1200 image may have almost no visible improvements. But, once you see what it can do at lower resolutions, you don't want to go back.
Nathan Mates
It's not April 1, is it?
on
What is 'IT'?
·
· Score: 1
If we were closer to April Fools Day, this would smell drastically like a hoax. Despite the date, it still sorta does. We'll see how this plays out over the long run.
Until the fully searchable tutorials are built in, I've found that the best way to learn a new environment (usually different OSs; I've got FreeBSD and OpenBSD running at home now) is a simple solution:
Have more than 1 box.
I do the work on one machine, and surf the websites (and google.com) from another when I have a problem while installing. A P133 is dirt cheap these days, and a great testbed-- you *WILL* botch the first few installs of a new OS.
>No. Paper-pushing is dead. You aren't going to build a multi-billion dollar business on a dead market with no margins.
There may be no margins in the printers, but those ink carts sell for a pretty hefty markup. $30 at the local Best Buy for an inkjet cart is probably $5 in parts and labor, tops.
>This means a) once you write a game, you can get it pressed anywhere,
Not quite. Sony owned the only factories in the world that made the black CDs. Sony got approx $5-7 per CD they pressed for a company, so owning the factories meant that they were sure to get their required cut per CD.
>b) you can order a small run, and if it takes off, you can have your stocks completely refilled in three days
Once again, not quite. It was Sony's factories or nothing. Granted, it's a *far* better deal than the $30/cart of raw material costs, but Sony's not stupid and insisted on control.
Nathan Mates
The point of the article is that while Mir may have been occupied for most of its life, there are times (such as right now) where it's not occupied.
As long as we can get a second station in space (orbiting, on moon/mars/other) before the ISS tanks, the point of the article is that from now on, there'll always be 1 or more human off earth.
This is a good thing. Space is vast, unoccupied, and there's nothing out there that'll care if we strip mine the asteroid belts, or dump some toxic waste into a lunar crater or the sun. Plus, it gets us out of this "all our eggs in one basket," err, in one planet, problem. It'd still be a tragedy to see global thermonuclear war, but if enough humanity is living elsewhere, life can go on.
Apple has *never* shipped a machine with enough RAM since the Apple//c. Period.
The original Macintosh had 128Kb, and the engineers had to go behind Job's back to have the capacity to go higher. Guess what? It was needed.
The original Apple IIGS shipped with 256Kb of memory, not enough to load the graphical OS (ProDOS 16 + Tools) designed for it. When the OS won't load, that's a severe sign that something should be done.
All of this has continued through the years, with their OSs chewing through most of the RAM on a base system, and leaving nothing left.
To be fair, some PC makers skimp on RAM as well at times-- when P3-800s were the hot new thing, I saw them sold with 64MB ram, which is a serious crippling.
My general rule of thumb for homebuilt boxes is roughly CPU Mhz divided by 4, rounded up to the nearest comfortable size. Thus, my 200Mhz boxes at home have 64MB, my PII-350 has 128, etc.
Looking back at Intel's history, their new product families tend to be introduced around the same speed or slower than older chips, but then they ramp the new chip's speed way up.
Consider the Pentium 60, vs 486DX4/100. The P60 wasn't all that much faster. The (non-MMX) Pentium core made it to 200Mhz, which smoked all 486s. P2 was introduced at 233 Mhz, similar to PMMX, but they ramped it to 400-500Mhz. The P3 was introduced at 450Mhz, and they're now at 1Ghz.
Why is this done? I believe Intel knows they can get people to buy things at the speeds and prices they set. [Last I checked, they're still making a profit on CPUs, so this strategy is still successful.] Once they get the cash of the early adoptors, they ramp speeds, and get more customers once things have a real benefit.
While some above have correctly noted iD's *choice* of open sourcing their older projects (Wolf3D, Doom, Quake1), I feel we need to commend them for doing other things correctly as well.
When iD wanted to make Wolf3D, they did not have the Wolfenstein name. Castle Wolfenstein and Beyond Castle WOlfenstein were done by MUSE Software, which was out of business. Did iD just unilaterally declare that the title was 'abondoned' and use it? No. They did the grunt work in tracking down the holder of the copyright (some granny in Maine, iirc), and *LEGALLY* got the name.
I commend them for doing things *rightly*.
Who says we can't learn from their example?
With copyright law as it stands, things *will* remain copyrighted for a darn long time unless you do one thing: ASK. Ask the copyright holder if they'll reclassify it, just as iD did with Wolf/Doom/Q1. If they say yes, everyone wins.
However, if the copyright holder says no, then it's time to prove we can behave like someone older than a two-year-old who's had his favorite toy taken away from them. Accept their judgment on the matter, and don't allow it to be copied (or posted for download).
It all boils down to respect for the author: if they say "freely copy this under BSD|GPL|XYZ license" then listen to them. If they say "don't copy this," then listen to them *the*same*way*.
One sentiment expressed is that the effort expended ensured that nothing bad would happen. Sure, we spent $$$ on things, and nothing happened.
But, look at the rest of the world. Countless third world countries (and the old Soviet Bloc, which might as well be 3rd world) did zilcho. Nothing happened there either. My parents work overseas in one of those 3rd world trashcans, and they can testify that nothing was done. Guess what: they survived the changeover just fine.
So, if both the first and third world came out ok, I would not attribute our success to the $$$ spent. The counterexample is just too strong to ignore.
I'm the network programmer on Battlezone II [see the Official site here ], and we're using such a setup. It looks as if at least one other game is using a similar method; see here also.
Only user inputs are sent around in BZ2, and used by every machine in the game to compute a new gamestate; if a client disagrees with the server, we can either shove a correct gamestate do that client, or kick them out. While traditional lockstep methods do have smoothness problems due to unpredictable transmission delays over the internet, on BZ2, we developed an interesting solution which we call 'Multiworld' -- sorry I can't say much more than that.
Even with synchronization, there still are client-side hacks that can be used-- people changing texture maps to show enemies more clearly, perfect radar hacks, and more. Even if everything's checksummed up the wazoo and that "works" (hah), a hacked driver can do fun stuff with texturemaps, or more.
This all points to one fundamental problem in computer security: on a system, there is at least one user (and/or process) that can read another processes's memory. Just that abiity is enough to develop cheats. [See: perfect radar above.] Unix's root account can do that, so it's really no better in terms of trust than Win95/98.
Fully stopping cheating is a problem not in computer science. It's a problem in humanity-- we're buggy to the core.
Slashdot Mirror
Out in the console games development market, there's one real serious tool: a hardware profiler. Basiclly, it's a heavily modified PSX with bus analyzers tacked on so that it can snoop and tell *exactly* where the slowdowns are. Is it a cache miss? Is it the GPU hammering on things? There's none of the "this function is slow" -- it points out *why*.
D /0,,30_2252_3604,00.html was so-so at best for my use). Those apps don't do any of the fancy bus analysis, etc. Still, I'd suspect they're better than nothing.
You should not rely on profilers from the beginning of writing code, but you they're no cure-all either. A profiler can't tell you to use quicksort over a bubblesort. It just says what is slow, and it's up to the programmers to find a faster way to do things.
The most recent x86 profiler I've used was Intel's VTune (AMD's free tool at http://www.amd.com/us-en/Processors/DevelopWithAM
I know this is going to sound like flamebait, but C++ *does* make it very easy to shoot yourself in the foot with regards to performance. If you don't set up all your operators to properly take consts, if you forget to set things up, it can kill performance. If you rely on a *lot* of small functions, you can either (1) blow out the cache with a larger executable (more likely on consoles), or (2) forget to inline a few, and kill your performance with lots of *tiny* calls that probably won't show up under VTune. The slowness of various compilers makes people afraid of putting a lot of small functions in headers where they belong, as any change would force a slow, full rebuild.
I've seen C++ compilers decide to inline a 4x4 matrix copy by unrolling a loop to read/write the first 12 elements, then call the Vector4 copy constructor. Worst of all worlds. Replacing that with a memcpy was a huge win. But, the only way one would know *how* to fix that is to be able to look at the disassembly.
Nathan Mates
This article, while a good read, more or less neglects the Japanese videogame industry. There's tons of games pumped out each year, some with amazing amounts of creativity. Yes, a fair amount of the software is derivative sequels. But, I'll put the guys at Nintendo, Sega, Sony (Gran Turismo) up as some of the best game designers around.
Nathan Mates
[And yes, I do work in the games industry.]
Will he post any changes? Will the Russkies? Will the Chinese Communists? Enquiring minds want to know. :)
The PS2 is a game console first, which means it's got a lot of limitations built in. Games are used to these limitations right off the bat, as they'll take the tradeoffs for a very limited compatability problem-- if it works on one PS2, it'll (usually) work on all.
First off, game programmers (of which I am one, and I've got a development box for one of the top name consoles this Christmas at my desk at work) always gripe about lack of RAM. However, we're used to it.
Most unix/linux desktop/workstation applications are *NOT* programmed with a concern for memory. [Embedded applications are a completely different area, but most linux coders are not working on that.] Virtual memory has always been an option for traditional unix development, so the big RAM hogs like X, gcc, and web browsers just run a little slower on older boxes.
On the other hand, the PS2 has 32MB RAM, and I highly doubt there'll ever be any virtual memory. If you want to use the HD (which'll be in maybe 5% of PS2s, tops), programmers will have to explicitly manage all RAM and swapping. That's a huge paradigm shift from traditional unix desktop/workstation programming, which is where 99+% of linux types work on.
32MB of RAM on the PS2 isn't gonna be enough to drop X on it, in my opinion, let alone a ported browser. A ground-up rewrite with a stripped down custom-built GUI (Qt, even though that gives some people the fits) is the only reasonable solution. Plus, the resolution of a TV is just plain lousy. No beans about it. People aren't going to want to use it for reading stuff for long.
Next, there's the market for addons for game consoles has historically been *very* limited. In the games business, one rule of thumb I've heard is that you can assume that maybe only 5-10% of customers will have any peripheral (ram, input, bolt-ons like the Sega 32X) not bundled with the box. Unless Sony sells a PS2 with a HD and a keyboard, you're talking about a very niche market here.
Finally, as I mentioned above, there's a different programming mentality between console game programmers and desktop/workstation types. Game programmers are used to precalculating, preconverting, doing as much work as possible to code and assets long before it gets to the console.
We do not develop on a console, for that console-- we don't run gcc on a PS2. gcc is one of the really bad offenders in assuming it's got as much ram/virtual memory as it wants. We run gcc on a host PC, and use that to cross-compile code. Same with all the art tools, sound/music, etc. There's a ton of work needed to get things done, and consolers are optimized for gameplay, not development.
Shipping a PS2 with "linux" on it means that they'll have to axe gcc (and lots of other development tools, I'm not singling it out), as there's no realistic way they're going to run on the PS2, building for the PS2. Is unix without a compiler really unix? In my mind, nope. I want the power to tweak out anything on my system, and run what I write. Consoles can't do that.
Nathan Mates
I can't stand the flicker of flourescent lights either. At least with computer monitors, we've had the option of getting from 60Hz (which is "good enough" for some) to 75+Hz, which is far better. Those that claim the human eye can't see past 30fps are just plain wrong.
So, an idea I've had recently is this: why not just overclock flourescents? Running at 120Hz (a 2:1 rate) would probably make them far less annoying to most people. While there may be an energy crisis in CA, more people (like me) might consider them if they weren't so darn headache-inducing.
Nathan Mates
Talking between two pieces of hardware is the simplest of problems. Useful communication between applications is *far* more difficult, and will only really happen if the same game exists on both ends.
This is realistically the last summer for the Dreamcast. Not many games at all will come out for it after the Christmas season with MS and Nintendo's game boxes taking up all the attention. I can't imagine PS2 games coming out next year along with a DC "port" just so that a few more people can play online.
So, a few games that are created this summer might play between the PS2 and DC, along with Sega's Phantasy Star Online. Realistically, that's at most 5 games that support this. News, but irrelevant news.
Nathan Mates
FSAA does have huge wins, especially when a games maximum resolution is limited. For example, Escape From Monkey Island (Lucasarts, 2000) is locked to 640x480. The difference between regular and FSAA on my Geforce 2MX at home was highly apparent on my 19" monitor. After turning it on, I couldn't bear to go back.
Sure, FSAA'ing a 1600x1200 image may have almost no visible improvements. But, once you see what it can do at lower resolutions, you don't want to go back.
Nathan Mates
If we were closer to April Fools Day, this would smell drastically like a hoax. Despite the date, it still sorta does. We'll see how this plays out over the long run.
Nathan Mates
Until the fully searchable tutorials are built in, I've found that the best way to learn a new environment (usually different OSs; I've got FreeBSD and OpenBSD running at home now) is a simple solution:
Have more than 1 box.
I do the work on one machine, and surf the websites (and google.com) from another when I have a problem while installing. A P133 is dirt cheap these days, and a great testbed-- you *WILL* botch the first few installs of a new OS.
Nathan Mates
I get my copies of old games here. Things are available legally to those who don't succumb to the dark side.
>> Don't knock printers, they're damned important.
>No. Paper-pushing is dead. You aren't going to build a multi-billion dollar business on a dead market with no margins.
There may be no margins in the printers, but those ink carts sell for a pretty hefty markup. $30 at the local Best Buy for an inkjet cart is probably $5 in parts and labor, tops.
Nathan Mates
>This means a) once you write a game, you can get it pressed anywhere, Not quite. Sony owned the only factories in the world that made the black CDs. Sony got approx $5-7 per CD they pressed for a company, so owning the factories meant that they were sure to get their required cut per CD. >b) you can order a small run, and if it takes off, you can have your stocks completely refilled in three days Once again, not quite. It was Sony's factories or nothing. Granted, it's a *far* better deal than the $30/cart of raw material costs, but Sony's not stupid and insisted on control. Nathan Mates
The point of the article is that while Mir may have been occupied for most of its life, there are times (such as right now) where it's not occupied.
As long as we can get a second station in space (orbiting, on moon/mars/other) before the ISS tanks, the point of the article is that from now on, there'll always be 1 or more human off earth.
This is a good thing. Space is vast, unoccupied, and there's nothing out there that'll care if we strip mine the asteroid belts, or dump some toxic waste into a lunar crater or the sun. Plus, it gets us out of this "all our eggs in one basket," err, in one planet, problem. It'd still be a tragedy to see global thermonuclear war, but if enough humanity is living elsewhere, life can go on.
Nathan Mates
Apple has *never* shipped a machine with enough RAM since the Apple //c. Period.
The original Macintosh had 128Kb, and the engineers had to go behind Job's back to have the capacity to go higher. Guess what? It was needed.
The original Apple IIGS shipped with 256Kb of memory, not enough to load the graphical OS (ProDOS 16 + Tools) designed for it. When the OS won't load, that's a severe sign that something should be done.
All of this has continued through the years, with their OSs chewing through most of the RAM on a base system, and leaving nothing left.
To be fair, some PC makers skimp on RAM as well at times-- when P3-800s were the hot new thing, I saw them sold with 64MB ram, which is a serious crippling.
My general rule of thumb for homebuilt boxes is roughly CPU Mhz divided by 4, rounded up to the nearest comfortable size. Thus, my 200Mhz boxes at home have 64MB, my PII-350 has 128, etc.
Nathan Mates
Looking back at Intel's history, their new product families tend to be introduced around the same speed or slower than older chips, but then they ramp the new chip's speed way up.
Consider the Pentium 60, vs 486DX4/100. The P60 wasn't all that much faster. The (non-MMX) Pentium core made it to 200Mhz, which smoked all 486s. P2 was introduced at 233 Mhz, similar to PMMX, but they ramped it to 400-500Mhz. The P3 was introduced at 450Mhz, and they're now at 1Ghz.
Why is this done? I believe Intel knows they can get people to buy things at the speeds and prices they set. [Last I checked, they're still making a profit on CPUs, so this strategy is still successful.] Once they get the cash of the early
adoptors, they ramp speeds, and get more customers once things have a real benefit.
Nathan Mates
While some above have correctly noted iD's *choice* of open sourcing their older projects (Wolf3D, Doom, Quake1), I feel we need to commend them for doing other things correctly as well.
When iD wanted to make Wolf3D, they did not have the Wolfenstein name. Castle Wolfenstein and Beyond Castle WOlfenstein were done by MUSE Software, which was out of business. Did iD just unilaterally declare that the title was 'abondoned' and use it? No. They did the grunt work in tracking down the holder of the copyright (some granny in Maine, iirc), and *LEGALLY* got the name.
I commend them for doing things *rightly*.
Who says we can't learn from their example?
With copyright law as it stands, things *will* remain copyrighted for a darn long time unless you do one thing: ASK. Ask the copyright holder if they'll reclassify it, just as iD did with Wolf/Doom/Q1. If they say yes, everyone wins.
However, if the copyright holder says no, then it's time to prove we can behave like someone older than a two-year-old who's had his favorite toy taken away from them. Accept their judgment on the matter, and don't allow it to be copied (or posted for download).
It all boils down to respect for the author: if they say "freely copy this under BSD|GPL|XYZ license" then listen to them. If they say "don't copy this," then listen to them *the*same*way*.
- Nathan Mates
One sentiment expressed is that the effort expended ensured that nothing bad would happen. Sure, we spent $$$ on things, and nothing happened.
But, look at the rest of the world. Countless third world countries (and the old Soviet Bloc, which might as well be 3rd world) did zilcho. Nothing happened there either. My parents work overseas in one of those 3rd world trashcans, and they can testify that nothing was done. Guess what: they survived the changeover just fine.
So, if both the first and third world came out ok, I would not attribute our success to the $$$ spent. The counterexample is just too strong to ignore.
Nathan Mates
Only user inputs are sent around in BZ2, and used by every machine in the game to compute a new gamestate; if a client disagrees with the server, we can either shove a correct gamestate do that client, or kick them out. While traditional lockstep methods do have smoothness problems due to unpredictable transmission delays over the internet, on BZ2, we developed an interesting solution which we call 'Multiworld' -- sorry I can't say much more than that.
Even with synchronization, there still are client-side hacks that can be used-- people changing texture maps to show enemies more clearly, perfect radar hacks, and more. Even if everything's checksummed up the wazoo and that "works" (hah), a hacked driver can do fun stuff with texturemaps, or more.
This all points to one fundamental problem in computer security: on a system, there is at least one user (and/or process) that can read another processes's memory. Just that abiity is enough to develop cheats. [See: perfect radar above.] Unix's root account can do that, so it's really no better in terms of trust than Win95/98.
Fully stopping cheating is a problem not in computer science. It's a problem in humanity-- we're buggy to the core.
Nathan Mates
BZ2 Network Programmer
http://www.visi.com/~nathan/