All you say may be true (obvious even), but Ion Storm is the WORST EVER example of it, which is why the original post looks a lot like a troll.
Consider the story in question: The guy responsible for the absolute turd of a game (which sold very badly) leaves, the guy responsible for the ground-breaking game (which sold a bucketload) takes over the top spot. This is an absolutely terrible illustration of how 'risky' the industry is, it's rather a great illustration of how things would work in an ideal world.
Quit whining - garage games are alive and well, it's not even hard to find them. Check out this or this for great examples of PC garage development
There are also a lot of low-production-value, simple, fun games for consoles - not done by two guys in their garage, but with a definite substance-over-style design ethic. Try Bangaioh on the DC or Kuru Kuru Kururin on the GBA to see what I mean.
Even if you can rasterize textured triangles much faster in hardware than in software, you still want to apply lots of texture layers to your objects, you want to work with larger and much more detailed textures or in general you need more realism than what current hardware-based algorithms can deliver.
Your point is well-taken, but I wasn't suggesting actually shading any pixels with the 3D hardware. Like you say, even a GeForce3's pixel pipeline can't hold a candle to a Renderman shader. I was suggesting rather that the hardware be used only for rendering scene geometry and it's associated parameters into a 2D buffer. Texturing would only be used for converting interpolated parameters (eg. surface UVs or vert normals) into RGBA values that can be rendered to and then read back from the framebuffer and decoded. The CPU then does a pass over the resulting 2D 'image': It feeds each pixel's XYZ, normal and UV into a shader chosen based on the pixel's material-id and gets that pixel's colour out the other end.
There's still a lot of algorithms that you can't easily map to hardware
True. If a given pixel uses a shader that references scene geometry then yes, you do have to go and do some work in software. At least the hardware gave you had a head-start on that pixel though.
Antialiasing is quite doable too. Since fillrate isn't the main problem when you're rendering a bajillion tiny triangles, you might as well render the geometry at twice or quadruple the desired final resolution. The shading pass can then work at the final resolution and adaptively supersample where required.
The OpenGL case is really sweet
It is now that most vendors have gotten around to fixing glReadPixels().
Finally, a reason to play with pbuffers! I can already see myself switching to a 640*480*8bpp desktop to free up vram for higher-res renders...
...rendering animations for the silver screen, that means hardware accelerated OpenGL rendering doesn't cut it, it's highly probable that you want to do software rendering.
This is rapidly becoming a bit of a grey area; I personally reckon some kind of hybrid approach is going to become increasingly popular in the near future.
Modern graphics cards are designed specifically to rasterise gigantic numbers of tris very quickly; they have extremely well-tuned pipelines in place to do this, and using CPUs for this when there's such great custom hardware in place is kind of wasteful. GPUs have been on a Moore's-Law-on-steroids for a while now, so this is going to be increasingly the case.
I understand that some production renderers work by first generating very fat, 2D renders (eg. where each pixel contains a Z, UVs, material ids, a normal and so on) and then applying materials and effects as a 2.5D postprocess. Pass1 of this approach is absolutely ripe for hardware acceleration, in fact there's no real reason this can't be done right now.
So the question is, how long before the cheap renderfarm is joined by the cheap rasterisation farm, stuffed with nothing but GeForce2s, Celerons and RAM? Anyone?
...the wacky religious overtones? I recall something about this being due to the funding for the series coming from a Mormon leader or something like that. Anyone care to clarify / correct that?
I always thought DPI was a 1D measurement, ie. 300dpi means 300*300 dots per square inch.
So how does tripling the dot-count to achieve colour reduce the dpi by about a factor of 3? Shouldn't that be a factor of sqrt(3)?
Re:PS2 manufacturing cost.
on
PS2 As PC
·
· Score: 1
People buying the GNU/Linux kit will just add to the (large) pool of people who got their PSX2s mainly to play DVDs. Same problem for Sony, same solution - deliver some standout games.
Now I know you're not suggesting that Mozart's Requiem shouldn't be available to the public, purely on the basis that you don't like it that much. So what are you saying?
I'm quite happy to be able to listen to his final, unfinished work.
---
'Fruity smells are what I like'
Debbie Gibson
Re:But what will it look like for us?
on
Star Wars Galaxies
·
· Score: 5
I'm betting you'll need a godly connection to be able to get those kinds of graphics.
Yep, I'm sure you'll also need a pretty good video-card to get the full audio experience. And I'm sure anyone with a cheap soundcard will get terrible pings.
You work 80 hours a week (no overtime), have co-workers egos to battle with, endless paperwork. Every aspect of the code has to be documented. Programmers have nothing to do with the creative process, that is up to the producers, designers and publishers.
Wow, my experience of it is pretty much the opposite of yours. Unlucky, dude.
Yes, we work stupid hours with no overtime at my place when it's needed. But I find my co-workers all have their egos in check and they keep mine in check too. We don't document code much, we just communicate well. Coders have plenty of say in the creative process. Yes, publishers are a gigantic pain in the arse, but that's what management is there for - they deal with it and filter out the worst of it.
All in all, it's a shitty job and not worth the effort.
In terms of salaries, I totally agree that it's not worth the effort - you could make a hell of a lot more money with the equivalent skills elsewhere. But where else could I find a job where:
- I can wander into work at 11.00 in casual clothes
- The company has a budget for buying cool video-games and movies and stuff
- I like and respect everyone who works there, including the guy who's nominally supposed to be my boss
- Just dreaming up a cool new algorithm or special effect is reason enough to go ahead and spend time investigating and implementing it
- The end result of my efforts is something *fun* that I can *play*
Who decideds what's "morally and socially acceptable speech?"
The same guys who decides what's morally and socially acceptable behaviour and make laws based on that. In an ideal world, that's honest polititians who work hard to accurately represent an educated, informed and fair-minded populace.
I seem to recal a Bjarne Stroustrup quote along the lines of: "I think there's a smaller, cleaner language inside C++ trying to get out", and I definitely agree (assuming I'm haven't got it wrong and am totally misquoting him). Everyone I know has picked their subset and is wary of going outside it.
The first example is something no sane coder would ever type in C or Perl, so the warning would almost never be issued in error. It would almost always signal either a bug or some bad formatting.
I now realize using indentation for blocking is the "right" answer
Unfortunately, along with a few others I've had the "wrong" answer burnt into my brain by years of reinforcement. Why not have the parser spit out a 'suspicious construct' warning instead? It would prevent the bugs you describe just as well, and would be one less new trick for old dogs like myself to get rewire their neurons around.
Most people, when skimming code, look for the indentation anyway. This leads to sometimes easily overlooked bugs like this one:
if (x 10)
x = 10;
y = 0;
Is it just me, or is that an instantly suspicious-looking piece of code? I don't think it's 'easily overlooked' at all, it doesn't look like regular C/C++ at all.
Easy to say in retrospect I suppose, but still...
---
Fruity smells are what I like -- Debbie Gibson
Slashdot Mirror
All you say may be true (obvious even), but Ion Storm is the WORST EVER example of it, which is why the original post looks a lot like a troll.
Consider the story in question: The guy responsible for the absolute turd of a game (which sold very badly) leaves, the guy responsible for the ground-breaking game (which sold a bucketload) takes over the top spot. This is an absolutely terrible illustration of how 'risky' the industry is, it's rather a great illustration of how things would work in an ideal world.
Quit whining - garage games are alive and well, it's not even hard to find them. Check out this or this for great examples of PC garage development
There are also a lot of low-production-value, simple, fun games for consoles - not done by two guys in their garage, but with a definite substance-over-style design ethic. Try Bangaioh on the DC or Kuru Kuru Kururin on the GBA to see what I mean.
I guess this is a good indication of the status of the gaming industry, and how risky it is.
This is a troll, right?
Even if you can rasterize textured triangles much faster in hardware than in software, you still want to apply lots of texture layers to your objects, you want to work with larger and much more detailed textures or in general you need more realism than what current hardware-based algorithms can deliver.
Your point is well-taken, but I wasn't suggesting actually shading any pixels with the 3D hardware. Like you say, even a GeForce3's pixel pipeline can't hold a candle to a Renderman shader. I was suggesting rather that the hardware be used only for rendering scene geometry and it's associated parameters into a 2D buffer. Texturing would only be used for converting interpolated parameters (eg. surface UVs or vert normals) into RGBA values that can be rendered to and then read back from the framebuffer and decoded. The CPU then does a pass over the resulting 2D 'image': It feeds each pixel's XYZ, normal and UV into a shader chosen based on the pixel's material-id and gets that pixel's colour out the other end.
There's still a lot of algorithms that you can't easily map to hardware
True. If a given pixel uses a shader that references scene geometry then yes, you do have to go and do some work in software. At least the hardware gave you had a head-start on that pixel though.
Antialiasing is quite doable too. Since fillrate isn't the main problem when you're rendering a bajillion tiny triangles, you might as well render the geometry at twice or quadruple the desired final resolution. The shading pass can then work at the final resolution and adaptively supersample where required.
The OpenGL case is really sweet
It is now that most vendors have gotten around to fixing glReadPixels().
Finally, a reason to play with pbuffers! I can already see myself switching to a 640*480*8bpp desktop to free up vram for higher-res renders...
...rendering animations for the silver screen, that means hardware accelerated OpenGL rendering doesn't cut it, it's highly probable that you want to do software rendering.
This is rapidly becoming a bit of a grey area; I personally reckon some kind of hybrid approach is going to become increasingly popular in the near future.
Modern graphics cards are designed specifically to rasterise gigantic numbers of tris very quickly; they have extremely well-tuned pipelines in place to do this, and using CPUs for this when there's such great custom hardware in place is kind of wasteful. GPUs have been on a Moore's-Law-on-steroids for a while now, so this is going to be increasingly the case.
I understand that some production renderers work by first generating very fat, 2D renders (eg. where each pixel contains a Z, UVs, material ids, a normal and so on) and then applying materials and effects as a 2.5D postprocess. Pass1 of this approach is absolutely ripe for hardware acceleration, in fact there's no real reason this can't be done right now.
So the question is, how long before the cheap renderfarm is joined by the cheap rasterisation farm, stuffed with nothing but GeForce2s, Celerons and RAM? Anyone?
...the wacky religious overtones? I recall something about this being due to the funding for the series coming from a Mormon leader or something like that. Anyone care to clarify / correct that?
From the auction description:
Created by Cinematronics, it broke new ground in arcade animation and interactivity.
Yep, it certainly broke new ground in interactivity - it was possibly the least interactive video game ever, roughly on a par with The Matrix DVD.
I always thought DPI was a 1D measurement, ie. 300dpi means 300*300 dots per square inch.
So how does tripling the dot-count to achieve colour reduce the dpi by about a factor of 3? Shouldn't that be a factor of sqrt(3)?
People buying the GNU/Linux kit will just add to the (large) pool of people who got their PSX2s mainly to play DVDs. Same problem for Sony, same solution - deliver some standout games.
How they input patient information with that crappy gamepad, I'll never know. ;-)
Patient has a history of heart problems: Up, up, down, down, left, right, left, right...
Now I know you're not suggesting that Mozart's Requiem shouldn't be available to the public, purely on the basis that you don't like it that much. So what are you saying?
I'm quite happy to be able to listen to his final, unfinished work.
---
'Fruity smells are what I like'
Debbie Gibson
I'm betting you'll need a godly connection to be able to get those kinds of graphics.
Yep, I'm sure you'll also need a pretty good video-card to get the full audio experience. And I'm sure anyone with a cheap soundcard will get terrible pings.
Wow, my experience of it is pretty much the opposite of yours. Unlucky, dude.
Yes, we work stupid hours with no overtime at my place when it's needed. But I find my co-workers all have their egos in check and they keep mine in check too. We don't document code much, we just communicate well. Coders have plenty of say in the creative process. Yes, publishers are a gigantic pain in the arse, but that's what management is there for - they deal with it and filter out the worst of it.
All in all, it's a shitty job and not worth the effort.
In terms of salaries, I totally agree that it's not worth the effort - you could make a hell of a lot more money with the equivalent skills elsewhere. But where else could I find a job where:
- I can wander into work at 11.00 in casual clothes
- The company has a budget for buying cool video-games and movies and stuff
- I like and respect everyone who works there, including the guy who's nominally supposed to be my boss
- Just dreaming up a cool new algorithm or special effect is reason enough to go ahead and spend time investigating and implementing it
- The end result of my efforts is something *fun* that I can *play*
Gotta love the new data-podules it comes in too.
The same guys who decides what's morally and socially acceptable behaviour and make laws based on that. In an ideal world, that's honest polititians who work hard to accurately represent an educated, informed and fair-minded populace.
I think you seem to recall incorrectly then
Well, someone said it about something. In my imagination, if nowhere else.
Have you tried the Intel compiler?
That's not one word.
I seem to recal a Bjarne Stroustrup quote along the lines of: "I think there's a smaller, cleaner language inside C++ trying to get out", and I definitely agree (assuming I'm haven't got it wrong and am totally misquoting him). Everyone I know has picked their subset and is wary of going outside it.
No it wouldn't.
control_statement
controlled_statement
unrelated_statement
would generate a warning.
control_statement
{
controlled_statement
another_controlled_statement
}
would not.
The first example is something no sane coder would ever type in C or Perl, so the warning would almost never be issued in error. It would almost always signal either a bug or some bad formatting.
I now realize using indentation for blocking is the "right" answer
Unfortunately, along with a few others I've had the "wrong" answer burnt into my brain by years of reinforcement. Why not have the parser spit out a 'suspicious construct' warning instead? It would prevent the bugs you describe just as well, and would be one less new trick for old dogs like myself to get rewire their neurons around.
Heh, I can't believe I missed that.
I was talking about the bracketing/indentation when I said 'doesn't look like regular C/C++' though.
Most people, when skimming code, look for the indentation anyway. This leads to sometimes easily overlooked bugs like this one:
if (x 10)
x = 10;
y = 0;
Is it just me, or is that an instantly suspicious-looking piece of code? I don't think it's 'easily overlooked' at all, it doesn't look like regular C/C++ at all.
Easy to say in retrospect I suppose, but still...
---
Fruity smells are what I like -- Debbie Gibson
This is the true treasure of Slashdot; someone should start an archive.
-- "Fruity smells are what I like" - Debbie Gibson