3 ms·

> Look at old game consoles (like a regular old PlayStation) and what they were able to render on what today would be laughably slow hardware. They could do it

> Look at old game consoles (like a regular old PlayStation) and what they were able to render on what today would be laughably slow hardware. They could do it because developers learned the stack inside and out. You're oversimplifying the situation and drawing conclusions from it. The PSX had dedicated hardware for geometry transforms, video decoding, sound processing, and rasterizing. The CPU was used for game logic and queuing up the render pipeline. So it's not like all PlayStation developers were doing black magic in every game, they were using a lot of dedicated hardware with well known and relatively modest and fixed constraints (NTSC/PAL, stereo audio, and relatively small frame buffers). It's interesting you picked the PSX as your exemplar because it's CPU/GPU/MDEC and audio processor were meant to be black boxes so developers didn't have to code to bare metal. The IO stack was much shorter and the OS (such as it was) was single tasking, single threaded, and didn't have any networking. Slowdowns in modern systems are much more complicated that a simplistic "inefficient code makes them slow". There's hundreds of small stupid latencies all over the place in modern systems. The USB and Bluetooth stacks are filled with little latencies, retransmissions, and just wait loops. Unless your inefficient code is full of accidentally quadratic loops it's usually compounded latencies making systems "feel slow".

p_l 5y ago
The description sounds more like PS4 than PS2 (maybe PSX was simpler - PS3 is closer to PS4 and "normal" programming). I've seen numerous examples of how involved CPU was in rendering, especially on PS2, due to special units being exposed as MIPS coprocessors. Efficient rendering meant you had to keep the pipelines happy and that could require significant amount of assembly wrangling. I remember reading about how GTA3 on PS2 was a watershed moment, because it was a proof you could use a somewhat more generic engine - whereas console programming had a heavy amount of assembly focus due to historical reasons.
- giantrobot 5y ago
  I'm sure there's plenty of people on HN with first hand experience developing for the various PlayStation models. I only know what I've read about the experience and technical tear downs. So maybe one will swoop in dropping knowledge bombs and tell me I'm wrong. The original claim was 3D worked on the PSX because of "efficiency" of the code. While I'm not claiming games on the PSX were inefficient, the hardware was designed specifically to do real-time 3D rendering. It's not like the PSX could only do 3D because everyone somehow had super deep mastery of the system. To my understanding the PSX was a big change in console development. While consoles always had some dedicated hardware (blitters, audio DSPs, etc), development was a lot of beam racing. There were no frame buffers, code ran as graphics were being drawn to the screen and during the VBI. The PSX was more like a modern system where you had a CPU and a GPU (albeit fixed function) with an OpenGL-ish drawing model. It was a far more capable 3D machine than PCs of the time that had to do all 3D work on the CPU with no acceleration. Tomb Raider on the PSX was impressive because the console only cost $300. While I'm sure Tomb Raider on the PSX wasn't inefficiently coded, the design of the PSX console contributed as much to its existence as the code. Quake on the PC on the other hand could only exist because of the developers' deep system mastery pushing generic hardware to its limits (before GPUs were prevalent).

p_l 5y ago

The description sounds more like PS4 than PS2 (maybe PSX was simpler - PS3 is closer to PS4 and "normal" programming). I've seen numerous examples of how involved CPU was in rendering, especially on PS2, due to special units being exposed as MIPS coprocessors. Efficient rendering meant you had to keep the pipelines happy and that could require significant amount of assembly wrangling. I remember reading about how GTA3 on PS2 was a watershed moment, because it was a proof you could use a somewhat more generic engine - whereas console programming had a heavy amount of assembly focus due to historical reasons.

giantrobot 5y ago
I'm sure there's plenty of people on HN with first hand experience developing for the various PlayStation models. I only know what I've read about the experience and technical tear downs. So maybe one will swoop in dropping knowledge bombs and tell me I'm wrong. The original claim was 3D worked on the PSX because of "efficiency" of the code. While I'm not claiming games on the PSX were inefficient, the hardware was designed specifically to do real-time 3D rendering. It's not like the PSX could only do 3D because everyone somehow had super deep mastery of the system. To my understanding the PSX was a big change in console development. While consoles always had some dedicated hardware (blitters, audio DSPs, etc), development was a lot of beam racing. There were no frame buffers, code ran as graphics were being drawn to the screen and during the VBI. The PSX was more like a modern system where you had a CPU and a GPU (albeit fixed function) with an OpenGL-ish drawing model. It was a far more capable 3D machine than PCs of the time that had to do all 3D work on the CPU with no acceleration. Tomb Raider on the PSX was impressive because the console only cost $300. While I'm sure Tomb Raider on the PSX wasn't inefficiently coded, the design of the PSX console contributed as much to its existence as the code. Quake on the PC on the other hand could only exist because of the developers' deep system mastery pushing generic hardware to its limits (before GPUs were prevalent).