I may have misunderstood. I’m a level designer so, yeah.
I think it depends on which audience you think of here. The middleware developer is excited because it lifts the constraints of existing 3D APIs and lets them implement all the snazzy effects that would have been difficult otherwise, but the high-level game developer still wants the nice, neatly-packaged engine that hides away all that work so he doesn’t have to do it himself. It’ll just become a marketing bullet point when the first guy tries to sell it to the second guy.
Those concerns would seem to directly contradict the proliferation of shovelware titles on the Wii platfrom.
I agree that the simple graphics may not be the only variable, but working the Wiimote use into the design of the game isn’t an obstacle to people more interested in churning out simple titles with low overhead to get at the demographic pie. You don’t have to take advantage of the Wii mote’s capabilites at all. Simply freeing up programmer’s time from graphics code doesn’t necessarily mean we’ll get more compelling gameplay.
I heard similar arguments back when the 3Dfx chips were hitting the market. “Hey, the processors will now be freed up to do all the heavy AI stuff while the graphics chip can do all the visual heavy lifting!” As with most automation-will-ease-our-lives predictions, this did not turn out to be strictly true. What we got in most cases was more pressure and budget on the graphics side of the house compared to actual gameplay.
I like my eyecandy as much as anyone. I’m not foolish enough to say that “gameplay trumps graphics” all the time, but I do know that I’m still waiting for all this incredible leapfrogging of game AI and processes that was predicted years ago thanks to the new 3D wonderland.
You seriously think anyone here doesn’t already know that?
Strike Commander (not really award winning, but the first to do texture mapping
Microprose’s F-15 3 beat SC to the punch, and was Origin pissed
Not mine. I always use shutter glasses. It really makes the sprite-based games stand out :)
I would argue that it has improved, but that graphics leaps have increased our expectations of what constitutes an “improved” AI. And 3D added a lot of complexity; doing pathfinding in 3D is an order of magnitude harder than it was in 2D.
Don’t be too impressed. The water and windows look way better, but most of the rest of the game doesn’t. It ran at “14-29 fps” at 1280x720 on a 16-core system (4 CPUs with 4 cores). That’s a massive amount of cost, electricity, heat, etc. for a reduction in performance of about 10X over a sub-$200 graphics card (at that res with max settings you get easily 150+ fps on a Radeon 4850) with the game’s regular native renderer. We’re a long way from ray tracing providing the kind of performance-to-quality tradeoff to be worthwhile. If you were going to blow 10X your performance with more traditional DX10 rasterization techniques you’d have much better overall image quality.
As for the article:
I think Tim wants this thing to happen so much that he keeps jumping the gun on predicting it. Yeah, I think he’s right that the ordered-triangles rendering approach with programmable shaders thing is eventually going to go away. I think we are, realistically, 3-4 years from the first AAA game to do that (that’s being pretty generous). Much of it may depend on the next generation of consoles.
Current rendering approaches for games have a lot of drawbacks, compared to having single homogeneous processors that can handle graphics as well as lots of other game code. Right now, the CPU has to keep a “low fidelity” copy of the world (essentially) in memory and use it to process collisions and physics and AI and all that stuff. That has consequences that are so prevalent in games that we don’t even notice them anymore. Push your character next to a wall in a game - why doesn’t your character touch it? Why doesn’t every relevant polygon of your character exactly touch the wall before stopping? Why do bits of hair or armor or weapons clip through other parts of your character? The answer is because the polygon mesh used for rendering isn’t the one used for collision detection (or many animation blending tasks, etc). Moving all this data to the same processor - most of your fundamental game tasks plus the graphics rendering - solves that problem. Everything used to draw the scene could be used to calculate collisions and physics and animation, and you’d have the kind of “fidelity of movement” you only get in pre-rendered scenes today.
And there are lots of other examples of ways you could make games not just “prettier” but more precise and immersive with the kind of change Sweeney’s talking about.
But specialized processing legacies can be hard to get rid of. You need to reach a point where your “highly generalized” processor is so good at the old DirectX/OpenGL style rendering that you don’t sacrifice existing games for the sake of new ones. And there are certain parts of the rendering pipeline today that are so much faster (per square millimeter) in a fixed function block that you simply couldn’t do it in software no matter how clever you are, without building a bigger, more expensive GPU/CPU. Even Larrabee has a fixed function texture address and filtering block, for example.
So you need a GPU/CPU chip where the fixed function parts are a relatively small part of the silicon but still sufficient to run the legacy stuff faster than the previous generation of GPU/CPU. And you need a more general, and higher performance, chip than the current 1 teraflop GPUs. With better cache structures. And you need to figure out the software language problem (you need something non-proprietary).
The next generation of consoles could really bootstrap the whole process, since they’re closed systems. If Xbox 720 (or whatever) has a big 'ol 256-core Larrabee 2 in it, you’ll have early games developed using DirectX 11 on PCs before the real hardware is available, maybe with a few tricks. But then the 2nd wave of games could use voxels or really any weird thing they want. Developers could step away from traditional rendering schemes on their own timetable, and the guaranteed market the consoles provide make it easier to risk doing a “non DirectX/OpenGL” PC game, helping along the transition.
If the next-gen consoles don’t provide silicon that is sufficiently fast at these new software rendering techniques to produce prettier games, the whole transition could be sidetracked for another 6 years as developers are loathe to build engines that won’t run optimally on consoles.
The power and flexibility of pure software rendering is enticing, yet I can’t help but feel that 3D graphics is about to experience some of the silliness we’ve been going through in the 2D video arena for the past 15-20 years. It’s been a pendulum effect, swinging between software and hardware. And when things swing back to the software side, senior staff would eagerly declare “We’re a software company now!”, thinking that complex, dedicated hardware was a thing of the past. And they were wrong every time. And always for reasons that should have been obvious, but which were conveniently ignored by the allure of trimming off all that complex, expensive, fixed-function hardware.
In the beginning, all you could do was grab single frames. The ISA bus couldn’t handle the data rate of live video. Then they added codecs to the hardware, allowing compressed video to be captured in real time (at very low quality). Suddenly editing video on a computer was possible. Offline rendering was slow, but software become important. The pendulum swung one way, then back again.
Then real-time editing became possible, and everyone wanted to edit their video interactively. Giving rise to a new generation of more powerful video cards. But the arrival of Pentiums, MMX, and other optimizations allowed video to be edited in real-time as well. As a low-res proxy, running only a few FPS. If you wanted to do anything elaborate (hello, MTV-style 100+ layer edit timelines), rendering was still the only option. The pendulum swung further this time, and then back.
The amateurs could get away with software, but the pros demanded more powerful hardware. Then we had P4’s, 64-bit 667MHz PCI (and then PCI-X, and then PCI-express), and suddenly editing full-res, full frame-rate video became possible. You could do whatever you wanted, and if it was too much, you just needed a faster computer (or multiple processors). And computers could only get faster! “We’re a software company now!” It was a foolish thing to say – it hurt more than a few companies, including the one where I worked. The pendulum swung too far, arguably, and people we not paying attention.
Then the pendulum swung back. HD finally arrived. Oh sure, it’d been around for quite awhile, but it just never went anywhere. Things changed. HD became a reality. Editing 720x480 30fps video is one thing, 1920x1080 60fps is a whole 'nother beast. It’s the difference between 20MB/s and 150-250MB/s. Hardware became important once again. And those companies that had walked away from integrated hardware support suffered. Especially those who had purged their hardware groups, thinking all they would ever need were software people. When the pendulum swung back, more than a few companies were hurt bad. A few didn’t survive – though the post-dot-com tech industry slump contributed quite a bit.
And now that Core2 is here, companies have been banging the software drum again, happy to dance in the path of the pendulum.
So while I like that a more flexible, software-oriented appoach to rendering is on the horizon, I view it as a battle-scarred veteran of the video industry. Always paranoid, expecting the relentless swing of the pendulum, even if I can’t see it. And I’m not alone. Having the pendulum swinging to and fro every couple of years, many of us in the industry are wary of it. We’re aware of it. Yet there’s no shortage of bright, shining eyes eager to bet their companies on the pendulum stopping and never moving again.
I say this because I can’t help feeling that the 3D graphics industry is about to get clobbered by the software/hardware pendulum. It’s had a solid decade now of hardware getting better and better. In a way, it’s about to turn into a software industry. Obviously, I’m wary of any such declaration. Hardware is too important, too integral to graphics. How many companies are going to bet on the whole industry turning into a pure software endeavor? How many are going to get caught in the path of the pendulum?
We had a long thread a few months back, with plenty of agreement that multi-threading is hard. Really hard. Larabee is going to be a nightmare of multithreading, deadlocks, communication, memory contention, bus activity. There are many things it can get wrong. And there are so many things you lose when you ignore hardware: vectorization, DMA, batched bus transfers… Software is flexible, hardware is fast.
I think the industry will learn some valuable lessons from trying to use Larabee for graphics. (Much as it has learned some painful lessons from PS3/Cell.) But my gut feeling is the industry will experience a swift return of the pendulum – the first since the arrival of 3D acceleration. Whatever comes a few years down the road, after Larabee and CUDA have been internalized, will probably be more hardware focused, more powerful, and impressive. But will it be programmable by a human? Will it require some meta compiler-compiler to program? Or will it be a huge block of processors sitting idle, blocked by bus contention and poorly laid-out mutexes?
Maybe I’m wrong. Maybe the 3D industry is travelling a different road. Yet the most impressive achievements have been born from the tension of hardware and software. I’m leary of this rise of software. It excites me, but I’m always wary of that pendulum.
“We’re a software company now!” I’ve heard that rallying cry three times now. At three different companies. I dread the next time I hear it. I hate job hunting.
So I’m left to wonder. Is 3D graphics about to learn the painful lesson we’ve been re-learning every 2-3 years in the video industry?
Dead Rising.
I look at it a lot like computer audio. It was all software stuff at first, and it sounded awful but you could make some neat noises. Then you had FM synthesis hardware, so it was still very much a software thing but with a hardware “acceleration” layer. Then you used hardware to mix and shift pre-recorded sound samples. The samples and mixing got richer and dedicated audio hardware was the only way to make it sound good.
But we got to a point where the limits were more creative than fidelity related, and CPUs got fast enough to deliver “good enough” quality. So now audio hardware is mostly just a CODEC to do translation to and from analog but all the real processing is on the host. At least, for most of the world.
3D graphics is a LOT more complicated, with a much higher fidelity ceiling, and a bigger cost piece of the game (in labor and money), and we’re still not to the point where the software solutions are “good enough” to compare at all to the dedicated but inflexible hardware. So the timeframe is longer, but I think fundamentally the same thing is going to happen. Eventually.
It’ll be at least the 32nm manufacturing process generation before real top-tier 3D games with generalized “software” based engines ship. And possibly the 22nm generation.
I remember in 1998 or so when he was talking about Unreal and MMX making dedicated 3D hardware obsolete. He has talked about how far off he was – but here he’s getting closer: the derivative of today’s GPU is going to obsolete the CPU. I guess you could say that about either side in a merge, though.
Another classic example is LISP machines. General purpose hardware can win over specialized hardware for economic reasons: more people will buy it, so more effort is made into improving it.
Same story with regard to CMOS over bipolar transistors. CMOS was cheaper and hence more popular, and now they use it for applications where bipolar transistors used to be dominant.
Anything that gets us closer to a Voxel future is fine by me. Voxels are so goddamn neat.