Tim Sweeney
speaker
640 appearances
1 recordings
1 series
first heard Apr 2025
last heard Apr 2025
Tim Sweeney’s voice in public audio — every appearance, attributed to the second.
Trend
recordings per month · last 12 monthsNo recordings in the last 12 months.Older appearances are listed below; set an alert to hear about the next one.
Appearances
I'd grown up learning with Pascal as my favorite language. In order to just get maximum performance and get the latest operating system features, I had to move to C for my second game, Joel of the Jungle, a little Nintendo-style platformer. And so when I started Unreal Engine, it was on 16-bit Windows using the C programming language.
And over the course of the first year, it moved to 32-bit, using these DOS extenders and then using Windows NT, and I moved to the C++ language, and just because it simplified the code so much, went from a really complicated pile of code to a much simpler one, making that transition. And so almost the entirety of Unreal Engine development, about two and a half years of it, was all on C++, 32-bit.
Completely state-of-the-art then. Like, 32-bit protected mode was kind of a magical thing, having come from the days when computers were much less reliable and crashed all the time.
Yeah, it's because it solves all the problems at scale, often through manual pain, but always solves them. A lot of other languages do better in a lot of theoretical aspects and are better for some usage cases, but you can't do everything, and that's very limiting.
I went through a big transition there. I started out being pretty lazy. I bought used computers because you'd often get them at half the price of a new one. They'd be good enough. I had this old 486 I was developing on. I guess it was a 15-inch monitor at the time. It was a poor workstation setup, but it was very economical. As we started on Unreal, I realized that I had to write a ton of code.
I had to write at absolute maximum productivity. So I had to rearrange my entire life around delivering maximum output. And so at that point, I realized actually spending money on getting good equipment was a good investment. And we're not talking about millions of dollars here or billions if you're building a GPU farm. We're just talking about buying some basic hardware.
And so I bought the biggest CRT you could buy at the time because this was a CRT. It was 24 inches. It weighed like 100 pounds. I had back pain for a week after I installed it, but it got me 1920x1200 view in 1996. In 1996, that was pretty cool. So I upgraded to a 90 MHz Pentium and did a lot of programming on that. It was on the 90 MHz Pentium.
These were the main consumer computers at the time, and I'd optimized the Unreal Engine software render on that, which was... And Pentium was the first superscalar architecture in consumer computing. It could run up to two instructions at a time. And if you wrote your assembly code very carefully, you could get absolute maximum throughput.
So I'd gotten my texture mapping code down to six CPU cycles comprising 11 instructions. And that was required for every pixel on the screen. And that was just enough performance to deliver that. But Dell came out with these new workstations, and Intel had just launched the Pentium Pro, the first out-of-order processor.
And so I basically bought the absolute maximum configuration that money can buy. It cost $7,000. I had a gigabyte of memory in 1996. Wow. And a 200 megahertz CPU. So it tripled the speed of compiles and just made me massively more productive. So that's why I was using throughout Unreal Engine development and shipped with that.
Well, at the time, so we did most Unreal Engine development before the first real GPUs came out. And, you know, the 3D effects Voodoo won. The first GPU that actually delivered serious performance compared to software rendering. The first GPU that was really gainful came out in the end of the development, and we supported it really quickly, but it was not the target all along.
And so development was focused on just building... There are two parts of the engine, right? There's all the gameplay systems that manage the simulation and physics and so on. That's all written in very high-level C++ code. And maintainability is as much of a goal as performance, because we had to build massive amounts of systems over time.
But the one thing that was really a bottleneck was graphics. the cost of rendering a single pixel was really high. And so you had to do everything you possibly could to optimize the rendering of pixels on screen. And so we were talking about how many CPU cycles. When you say your CPU runs at a gigahertz or whatever, that's a billion instructions per second.
How many instructions do you need to run to get a pixel on screen? And so there's a constant challenge to optimize that down. And, you know, there was also a competition among all of the graphics programmers who'd often send emails, you know, like bragging to each other about what new technique they've discovered, you know, to try to get the cost down.
And Abrash's original articles took like 12 CPU cycles to render a pixel. And, Everybody else had figured out how to get it down to six or sometimes even four cycles. And that involved lots of different trade-offs of caching and memory hierarchy and so on.
It was just like a magical time where a human could actually understand exactly what the CPU was doing under the hood and could write code that exactly targeted that. And that's largely lost now. When we talk about optimization software now, it's largely about heuristics. And statistically, this memory access is likely to hit the cache. And this algorithm is faster than that algorithm.
Because CPUs now have such advanced out-of-order execution, you really can't micromanage what's happening on an instruction-by-instruction basis. You can only manage the aggregate performance of code. And so there's kind of this lost art. Some people miss it, some people don't, in which the programmer had absolute control over the machine and could work miracles in special cases if he tried.
Yeah, that's absolutely so. The optimization problems have just moved around. In a system like Nanite, the virtualized micropolygon geometry system that Brian Karras, a brilliant engineer with Epic built, was just one of those multi-year problems.
optimization efforts that required him understanding everything from the highest levels to the lowest levels of the hardware to figure out how to make this breakthrough technique work in a way that was actually maximally performant on GPUs.
Yeah, you know, with the advanced art tools we have today, it's really easy to create a scene with billions of polygons. The hard part is how to render it efficiently because you can't render billions of polygons in a frame. Basically, you want to render an image that's indistinguishable from the full detailed geometry if you rendered it at ridiculous cost.
Showing 121–140 of 640 · page 7 of 32
← Previous
Next →