The original PS1 was so freaking limited. 33mhz? 2mb RAM? I used to wonder how they made games work on it. But looking at them today, you can see the short draw distances and the limitations very clearly.
It had additional fixed function hardware (GPU, SPU), a vector coprocessor and a coprocessor for decoding images and video. It was made for PS1 games, it's just that Sony's C library did not initially expose the vector coprocessor, and the 2 MB RAM and 1 MB VRAM required developers to chunk resources from a 650 MB CD-ROM.
It's still magic though, isn't it? The hardware was slower and more limited, but at the same time the GPU wasn't event that much of a GPU by today's standards, for example. You had to do a lot of what modern GPUs do for you by yourself, on the CPU, sacrificing even more of what little performance it had.
A modern dev would wonder how on earth he's gonna get Node.js plus a thousand npm packages running on this so he can create a WebGL context to start making a game. ;)
"a 40MHz MIPS R3000 gets 18.1 MFLOPS, while a 66MHz 486DX2 only gets 3.1 MFLOPS. So, the MIPS is downright Pentium-class for floating-point code. For integer code, the MIPS R3000/40 manages a score of 22.6 in SPECINT89, while the 486DX2/66 gets 34.0"
So its also only "Pentium-class" for floating point math, not for integer.
It should, by nature of CISC. However, the other coprocessors on the playstation meant you weren't wasting all your CPU cycles on rendering, which was the majority of the time on a 3D game of the era.
Pentium CPU's often matched the performance of SPARC/MIPS chips clock-for-clock, at least in non-floating point operations. And at that time, almost no games use floating point anyway.
The CPU in the PlayStation is nowhere near a 90 MHz Pentium.
The CPUs in the Saturn, PlayStation, and N64 were single issue, and could execute at most one instruction per clock. The Pentium was superscalar and could execute two instructions per clock. The Pentium would likely average, for integer operations, more than four or five times the performance. Much higher for floating point.
The MIPS CPU in the PlayStation is much closer to a 486 in performance-per-clock for general purpose code. A similarly clocked 486 might win some G.P. code competitions due to better caches, but the PSX's CPU would smoke the 486 in transform and lighting, thanks to it's DSP coprocessor, and the MIPS would still have much better performance-per-dollar than the 486.
Yeah. I programmed the Amiga and it was awesome - no middleware, no crap, if somebody else's code ran better then their code was better. Same with the Atari ST.
Not sure if this applies to the Amiga, but one of the huge drawbacks to DOS was that you wrote your own video and sound drivers. It wasn't abstracted away, so you could get better performance, but it was a lot of repeated work, and it doesn't scale.
I mean, for most DOS games the "video driver" was one interrupt and start writing pixels to framebuffer at 0xa0000. Sound drivers were more complicated, but there were a ton of libraries - it's how FMod got started!
The Amiga had pretty similar hardware throughout its entire lifetime, and to some extent, later models were compatible with earlier models. The kickstart ROM included a basic hardware abstraction layer. Of course most game developers largely ignored it. Compatibility is maintained using software like WHDLoad to patch games where the software makes too many assumptions about the hardware.
There's nothing inherent about DOS that prevents code reuse. For example, network stacks and audio drivers were commonly reused, and also graphics APIs like Glide and BGI, not to mention game engines. Either way, writing a soundblaster driver seems like peanuts compared to the work I imagine goes into the rendering pipeline of a modern AAA game.
It does scale in the sense that matters to a game publisher; you build it once and then you sell a million copies. The bigger the expected number of sales, the more time you can spend reinventing a more refined, custom-tailored wheel, and the simpler the wheel the tools inspire, the less time you have to spend on it. Amiga and old DOS games were probably just at just the right point where extensive reuse didn't pay off. Hardware wasn't very complex and for games like Doom it had to be a first class consideration for the product to perform well enough.
I always wonder about how the hell DOOM ran at 30 fps on a 33 Mhz system.
320 * 200 pixels @ 30 fps means they needed to calculate 1,920,000 pixels per second. With a 33 Mhz CPU, that's ~17 clock cycles per pixel, and that doesn't account for time to handle game logic.
I know it's not a true 3D engine, and the status bar took up a good amount of space, but even accounting for that, you still don't get a lot of clock cycles.
It can only draw horizontal floors and vertical walls (so the map is essentially 2D even though it is drawn in 3D). The player also cannot tilt their head sideways.
As others noted, it only supported horizontal walls and floors. More specifically, though, it only supported _one_ gap (e.g., a single window or door). You couldn't stack floors on top of each other.
This allowed a single ray cast against the 2D map to learn which vertical slices of wall texture to paint (no pitch or roll, remember). Floors and ceilings could be painted in vertical order (above / below the horizon line - "floor" and "ceiling" being explicit for any given open area), iirc, and walls filled in based on the ray cast from the eye.
> I always wonder about how the hell DOOM ran at 30 fps on a 33 Mhz system.
It didn't. It ran at ~25 FPS on a 66 Mhz 486 and only ~15 FPS on a 33 Mhz system. It needed a Pentium to reach half the refresh rate, which was 35 FPS at the time.
> 320 * 200 pixels @ 30 fps means they needed to calculate 1,920,000 pixels per second. With a 33 Mhz CPU, that's ~17 clock cycles per pixel, and that doesn't account for time to handle game logic.
GPUs, even the primitive PSX one, will draw many in a single CPU cycle. I can't find information on the PSX GPU fill rate but I'm sure it's faster than 1 pixel per CPU cycle.
DOOM didn't use the GPU to draw the walls/floors as triangles but did use the GPU to draw the scene as vertical strips. DOOM also relied on the 1Kbyte "scratchpad RAM" which was the CPU cache mapped into the address space and not subject to DMA delays.
> GPUs, even the primitive PSX one, will draw many in a single CPU cycle. I can't find information on the PSX GPU fill rate but I'm sure it's faster than 1 pixel per CPU cycle.
GPUs do it via massive parallelization.
> DOOM didn't use the GPU to draw the walls/floors as triangles but did use the GPU to draw the scene as vertical strips. DOOM also relied on the 1Kbyte "scratchpad RAM" which was the CPU cache mapped into the address space and not subject to DMA delays.
In the days of DOOM, did the video card even offer any sort of acceleration? I was under the impression that all the texture scaling was done on the CPU. So while it rendered walls as vertical strips, it would still have to interpolate across the strip on the CPU.
There's a misunderstanding about which version of Doom people are talking about. I think you're talking about the PC version while the person you replied to was talking about the PS1 version.
>GPUs, even the primitive PSX one, will draw many in a single CPU cycle. I can't find information on the PSX GPU fill rate but I'm sure it's faster than 1 pixel per CPU cycle.
Two pixels per cycle for flat shaded or rectangular primitives. Add another cycle for color interpolation, and another for on-cache texture reads (divided by how many texels are packed into 16 bits). The GPU is clocked around 53MHz so the range of 'many' here is roughly 1 to 4, ignorning that a CPU renderer would probably write two pixels at once. The CPU is also hampered by main memory reads taking a minimum of 5 cycles. Pipelining helps a little but extensive scratchpad use, such as putting the stack on it, was essential.
DOOM PSX did use triangles for the walls, just that they were a single pixel wide.
What always impressed me about Doom was the dynamic shading/lighting effects they managed in a 256-color mode.
The "3D" part wasn't any more impressive than Wolfenstein3D was, which was running on significantly slower PCs.
I dabbled in PC demo programming at the time, the limited color palette was a major challenge for me in attempting shaded texture mapping. Once we had ubiquitous "TrueColor"/"DirectColor" RGB modes, the shading challenges became trivial.
Doom made clever use of a finite colorspace. When I tried recreating some of that myself it became rather obvious why Doom's palette was so muted and basically dark gray/brown/green gradients they could then illuminate. But it worked very well for Doom.
- doom doesnt operate on pixels, it operates on constant-z planes (lines), you can scale linearly inside those (cheap 2D operation).
How Carmack did it? He cheated by deciding to never look down/up or draw slopes :) 'HandmadeCon 2016 - History of Software Texture Mapping in Games' https://www.youtube.com/watch?v=xn76r0JxqNM
Chris Hecker (Microsoft/Maxis/etc): that's a classic Carmack thing which is like Fuck those general problems, Im gonna solve this other problem perfectly
John Miles (ORIGIN/Miles Design/etc): Its all about not doing the math, we were still at a point in time when you won by not doing the math
If you want to see this sort of brilliant hacking on a modern system, I recommend taking a closer look at Unreal Nanite. It isn't just auto-LOD. Oh no. That's the core, but they had to do this same sort of "work around the tools they are given" to make it actually happen. Tiny triangles chug in modern GPU hardware raster pipelines -- so they wrote a GPGPU software rasterizer. They needed more bandwidth, so they wrote a compression engine. Their shaders needed better scheduling, so they abused the Z-test to do it. It's nuts!
43 comments
[ 2.8 ms ] story [ 104 ms ] threadA modern dev would wonder how on earth he's gonna get Node.js plus a thousand npm packages running on this so he can create a WebGL context to start making a game. ;)
https://www.vogons.org/viewtopic.php?t=56207 "Finding an IA-32 CPU most like the MIPS R3000A"
"a 40MHz MIPS R3000 gets 18.1 MFLOPS, while a 66MHz 486DX2 only gets 3.1 MFLOPS. So, the MIPS is downright Pentium-class for floating-point code. For integer code, the MIPS R3000/40 manages a score of 22.6 in SPECINT89, while the 486DX2/66 gets 34.0"
So its also only "Pentium-class" for floating point math, not for integer.
The CPUs in the Saturn, PlayStation, and N64 were single issue, and could execute at most one instruction per clock. The Pentium was superscalar and could execute two instructions per clock. The Pentium would likely average, for integer operations, more than four or five times the performance. Much higher for floating point.
The MIPS CPU in the PlayStation is much closer to a 486 in performance-per-clock for general purpose code. A similarly clocked 486 might win some G.P. code competitions due to better caches, but the PSX's CPU would smoke the 486 in transform and lighting, thanks to it's DSP coprocessor, and the MIPS would still have much better performance-per-dollar than the 486.
The original C64 was so freaking limited. 1 MHz? 64KB RAM?....
The original 48K was so freaking limited. 3.5 MHz? 48KB RAM?....
It is a matter to know the tools and hardware.
I kind of miss those days.
Not sure if this applies to the Amiga, but one of the huge drawbacks to DOS was that you wrote your own video and sound drivers. It wasn't abstracted away, so you could get better performance, but it was a lot of repeated work, and it doesn't scale.
There's nothing inherent about DOS that prevents code reuse. For example, network stacks and audio drivers were commonly reused, and also graphics APIs like Glide and BGI, not to mention game engines. Either way, writing a soundblaster driver seems like peanuts compared to the work I imagine goes into the rendering pipeline of a modern AAA game.
It does scale in the sense that matters to a game publisher; you build it once and then you sell a million copies. The bigger the expected number of sales, the more time you can spend reinventing a more refined, custom-tailored wheel, and the simpler the wheel the tools inspire, the less time you have to spend on it. Amiga and old DOS games were probably just at just the right point where extensive reuse didn't pay off. Hardware wasn't very complex and for games like Doom it had to be a first class consideration for the product to perform well enough.
320 * 200 pixels @ 30 fps means they needed to calculate 1,920,000 pixels per second. With a 33 Mhz CPU, that's ~17 clock cycles per pixel, and that doesn't account for time to handle game logic.
I know it's not a true 3D engine, and the status bar took up a good amount of space, but even accounting for that, you still don't get a lot of clock cycles.
This allowed a single ray cast against the 2D map to learn which vertical slices of wall texture to paint (no pitch or roll, remember). Floors and ceilings could be painted in vertical order (above / below the horizon line - "floor" and "ceiling" being explicit for any given open area), iirc, and walls filled in based on the ray cast from the eye.
It didn't. It ran at ~25 FPS on a 66 Mhz 486 and only ~15 FPS on a 33 Mhz system. It needed a Pentium to reach half the refresh rate, which was 35 FPS at the time.
https://youtu.be/HNlcZetLzY8?t=209
- Everything that wasn't a room was a 2d sprite
- Very limited lighting effects
- An effectively 2d environment
It's still impressive. It's just that 3d games weren't "ready" until the Quake II/Unreal/PS2 era.
GPUs, even the primitive PSX one, will draw many in a single CPU cycle. I can't find information on the PSX GPU fill rate but I'm sure it's faster than 1 pixel per CPU cycle.
DOOM didn't use the GPU to draw the walls/floors as triangles but did use the GPU to draw the scene as vertical strips. DOOM also relied on the 1Kbyte "scratchpad RAM" which was the CPU cache mapped into the address space and not subject to DMA delays.
GPUs do it via massive parallelization.
> DOOM didn't use the GPU to draw the walls/floors as triangles but did use the GPU to draw the scene as vertical strips. DOOM also relied on the 1Kbyte "scratchpad RAM" which was the CPU cache mapped into the address space and not subject to DMA delays.
In the days of DOOM, did the video card even offer any sort of acceleration? I was under the impression that all the texture scaling was done on the CPU. So while it rendered walls as vertical strips, it would still have to interpolate across the strip on the CPU.
Two pixels per cycle for flat shaded or rectangular primitives. Add another cycle for color interpolation, and another for on-cache texture reads (divided by how many texels are packed into 16 bits). The GPU is clocked around 53MHz so the range of 'many' here is roughly 1 to 4, ignorning that a CPU renderer would probably write two pixels at once. The CPU is also hampered by main memory reads taking a minimum of 5 cycles. Pipelining helps a little but extensive scratchpad use, such as putting the stack on it, was essential.
DOOM PSX did use triangles for the walls, just that they were a single pixel wide.
The "3D" part wasn't any more impressive than Wolfenstein3D was, which was running on significantly slower PCs.
I dabbled in PC demo programming at the time, the limited color palette was a major challenge for me in attempting shaded texture mapping. Once we had ubiquitous "TrueColor"/"DirectColor" RGB modes, the shading challenges became trivial.
Doom made clever use of a finite colorspace. When I tried recreating some of that myself it became rather obvious why Doom's palette was so muted and basically dark gray/brown/green gradients they could then illuminate. But it worked very well for Doom.
- doom doesnt operate on pixels, it operates on constant-z planes (lines), you can scale linearly inside those (cheap 2D operation).
How Carmack did it? He cheated by deciding to never look down/up or draw slopes :) 'HandmadeCon 2016 - History of Software Texture Mapping in Games' https://www.youtube.com/watch?v=xn76r0JxqNM
Chris Hecker (Microsoft/Maxis/etc): that's a classic Carmack thing which is like Fuck those general problems, Im gonna solve this other problem perfectly
John Miles (ORIGIN/Miles Design/etc): Its all about not doing the math, we were still at a point in time when you won by not doing the math
https://www.youtube.com/watch?v=JK1aV_mzH3A
https://www.youtube.com/watch?v=gRzKAe9UtoU
https://www.youtube.com/watch?v=eviSykqSUUw