This is a great overview. I don't remember having to put in padding instructions to prevent the pipeline issues mentioned here; maybe we just never ran into that. (I wrote pretty much all the R3000 code for Crash 1 and just do not recall problems like that coming up.)
To us the elephant in the room limitation of PS1 is not mentioned here as far as I could tell from a quick read-through: it had no Z-buffer. This meant that you either had to do heroic pre-computation (sort polygons ahead of time) or you ended up with lots of flickering polygons (bluedino's "jiggling and sparkling" comment below seems apt).
The other thing to note is that to make a truly high-performance game for PS1 you had to completely ditch Sony's sanctioned C APIs -- something they said would cause your game to get banned, but which we did anyway. Sony's libraries spent more time copying registers to and from the stack than they did doing the actual work, so they were a big lose.
Finally, that 2KB scratchpad was immensely powerful if you used it well. It's the only reason the 3D collision detection on Crash was fast enough; it took me 9 months to get that performant enough to ship. The CPU and RAM in those machines were just incredibly slow by today's standards.
One could endlessly debate the merits of Lisp dialects for game development, but at least in the Crash era it was a big win for us. Naughty Dog migrated away from Lisp in the PS3 era, I believe. (I was long gone by then.)
It was very powerful to be able to write code for critters and other animated objects in GOOL/GOAL because it was both conceptually simple and compiled into tiny amounts of code, which mattered a lot when you only had 2MB of RAM (half of which was video RAM if I recall correctly).
> This is a great overview. I don't remember having to put in padding instructions to prevent the pipeline issues mentioned here; maybe we just never ran into that. (I wrote pretty much all the R3000 code for Crash 1 and just do not recall problems like that coming up.)
If you were using the GNU assembler, it automatically fills branch delay slots with nop instructions unless you prefix assembly code as using `.set noreorder`. GAS would also handle load delay slots as well.
Inserting NOPs is a waste of code space and execution resources though. If resources are not too tight, this is fine.
We used gcc on a MIPS M4K in a communication chip. We had a lot of existing C code and were short on ROM and on CPU cycles. Therefore a few co-workers wrote a tool which parsed the gcc asm output to fill the branch delay slot with an instruction with no side effects on the branch. It also fixed some gcc issue with 16 bit memory accesses in C were created as 32 bit load instruction in asm (which can be two cycles if the first 16 bit of a 32 bit word are needed). I had a HW/SW cosim setup to test code and hardware (Verilog). These were cool projects. Good memories (although quite vague now).
PS: If we would have had a license of the Green Hills compiler we could have saved some of the effort. IIRC it did branch delay slot optimization.
The layout of this article seems unique, and in one of the sub-sections I think they did go into the Z-axis ordering a bit:
> Moving on, the ordering table puts the burden on the developer/program to show the geometry in the right order. In some cases, the calculations implemented rely on too many approximations to gain performance. This may result in flickering or occluded surfaces that should have been displayed.
Reverse engineering the assembly code required to drive the Geometry Transformation Engine efficiently from the compiled output of the C libraries is to this day one of my favorite technical puzzles I've worked on in my career.
I remember sitting in a meeting with our technical contact at Sony's headquarters in San Mateo where he basically asked without asking if we were using the C libraries. From the way he asked the question it was clear that the correct answer was "No, not using the libraries" since otherwise our game wouldn't be performant. At the same time we both knew we couldn't say that explicitly since that would violate Sony's contracts.
Well of course you were using the libraries! Just like you were using the documentation. Exactly like you were using the documentation, in fact. The fact that neither got jumped to as executable code is clearly immaterial.
Something I've wondered about the "sorting polygons" strategy: would sorting only part of the part of the polygons per frame been enough? (front-half vs back-half, one-bubble-sort-pass-per-frame, or some other iterative partial solution)
How often did the polygons get out of order?
(Or am I thinking only in 2D arrays when the problem is really multiple-polygon occlusion?)
I doubt it. One observation is that polygons can experience cyclic overlap, so A > B and B > C does NOT imply A > C. This transitivity property is required for O(N lg N) sorting algorithms. And note that even with Crash 1 polygon counts, O(N^2) is > 1000^2 -- way too huge for a 33Mhz processor.
However, the way I did it was to precompute the sort order of the polygons ahead of time and store periodic key frames (the complete sorted list) along with diffs. These diffs were generally very small, meaning your intuition that not much changes from frame to frame is a valid one. The problem is without the runtime oracle telling you which polygons move from frame to frame, it seems hard to exploit this property.
Another issue with approximate polygon sorting methods like bucket sorting is that the sort isn't terribly stable from frame to frame, so you get the annoying flickering effect that you see so often in PS1 games, as a pair of polygons alternates between relative sort order as you move around.
It’s not a basic question at all. If you look at the most innovative games of that era, they all found some way to not resort to O(N^2) polygon sorting. A bit before Crash came out ID Software showed that spatial data structures like BSP trees could help a lot; we were influenced by that.
> The other thing to note is that to make a truly high-performance game for PS1 you had to completely ditch Sony's sanctioned C APIs -- something they said would cause your game to get banned, but which we did anyway.
Fascinating! Was this because Sony didn't bother checking, or they saw the performance you were getting and just let it slide?
I recall that they mandated use of the C APIs to easily support future PS2 backward compatibility. I think what they ended up doing was just embedding a PS1 into the PS2, so use of the C APIs never mattered. Which was good, because by the time PS2 was out, lots of PS1 games had shipped that used the bare metal hardware, circumventing the APIs.
The problem was there was just no way to make a fast C API for things like polygon rendering, because as soon as you touched RAM (the stack) you were looking at many cycles of delay per instruction.
"I think what they ended up doing was just embedding a PS1 into the PS2, so use of the C APIs never mattered." I'm not sure on the PS2 but I know that's what they did in the PS3 - I found the 60GB launch PS3 that had the hardware PS2 embedded as well as the greatest amount of ports and maybe a few other aspects that made it one of the more sought after PS3 version. I still use it as a Bluray player and occasionally fire up Little Big Planet - still one of my favorite games.
It would have had to have been in software then; modern hardware handles Z buffer calculations for you. That would have been slow and memory intensive on the PS1.
It is emulated but you can still see a sorting failure here (the gray platform at the bottom left side of the video appears "over" the ground for a bit):
> To us the elephant in the room limitation of PS1 is not mentioned here as far as I could tell from a quick read-through: it had no Z-buffer.
There is a section "Visibility Approach" under the GPU section that starts: "Just like the competition, the PS1 doesn’t include any hardware feature that solves the visibility problem."
I agree that it doesn't really stress the ramifications of that.
> The CPU and RAM in those machines were just incredibly slow by today's standards.
I have a few questions, interspersed with my musings on them.
Based on an initial misreading of the above as the RAM being slow, I mistook your statement to mean that memory latency on a similar order to today's computers was something that you had to fight with. Was it memory latency per-se that made achieving sufficient performance hard?
Per the article, the system had EDO memory, which I discover can deliver a word read in 3 cycles for the first word of a page, and two cycles for subsequent words in the same page -- or 1 cycle for all if it is fast enough. I don't know the details of a MIPS memory access cycle, but by comparison, the 68k takes at least 4 clock cycles to pull a word off the bus. Thus, ISTM that EDO memory could keep a 68k fully supplied with data without resorting to wait states. I would hope that a MIPS processor, being a more modern design, could pull a word off the bus in a singe clock cycle, but on the other hand, I could see Sony possibly using cheaper chips with a tRAC slower than the CPUs clock period to save money.
Or, was the issue less so memory latency per-se, and more a bus utilization problem? In the article, I see that the DMA controller leaves the CPU idle while other devices are using the bus unless the CPU is making use of the scratchpad.
Re-reading your statement, that the CPU and RAM were just slow in general compared to today, I find myself wondering, how did the power of your development workstations compare to the PS1? Were you guys using high-end workstations like NeXT or SGIs, or common PCs of the era, since per the article, the SDK and development board targeted Windows 3.1 and 95?
Good questions. We were using SGI workstations which ran at 250Mhz if I recall correctly — so ~8x the PS1 CPU.
It was admittedly nearly 30 years ago but my recollection is that the only way to make anything fast on that hardware was to keep everything in registers and avoid touching memory except when absolutely necessary. It was definitely many cycles to access memory.
Oh what an amazing feeling seeing one of my articles here. Let me share you a bit of history about this one:
- A year ago, an old version of this article got shared in hn (https://news.ycombinator.com/item?id=22932134) and since then, google started positioning my site in their search results, and many forums started noticing the site. Yay!
- Fast forward, I graduated from uni, continued working on more articles in my free time, and with all the newly acquired knowledge, I decided to re-write the old PS1 article to make it much more informational and accurate - This is the one you are seeing right now.
- The rewrite wasn’t easy, though. Luckily, I found very kind and talented experts that lent me a hand, you can see them credited in the ‘Changelog’ at the end of the article. Curiously enough, we are still debating on Discord about some discrepancies regarding the main diagram shown in the article. LSI’s docs (the CPU manufacturer) and Sony’s docs contradict each other when they explain the layout of the CPU’s ‘main’ bus! But don’t worry about it, it doesn’t affect any statement in the article. It’s more of a need to have everything as accurate as possible.
Finally, I’m always open to comments, improvements, suggestions, anything really! I share the writings here (https://github.com/flipacholas/Architecture-of-consoles) to discuss improvements but you can also find my email in the site.
PS: The insight shared by developers in the parent thread is phenomenal.
> CD-ROM sub-channels traditionally store metadata, mostly to guide the drive. These aren’t user accessible and conventional readers rarely allow to manually write over them.
Maybe early CD-ROM drives couldn't read the side-channel data, but all drives (readers and burners) after a certain generation can read raw 2448 byte (2352 byte raw sector data + 96 byte subchannel data) sectors. I think Plextor drives might have been the first to support it?
> 5-stage pipeline: Up to five instructions can be executed simultaneously
Although technically correct, that's a bit misleading IMO. The instruction execution is overlapping, but you can still execute at most 1 instruction per cycle (each stage of the pipeline can only execute one instruction at a time). You need a super-scalar pipeline design to do more than 1 instruction per cycle.
> Although technically correct, that's a bit misleading IMO.
I Agree. My issue is that the other consoles also have a pipelined CPU and I'm trying not to copy-paste the same long explanation from other articles every time. So I included a link next to the PS1's pipeline description. I will try to reword it though. Thanks!
I led a small dev team to port a PC title to the original PSX. It had a physics engine that ran at 30Hz and needed to run close to isochronously to preserve gameplay.
One of the hacks we created was a limited pre-emptive multi-tasking system on the original Playstation to run our physics engine at a constant frequency. We'd asked Sony US who escalated to Sony Japan and told us it couldn't be done and we should write our code in a cooperative multi-tasking style.
We eventually figured out how to use the vertical blank interrupt to save all the registers, modify the return address to return from the interrupt to our physics code, then our physics code would run (not in the interrupt context), then restore the registers and longjmp back to the main game code which had been originally interrupted by the vertical blank interrupt.
This wasn't general-purpose pre-emption and had only fixed divisors of the screen refresh rate available, but was enough to get our physics engine to run close to isochronously.
Side note 1: our game (NASCAR Racing) was comparatively terrible and I remember being in awe of what the Crash Bandicoot, Ridge Racer, and other early PSX teams accomplished in gameplay and graphics.
Side note 2: as unconventional as the PSX was, it was positively mainstream compared to its contemporary Sega Saturn.
The physics thread (with interleaved joystick read code on PC) did have to yield back to the main/graphics thread. That was no issue in our case; I've not thought deeply about it, but it seems like the method is likely extensible to do context switches among multiple [unaware/non-cooperating] threads.
You probably know this, but for the benefit of others: this technique of using the vertical blank interrupt to run code was very common in the 8-bit (Atari/Apple/C64) era. In fact you really couldn't write a decent game without hooking the vertical blank interrupt (and often the per-scanline horizontal interrupt as well).
It's interesting that you were able to adapt this technique to PS1 hardware; does that game run properly under emulators or does it give them fits?
Indeed: that's where I learned it, having written both H/VBLANK ISRs on the beloved 8-bit Atari I grew up with. HBlank ISRs were needed to get more than 4 + 1 player-missile (sprites) to work.
I don't know if the game runs on emulators, but I know it runs correctly on a mid-generation PS3 and I'd expect that VBlank interrupt handling would be implemented by an emulator, so I'd expect it should work.
PS: Massive, massive respect for you and the rest of the Crash team. When that game came out, we couldn't comprehend how you were able to pull off that game on the same hardware we were using. Much respect (and thanks for the great gaming memories)!
> During the development of the PlayStation, MIPS was offering the R3000A series of processors.
The TMPR5900 (the MIPS chip developed by Toshiba to power the PS2) was sufficiently complex to develop that we developed a cycle-accurate simulator so Sony (and a few game developers) could start development before hardware was available.
However emulation isn't always the best approach: the PS2 (at least the first edition) implemented back compatibility by simply including a PS1 on board. That's a kind of Moore's law in that the cost of doing so had dropped so much since the original PS introduction that it was worth it.
I noticed this at a friend house, while looking for something in the garage we came across his old system and games. We could not resist taking it back into the house and setting it up.
The first thing I noticed was how long the load times were. And how noisy the machine was when reading and seeking on the discs.
The next thing was the primitive texture mapping. Polygons 'jiggling' and 'sparkling' all over the place. It reminded me of my first attempts at programming 3D graphics in VGA, before realizing what floating point (or fixed point) could do.
We tried re-living some of the classics, and after not even an hour we just shook our heads and went back to what we were originally doing.
I find that the PSX (and PS2 to an extent) look better on a legacy CRT TV, the video artifacting while still present does not appear as unsightly as it does on an modern LCD. Perhaps this is down to my nostalgia for the system
Yeah, I don't recall shimmering ever being noticeable during the PSX era, but when I see videos clips of actual PSX hardware, it stands out to the point of being highly distracting.
The shimmer and dithering are not really noticeable on CRTs. Maaaybe if you had a really fancy Trinitron or another of the last-generation ultrasharp flat screen CRT TVs, it would be noticeable, but those weren't mainstream until pretty comfortably into the PS2+ era.
Granted, I was a kid then. If you were a professional artist or something in the 90s, I'm sure you noticed.
Nah, a lot of things from that era (including filmography) just look better on the era-appropriate display hardware. CRTs have totally different properties and design considerations; trying to display content made for CRT, on LCD, often just presents the worst of both worlds.
Anything that only has analogue out really—it's only games for 360/PS3 and newer that were really designed with LCDs in mind. Anything older is best played on a CRT, although that's impractical for most people and becoming harder with every passing day.
That said, as much as I love playing old games on a CRT, I'm in a PAL region, and in today's world of high-refresh rate screens 50Hz is nausea inducing.
On the other hand, all the graphical glitching you speak of is entirely unique to the system. A whole genre of independent games has risen dedicated to replicating it. We've seen a proliferation of hundreds of "PSX style" horror games in the past few years. YouTube channel Alpha Beta Gamer [1] displays many of them (no commentary).
“Whatever you now find weird, ugly, uncomfortable and nasty about a new medium will surely become its signature. CD distortion, the jitteriness of digital video, the crap sound of 8-bit - all of these will be cherished and emulated as soon as they can be avoided. It’s the sound of failure: so much modern art is the sound of things going out of control, of a medium pushing to its limits and breaking apart. The distorted guitar sound is the sound of something too loud for the medium supposed to carry it. The blues singer with the cracked voice is the sound of an emotional cry too powerful for the throat that releases it. The excitement of grainy film, of bleached-out black and white, is the excitement of witnessing events too momentous for the medium assigned to record them.” ― Brian Eno
Perhaps lack of distortion? I remember some DJ friends from back in the day saying that CDs sound more "sterile" than vinyl (this was late 90s/early 2000s).
I'm not sure it is unique. The problem with the PSX is the lack of a z buffer and affine texturing. Those certainly weren't unique limitations in the 90s.
Your citation contradicts itself. The polygon jitter exists for lack of floating point unit. While it's possible to emulate the necessary precision, it's uneconomical without the acceleration provided by a dedicated processing unit. Without floating point, the PSX isn't fast enough to render complex scenes in real-time accurately; Hence the jitter.
I don't mind being wrong and I will correct the article if needed. That being said, I'm interested in debating this, what if the PS1's GPU had implemented some sort of sub-pixel precision and edge antialiasing? Do you think the lack of floating-point vertex coordinates would have been noticeable? (I'm assuming the 'jitter' means the sudden jumps when polygons move slowly).
I'm not sure why you think the "Models/textures flicker due to lack of Z-buffering" is not accurate. I mean, sure, models/textures can flicker for other reasons too so technically that can be inaccurate but lack of z-buffer is one of the most common reasons since the majority of 3D games software relied on z sorting polygons that couldn't always be sorted perfectly (static geometry could be preprocessed with, e.g., a BSP tree, but as long as dynamic geometry entered the picture things became much hairier).
Or is it that it isn't a problem of PS1 but a problem of games - which, again sure, this might be true but that'd be the splittiest of hair splitting :-P it is the lack of a hardware feature that drove the games do what they do, so it isn't entirely "blameless".
> Or is it that it isn't a problem of PS1 but a problem of games
Yes, this is what I wanted to emphasize.
My intent wasn't to say that the 'lack of z-buffering' statement was incorrect (it's still true), but that there's a fundamental issue behind it, the visible/hidden surface determination, and now it depends on the developer's implementation. I believe this is overlooked on non-technical sites.
With this, I just wanted to make it more informative for the reader. I don't think the question is if the PS1 has a z-buffer or not. Sure, z-buffering is a solution, but there's the reasoning behind it that I wanted to transmit it to the reader.
Indeed, last year i made a 3D platform/adventure game for an MS-DOS game jam[0] and noticed that some people added it to their "PS1-styled" game lists even though it had nothing to do with PS1 :-P (nor i ever had a PS1 myself - i did buy a PS2 though a few years ago but only played a single game on it - i want to figure out a way to modchip or something so i can do some homebrew, though i dont want to mess with the hardware side of things and i hope it'll be eventually supported by FreeDVDBoot instead).
However i think the combination of lack of z-buffer, affine texturing and RGB color output with dithering was kinda unique - or at least very rarely seen elsewhere. You could see several z-buffer-less and affine-only texture mapped games on software rendered PC games, but pretty much all of them were using 8bit palettized modes. Some also used dithering (e.g. Ultima Underworld) though it was very rare.
By the time there were a few games that used RGB colors and software rendering (e.g. Unreal, Heretic 2), PCs were also powerful enough to do perspective correct texturing.
PS1 and N64 visuals have both aged poorly, though I agree, I think the PS1 is the toughest to go back to from a visual perspective. The shimmering polygons that you see on the PlayStation and on the Saturn feels unacceptable by today’s standards and then they are both also notorious for long load times.
The N64 has it’s own set of graphical limitations, but hold up a bit better to the test of time, IMO. At the time I know it was the school yard debate of which looked better and many felt the sharpness of the PS1 was preferred over the softer N64 image.
Weirdly, I think sharpness is exactly where PS1 games don't hold up. Metal Gear Solid is less off-putting to go back to than Metal Gear Solid 2. The pixely textures and dim lighting give it some atmosphere, where the extra detail in MGS2 just comes off as very plastic now.
> - Tekken 3: Very detailed character models and I think it runs at 60 FPS? Even if it doesn't, it is still impressive.
It does, at least on NTSC. On the PlayStation Mini or whatever they called it, they packed a 50FPS PAL version of the game - and as near as I ever figured out, it was because the MT chip inside of it couldn't emulate Tekken 3 at 60FPS.
Tenchu: Stealth Assasins should also be very playable still I think? At least I played it a bit recently on a PS1 emulator on a Raspberry Pi and was fun enough for me (as is Tekken 3).
I remember watching commercials for the PS1 at the time, as a member of their target audience, and I was generally underwhelmed. Even at the time, 10fps footage on TV didn't impress me and didn't compel me to want to buy one. In my opinion, it really didn't have enough power to be a 3D system. Excellent 2D system, though.
The first system that I feel like had enough power to be a 3D system without being completely terrible was the Dreamcast. It had enough power that you could target 60fps and even if you missed it, get close enough, and have enough power to draw recognizable environments and make things that could at least hide the fact they weren't made out of huge polygons, with a bit of artistry. It wasn't near obligatory to spend multiple refreshes' worth of time on a single frame to put up a competitive-looking frame. I played quite a few games on that and it was rare to see slideshows. All the 3D I've played prior to that still feels clunky to me, but playing the Dreamcast feels primitive, but workable.
It's worth revisiting some of your favourites in an emulator - these days PSX emulators can do perspective correct texturing to fix the jiggling and warping, which combined with internal upscaling makes games which were badly affected by those shimmering textures feel much more "solid".
Here's the first track in Ridge Racer Type 4, for example, which looks so much nicer without the track and wall textures wobbling about:
True, if it were a ps2 title the level would start out like that, and then suddenly open up to show off how much better they can do outdoor environments now.
For me it's the gameplay of this generation that didn't age well.
Developers were:
1. grappling with an entirely new dimension of gameplay
2. investing enormous amounts of engineering work into making 3D world run at all on these systems
And it seems to me that the result was that gameplay the gameplay for this generation at least for action-oriented titles, generally was a big step back from the 16-bit era.
There are certainly some early 3D action titles that still shine for me though. The PSX-based entries in the Tekken series and Metal Gear Solid come to mind.
It’s a minor point in the breakdown of the system, but I had absolutely no idea that the Memory Card Slots and the Controller Ports on the PlayStation were electrically identical, when I was younger I had recognised that they both had 9 contacts. But I hadn’t considered that they would be electrically the same. The only difference being in how they were addressed.
I regularly use my PlayStation instead of my PlayStation 2 for playing PS1 games, it appears to me that the video output on the PS2 while playing PS1 games is of a lower fidelity (while using an SCART lead), the output is always off centre on the PS2. I assume it’s something to do with the hardware differences in the video output between the two?
This (the linkages between the controller and the memory card) turned out to be problematic for us on Crash, actually. I've posted about this here in prior years so I won't rehash it. :)
This is an awesome article! It covers a lot of ground in a way that makes sense for people that aren't game developers or system-level engineers. I love the tabbed sections and the model viewers too.
It looks like the author, Rodrigo, has done similar articles for a bunch of other consoles which is incredible.
My Pentium from 1996 had a 133mhz processor and 8Mb of onboard EDO RAM (you could upgrade, but that’s what it came with). A 1994 machine would have been weaker, but still much stronger than PS hardware.
The PS was a specialized machine though. Don’t discount either the benefits of developing and optimizing for a single set of known hardware, rather than a wide wide array of PC hardware.
Well, the Nintendo Wii has 88MB of memory and a 730MHz single core PowerPC 750CL cpu. And yet games like Super Mario Galaxy or Skyward Sword are quite impressive considering the limited hardware.
The Last of Us for the PS3 never fails to leave in awe, Naughty Dog did some serious black magic to get those results out of the hardware they were targeting.
It's really amazing how much can be done when talented developers target specific hardware.
>Well, the Nintendo Wii has 88MB of memory and a 730MHz single core PowerPC 750CL cpu. And yet games like Super Mario Galaxy or Skyward Sword are quite impressive considering the limited hardware.
Max Payne ran on a PIII @1GHZ with 128 of RAM (not a bg step over 88MB considering W98SE could use about 32MB) and the graphics were on par to Mario Galaxy if not better.
>The Last of Us for the PS3 never fails to leave in awe, Naughty Dog did some serious black magic to get those results out of the hardware they were targeting.
It's really amazing how much can be done when talented developers target specific hardware.
Textures, textures, textures. Max Payne had amazing textures, so did most console games from Konami and such. Yet, a lot of UE1 based games had so blurry-ish and shitty textures they indeed look worse than a Game Cube game.
I am not talking about the texture size, but the quality of the artwork.
The Nintendo Wii case is an interesting one, because instead of introducing a completely new architecture, both CPU (Broadway) and GPU (GX) come from well-known Gamecube hardware (Gekko and Flipper). So I presume the existing toolkit and game's codebase were easily ported. Thus, more time could be spent in improving the quality of the game.
One can get cycle-accurate hardware emulations of 2nd (Atari), 3rd (NES) and 4th Generations (Genesis) video game consoles for FPGAs now days. I assume this is because the systems are quite simple by today's standards, even in their graphics ASICs, and even the less-simple bits have been around long enough that there's been plenty of opportunity for in-depth study.
Is something like that feasible for 5th Gen systems like the Playstation or have we crossed a threshold of complexity where if you want cycle accurate hardware, it's time to pony up the money to license the IC data from Sony and to have custom chips manufactured?
Truly excellent information, but the "tabs" that you have to click in order to read the next part is positively the worst UX I have ever seen on a static website.
The tabs were made to prevent the user from scrolling indefinitely if he/she is not interested in one section in particular. This only appears in desktop (not mobile).
I'm not a web dev though, so I don't mind switching to a better pattern. Do you know a better one?
I experimented a bit with a ToC wikipedia-style but the results didn't fit very well with the rest of the design. I'll try to allocate more time in the future to focus on the design.
Ah don't worry about that, I use Hugo which has a ToC generator. My problem is regarding the style (CSS) which I need to spend more time to make it blend better with the rest of the site. Thanks anyway!
Having a page consists of a series of "tabs" is not a very good pattern because it's not at all intuitive what is going to change (and it's only going to be part of the page) when you actually click it.
Would rather just have a table of contents with items and sub-items.
This is a great overview. I don't remember having to put in padding instructions to prevent the pipeline issues mentioned here; maybe we just never ran into that. (I wrote pretty much all the R3000 code for Crash 1 and just do not recall problems like that coming up.)
To us the elephant in the room limitation of PS1 is not mentioned here as far as I could tell from a quick read-through: it had no Z-buffer. This meant that you either had to do heroic pre-computation (sort polygons ahead of time) or you ended up with lots of flickering polygons (bluedino's "jiggling and sparkling" comment below seems apt).
The other thing to note is that to make a truly high-performance game for PS1 you had to completely ditch Sony's sanctioned C APIs -- something they said would cause your game to get banned, but which we did anyway. Sony's libraries spent more time copying registers to and from the stack than they did doing the actual work, so they were a big lose.
Finally, that 2KB scratchpad was immensely powerful if you used it well. It's the only reason the 3D collision detection on Crash was fast enough; it took me 9 months to get that performant enough to ship. The CPU and RAM in those machines were just incredibly slow by today's standards.
Thank you for this insight and special thanks for providing me and many others with this wonderful piece of childhood.
Legend. I've heard the original GOAL code is floating around somewhere online. Is there any chance Sony ever releases it into the public domain?
I notice another game today on here using ClojureScript. Apart from a lack of tooling / engine, is Lisp better suited for gamedev?
One could endlessly debate the merits of Lisp dialects for game development, but at least in the Crash era it was a big win for us. Naughty Dog migrated away from Lisp in the PS3 era, I believe. (I was long gone by then.)
It was very powerful to be able to write code for critters and other animated objects in GOOL/GOAL because it was both conceptually simple and compiled into tiny amounts of code, which mattered a lot when you only had 2MB of RAM (half of which was video RAM if I recall correctly).
I've not heard of GOAL before - do you have a link to any references or articles about it?
The OpenGOAL project is very active at reimplementing the GOAL compiler and infrastructure of Jak 1.
https://blog.jakspeedruns.com/opengoal-project-update-septem...
Looks like GOOL was an early interpreted(?) lisp/scheme, and GOAL was a later complier/compiled version?
GOOL: https://all-things-andy-gavin.com/2011/03/12/making-crash-ba...
GOAL: https://en.m.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
https://github.com/water111/jak-project
> This is a great overview. I don't remember having to put in padding instructions to prevent the pipeline issues mentioned here; maybe we just never ran into that. (I wrote pretty much all the R3000 code for Crash 1 and just do not recall problems like that coming up.)
If you were using the GNU assembler, it automatically fills branch delay slots with nop instructions unless you prefix assembly code as using `.set noreorder`. GAS would also handle load delay slots as well.
Ah yes, that makes perfect sense! I'm sure that's why I never had to worry about it.
Inserting NOPs is a waste of code space and execution resources though. If resources are not too tight, this is fine.
We used gcc on a MIPS M4K in a communication chip. We had a lot of existing C code and were short on ROM and on CPU cycles. Therefore a few co-workers wrote a tool which parsed the gcc asm output to fill the branch delay slot with an instruction with no side effects on the branch. It also fixed some gcc issue with 16 bit memory accesses in C were created as 32 bit load instruction in asm (which can be two cycles if the first 16 bit of a 32 bit word are needed). I had a HW/SW cosim setup to test code and hardware (Verilog). These were cool projects. Good memories (although quite vague now).
PS: If we would have had a license of the Green Hills compiler we could have saved some of the effort. IIRC it did branch delay slot optimization.
The layout of this article seems unique, and in one of the sub-sections I think they did go into the Z-axis ordering a bit:
> Moving on, the ordering table puts the burden on the developer/program to show the geometry in the right order. In some cases, the calculations implemented rely on too many approximations to gain performance. This may result in flickering or occluded surfaces that should have been displayed.
Comments like this are the reason I keep coming back to HN, thanks!
Thanks for your great comment.
> This meant that you either had to do heroic pre-computation (sort polygons ahead of time)
Much more detail on this is available in this amazing series of blog posts:
https://all-things-andy-gavin.com/2011/02/02/making-crash-ba...
Reverse engineering the assembly code required to drive the Geometry Transformation Engine efficiently from the compiled output of the C libraries is to this day one of my favorite technical puzzles I've worked on in my career.
I remember sitting in a meeting with our technical contact at Sony's headquarters in San Mateo where he basically asked without asking if we were using the C libraries. From the way he asked the question it was clear that the correct answer was "No, not using the libraries" since otherwise our game wouldn't be performant. At the same time we both knew we couldn't say that explicitly since that would violate Sony's contracts.
I assume you only had a disassembler to work with, at the time?
> Reverse engineering the assembly code
Well of course you were using the libraries! Just like you were using the documentation. Exactly like you were using the documentation, in fact. The fact that neither got jumped to as executable code is clearly immaterial.
Something I've wondered about the "sorting polygons" strategy: would sorting only part of the part of the polygons per frame been enough? (front-half vs back-half, one-bubble-sort-pass-per-frame, or some other iterative partial solution)
How often did the polygons get out of order?
(Or am I thinking only in 2D arrays when the problem is really multiple-polygon occlusion?)
I doubt it. One observation is that polygons can experience cyclic overlap, so A > B and B > C does NOT imply A > C. This transitivity property is required for O(N lg N) sorting algorithms. And note that even with Crash 1 polygon counts, O(N^2) is > 1000^2 -- way too huge for a 33Mhz processor.
However, the way I did it was to precompute the sort order of the polygons ahead of time and store periodic key frames (the complete sorted list) along with diffs. These diffs were generally very small, meaning your intuition that not much changes from frame to frame is a valid one. The problem is without the runtime oracle telling you which polygons move from frame to frame, it seems hard to exploit this property.
Another issue with approximate polygon sorting methods like bucket sorting is that the sort isn't terribly stable from frame to frame, so you get the annoying flickering effect that you see so often in PS1 games, as a pair of polygons alternates between relative sort order as you move around.
Thanks, really clear explanation, and thanks for taking the time to answer such a basic question. :)
It’s not a basic question at all. If you look at the most innovative games of that era, they all found some way to not resort to O(N^2) polygon sorting. A bit before Crash came out ID Software showed that spatial data structures like BSP trees could help a lot; we were influenced by that.
> The other thing to note is that to make a truly high-performance game for PS1 you had to completely ditch Sony's sanctioned C APIs -- something they said would cause your game to get banned, but which we did anyway.
Fascinating! Was this because Sony didn't bother checking, or they saw the performance you were getting and just let it slide?
I recall that they mandated use of the C APIs to easily support future PS2 backward compatibility. I think what they ended up doing was just embedding a PS1 into the PS2, so use of the C APIs never mattered. Which was good, because by the time PS2 was out, lots of PS1 games had shipped that used the bare metal hardware, circumventing the APIs.
The problem was there was just no way to make a fast C API for things like polygon rendering, because as soon as you touched RAM (the stack) you were looking at many cycles of delay per instruction.
"I think what they ended up doing was just embedding a PS1 into the PS2, so use of the C APIs never mattered." I'm not sure on the PS2 but I know that's what they did in the PS3 - I found the 60GB launch PS3 that had the hardware PS2 embedded as well as the greatest amount of ports and maybe a few other aspects that made it one of the more sought after PS3 version. I still use it as a Bluray player and occasionally fire up Little Big Planet - still one of my favorite games.
I think a late-generation ps1 game did have a z-buffer, I don't remember the one though. Blasto maybe?
It would have had to have been in software then; modern hardware handles Z buffer calculations for you. That would have been slow and memory intensive on the PS1.
It is emulated but you can still see a sorting failure here (the gray platform at the bottom left side of the video appears "over" the ground for a bit):
https://youtu.be/Qo-wX5CeDRA?t=340
So it most likely wasn't Blasto.
> To us the elephant in the room limitation of PS1 is not mentioned here as far as I could tell from a quick read-through: it had no Z-buffer.
There is a section "Visibility Approach" under the GPU section that starts: "Just like the competition, the PS1 doesn’t include any hardware feature that solves the visibility problem."
I agree that it doesn't really stress the ramifications of that.
> The CPU and RAM in those machines were just incredibly slow by today's standards.
I have a few questions, interspersed with my musings on them.
Based on an initial misreading of the above as the RAM being slow, I mistook your statement to mean that memory latency on a similar order to today's computers was something that you had to fight with. Was it memory latency per-se that made achieving sufficient performance hard?
Per the article, the system had EDO memory, which I discover can deliver a word read in 3 cycles for the first word of a page, and two cycles for subsequent words in the same page -- or 1 cycle for all if it is fast enough. I don't know the details of a MIPS memory access cycle, but by comparison, the 68k takes at least 4 clock cycles to pull a word off the bus. Thus, ISTM that EDO memory could keep a 68k fully supplied with data without resorting to wait states. I would hope that a MIPS processor, being a more modern design, could pull a word off the bus in a singe clock cycle, but on the other hand, I could see Sony possibly using cheaper chips with a tRAC slower than the CPUs clock period to save money.
Or, was the issue less so memory latency per-se, and more a bus utilization problem? In the article, I see that the DMA controller leaves the CPU idle while other devices are using the bus unless the CPU is making use of the scratchpad.
Re-reading your statement, that the CPU and RAM were just slow in general compared to today, I find myself wondering, how did the power of your development workstations compare to the PS1? Were you guys using high-end workstations like NeXT or SGIs, or common PCs of the era, since per the article, the SDK and development board targeted Windows 3.1 and 95?
Good questions. We were using SGI workstations which ran at 250Mhz if I recall correctly — so ~8x the PS1 CPU.
It was admittedly nearly 30 years ago but my recollection is that the only way to make anything fast on that hardware was to keep everything in registers and avoid touching memory except when absolutely necessary. It was definitely many cycles to access memory.
An MMX Pentium would run circles around the PSX as it could play lots of games with a 3DFX.
A Pentium Pro could run Unreal, I think. That game (and engine) basically could crush down any PSX and N64 at once.
A Pentium 2 could emulate the PSX at lowest settings.
Oh what an amazing feeling seeing one of my articles here. Let me share you a bit of history about this one:
- A year ago, an old version of this article got shared in hn (https://news.ycombinator.com/item?id=22932134) and since then, google started positioning my site in their search results, and many forums started noticing the site. Yay!
- Fast forward, I graduated from uni, continued working on more articles in my free time, and with all the newly acquired knowledge, I decided to re-write the old PS1 article to make it much more informational and accurate - This is the one you are seeing right now.
- The rewrite wasn’t easy, though. Luckily, I found very kind and talented experts that lent me a hand, you can see them credited in the ‘Changelog’ at the end of the article. Curiously enough, we are still debating on Discord about some discrepancies regarding the main diagram shown in the article. LSI’s docs (the CPU manufacturer) and Sony’s docs contradict each other when they explain the layout of the CPU’s ‘main’ bus! But don’t worry about it, it doesn’t affect any statement in the article. It’s more of a need to have everything as accurate as possible.
Finally, I’m always open to comments, improvements, suggestions, anything really! I share the writings here (https://github.com/flipacholas/Architecture-of-consoles) to discuss improvements but you can also find my email in the site.
PS: The insight shared by developers in the parent thread is phenomenal.
> CD-ROM sub-channels traditionally store metadata, mostly to guide the drive. These aren’t user accessible and conventional readers rarely allow to manually write over them.
Maybe early CD-ROM drives couldn't read the side-channel data, but all drives (readers and burners) after a certain generation can read raw 2448 byte (2352 byte raw sector data + 96 byte subchannel data) sectors. I think Plextor drives might have been the first to support it?
> 5-stage pipeline: Up to five instructions can be executed simultaneously
Although technically correct, that's a bit misleading IMO. The instruction execution is overlapping, but you can still execute at most 1 instruction per cycle (each stage of the pipeline can only execute one instruction at a time). You need a super-scalar pipeline design to do more than 1 instruction per cycle.
> Although technically correct, that's a bit misleading IMO.
I Agree. My issue is that the other consoles also have a pipelined CPU and I'm trying not to copy-paste the same long explanation from other articles every time. So I included a link next to the PS1's pipeline description. I will try to reword it though. Thanks!
Yes, with cdrdao I could read any rented PSX disc under Linux in order to "backup" it.
I led a small dev team to port a PC title to the original PSX. It had a physics engine that ran at 30Hz and needed to run close to isochronously to preserve gameplay.
One of the hacks we created was a limited pre-emptive multi-tasking system on the original Playstation to run our physics engine at a constant frequency. We'd asked Sony US who escalated to Sony Japan and told us it couldn't be done and we should write our code in a cooperative multi-tasking style.
We eventually figured out how to use the vertical blank interrupt to save all the registers, modify the return address to return from the interrupt to our physics code, then our physics code would run (not in the interrupt context), then restore the registers and longjmp back to the main game code which had been originally interrupted by the vertical blank interrupt.
This wasn't general-purpose pre-emption and had only fixed divisors of the screen refresh rate available, but was enough to get our physics engine to run close to isochronously.
Side note 1: our game (NASCAR Racing) was comparatively terrible and I remember being in awe of what the Crash Bandicoot, Ridge Racer, and other early PSX teams accomplished in gameplay and graphics.
Side note 2: as unconventional as the PSX was, it was positively mainstream compared to its contemporary Sega Saturn.
I started to read your side note 2 and immediately wondered what you would have called the Saturn but then you addressed it.
> then restore the registers and longjmp back to the main game code which had been originally interrupted by the vertical blank interrupt.
So that's really like, half preemptive with the return side really being cooperative style?
Yes, exactly (and why I described it as limited).
The physics thread (with interleaved joystick read code on PC) did have to yield back to the main/graphics thread. That was no issue in our case; I've not thought deeply about it, but it seems like the method is likely extensible to do context switches among multiple [unaware/non-cooperating] threads.
You probably know this, but for the benefit of others: this technique of using the vertical blank interrupt to run code was very common in the 8-bit (Atari/Apple/C64) era. In fact you really couldn't write a decent game without hooking the vertical blank interrupt (and often the per-scanline horizontal interrupt as well).
It's interesting that you were able to adapt this technique to PS1 hardware; does that game run properly under emulators or does it give them fits?
Indeed: that's where I learned it, having written both H/VBLANK ISRs on the beloved 8-bit Atari I grew up with. HBlank ISRs were needed to get more than 4 + 1 player-missile (sprites) to work.
I don't know if the game runs on emulators, but I know it runs correctly on a mid-generation PS3 and I'd expect that VBlank interrupt handling would be implemented by an emulator, so I'd expect it should work.
PS: Massive, massive respect for you and the rest of the Crash team. When that game came out, we couldn't comprehend how you were able to pull off that game on the same hardware we were using. Much respect (and thanks for the great gaming memories)!
Thank you so much for the kind words. We took huge technical risks and got really lucky.
> During the development of the PlayStation, MIPS was offering the R3000A series of processors.
The TMPR5900 (the MIPS chip developed by Toshiba to power the PS2) was sufficiently complex to develop that we developed a cycle-accurate simulator so Sony (and a few game developers) could start development before hardware was available.
However emulation isn't always the best approach: the PS2 (at least the first edition) implemented back compatibility by simply including a PS1 on board. That's a kind of Moore's law in that the cost of doing so had dropped so much since the original PS introduction that it was worth it.
The first gen of PS3 included a PS2 on board.
Fun to know, thanks. I was out of the "biz" by then.
Game boy advance had a game boy on board as well.
And Nintendo DS has a GBA core/CPU on board.
I believe that even the slim PS3 versions without full-blown GS+EE hardware still include the PS1 CPU somewhere in a role of IO controller.
The PSX did not age well.
I noticed this at a friend house, while looking for something in the garage we came across his old system and games. We could not resist taking it back into the house and setting it up.
The first thing I noticed was how long the load times were. And how noisy the machine was when reading and seeking on the discs.
The next thing was the primitive texture mapping. Polygons 'jiggling' and 'sparkling' all over the place. It reminded me of my first attempts at programming 3D graphics in VGA, before realizing what floating point (or fixed point) could do.
We tried re-living some of the classics, and after not even an hour we just shook our heads and went back to what we were originally doing.
I find that the PSX (and PS2 to an extent) look better on a legacy CRT TV, the video artifacting while still present does not appear as unsightly as it does on an modern LCD. Perhaps this is down to my nostalgia for the system
Yeah, I don't recall shimmering ever being noticeable during the PSX era, but when I see videos clips of actual PSX hardware, it stands out to the point of being highly distracting.
The shimmer and dithering are not really noticeable on CRTs. Maaaybe if you had a really fancy Trinitron or another of the last-generation ultrasharp flat screen CRT TVs, it would be noticeable, but those weren't mainstream until pretty comfortably into the PS2+ era.
Granted, I was a kid then. If you were a professional artist or something in the 90s, I'm sure you noticed.
Nah, a lot of things from that era (including filmography) just look better on the era-appropriate display hardware. CRTs have totally different properties and design considerations; trying to display content made for CRT, on LCD, often just presents the worst of both worlds.
Anything that only has analogue out really—it's only games for 360/PS3 and newer that were really designed with LCDs in mind. Anything older is best played on a CRT, although that's impractical for most people and becoming harder with every passing day.
That said, as much as I love playing old games on a CRT, I'm in a PAL region, and in today's world of high-refresh rate screens 50Hz is nausea inducing.
On the other hand, all the graphical glitching you speak of is entirely unique to the system. A whole genre of independent games has risen dedicated to replicating it. We've seen a proliferation of hundreds of "PSX style" horror games in the past few years. YouTube channel Alpha Beta Gamer [1] displays many of them (no commentary).
[1] https://www.youtube.com/c/AlphaBetaGamer/videos
There's also the haunted PS1 demo discs. [1] https://hauntedps1.itch.io/
There's even a Bloodborne demake for PSX. https://www.youtube.com/watch?v=YXcwpNWoR8s
“Whatever you now find weird, ugly, uncomfortable and nasty about a new medium will surely become its signature. CD distortion, the jitteriness of digital video, the crap sound of 8-bit - all of these will be cherished and emulated as soon as they can be avoided. It’s the sound of failure: so much modern art is the sound of things going out of control, of a medium pushing to its limits and breaking apart. The distorted guitar sound is the sound of something too loud for the medium supposed to carry it. The blues singer with the cracked voice is the sound of an emotional cry too powerful for the throat that releases it. The excitement of grainy film, of bleached-out black and white, is the excitement of witnessing events too momentous for the medium assigned to record them.” ― Brian Eno
>CD distortion
There is no such thing as CD distortion. Does that make the whole opinion invalid?
Perhaps they mean mp3 distortion? Many CDs were encoded as mp3?
Perhaps lack of distortion? I remember some DJ friends from back in the day saying that CDs sound more "sterile" than vinyl (this was late 90s/early 2000s).
Yeah maybe, but as a composer he should know better than that, no? Or does he rely on his engineers for that?
I'm not sure it is unique. The problem with the PSX is the lack of a z buffer and affine texturing. Those certainly weren't unique limitations in the 90s.
It also has that strange polygon jitter for lack of floating point, and no texture filtering.
The lack of floating point unit on the PS1 is commonly misinterpreted, see https://www.copetti.org/writings/consoles/playstation/#tab-5...
Your citation contradicts itself. The polygon jitter exists for lack of floating point unit. While it's possible to emulate the necessary precision, it's uneconomical without the acceleration provided by a dedicated processing unit. Without floating point, the PSX isn't fast enough to render complex scenes in real-time accurately; Hence the jitter.
I don't mind being wrong and I will correct the article if needed. That being said, I'm interested in debating this, what if the PS1's GPU had implemented some sort of sub-pixel precision and edge antialiasing? Do you think the lack of floating-point vertex coordinates would have been noticeable? (I'm assuming the 'jitter' means the sudden jumps when polygons move slowly).
I have no idea :)
I'm not sure why you think the "Models/textures flicker due to lack of Z-buffering" is not accurate. I mean, sure, models/textures can flicker for other reasons too so technically that can be inaccurate but lack of z-buffer is one of the most common reasons since the majority of 3D games software relied on z sorting polygons that couldn't always be sorted perfectly (static geometry could be preprocessed with, e.g., a BSP tree, but as long as dynamic geometry entered the picture things became much hairier).
Or is it that it isn't a problem of PS1 but a problem of games - which, again sure, this might be true but that'd be the splittiest of hair splitting :-P it is the lack of a hardware feature that drove the games do what they do, so it isn't entirely "blameless".
> Or is it that it isn't a problem of PS1 but a problem of games
Yes, this is what I wanted to emphasize.
My intent wasn't to say that the 'lack of z-buffering' statement was incorrect (it's still true), but that there's a fundamental issue behind it, the visible/hidden surface determination, and now it depends on the developer's implementation. I believe this is overlooked on non-technical sites.
With this, I just wanted to make it more informative for the reader. I don't think the question is if the PS1 has a z-buffer or not. Sure, z-buffering is a solution, but there's the reasoning behind it that I wanted to transmit it to the reader.
Anyway, that's just my opinion.
Indeed, last year i made a 3D platform/adventure game for an MS-DOS game jam[0] and noticed that some people added it to their "PS1-styled" game lists even though it had nothing to do with PS1 :-P (nor i ever had a PS1 myself - i did buy a PS2 though a few years ago but only played a single game on it - i want to figure out a way to modchip or something so i can do some homebrew, though i dont want to mess with the hardware side of things and i hope it'll be eventually supported by FreeDVDBoot instead).
However i think the combination of lack of z-buffer, affine texturing and RGB color output with dithering was kinda unique - or at least very rarely seen elsewhere. You could see several z-buffer-less and affine-only texture mapped games on software rendered PC games, but pretty much all of them were using 8bit palettized modes. Some also used dithering (e.g. Ultima Underworld) though it was very rare.
By the time there were a few games that used RGB colors and software rendering (e.g. Unreal, Heretic 2), PCs were also powerful enough to do perspective correct texturing.
[0] https://bad-sector.itch.io/post-apocalyptic-petra
PS1 and N64 visuals have both aged poorly, though I agree, I think the PS1 is the toughest to go back to from a visual perspective. The shimmering polygons that you see on the PlayStation and on the Saturn feels unacceptable by today’s standards and then they are both also notorious for long load times.
The N64 has it’s own set of graphical limitations, but hold up a bit better to the test of time, IMO. At the time I know it was the school yard debate of which looked better and many felt the sharpness of the PS1 was preferred over the softer N64 image.
The N64 is responsible for blur induced headaches, but you don't have time to complain because the game levels load nearly instantly.
Weirdly, I think sharpness is exactly where PS1 games don't hold up. Metal Gear Solid is less off-putting to go back to than Metal Gear Solid 2. The pixely textures and dim lighting give it some atmosphere, where the extra detail in MGS2 just comes off as very plastic now.
> The PSX did not age well.
Most games didn't aged well, however some of them are still impressive today considering the limitations:
- Chrono Cross: almost no loading times after the initial one.
- Crash Bandicoot: the graphics are still very charming, and there is almost no graphics 'jigling'.
- Valkyrie Profile: one of my favorite RPGs of all the time, and thanks to its 2D graphics and huge sprites it is still very good looking even today.
- Tekken 3: Very detailed character models and I think it runs at 60 FPS? Even if it doesn't, it is still impressive.
> - Tekken 3: Very detailed character models and I think it runs at 60 FPS? Even if it doesn't, it is still impressive.
It does, at least on NTSC. On the PlayStation Mini or whatever they called it, they packed a 50FPS PAL version of the game - and as near as I ever figured out, it was because the MT chip inside of it couldn't emulate Tekken 3 at 60FPS.
Tenchu: Stealth Assasins should also be very playable still I think? At least I played it a bit recently on a PS1 emulator on a Raspberry Pi and was fun enough for me (as is Tekken 3).
The PSX had beautiful 2D graphics. I'm pretty confident that any of the 2D PSX games could be released now without much modification.
I bet you played it on a modern display. Contemporary TVs tended to hide a lot of those limitations.
I remember watching commercials for the PS1 at the time, as a member of their target audience, and I was generally underwhelmed. Even at the time, 10fps footage on TV didn't impress me and didn't compel me to want to buy one. In my opinion, it really didn't have enough power to be a 3D system. Excellent 2D system, though.
The first system that I feel like had enough power to be a 3D system without being completely terrible was the Dreamcast. It had enough power that you could target 60fps and even if you missed it, get close enough, and have enough power to draw recognizable environments and make things that could at least hide the fact they weren't made out of huge polygons, with a bit of artistry. It wasn't near obligatory to spend multiple refreshes' worth of time on a single frame to put up a competitive-looking frame. I played quite a few games on that and it was rare to see slideshows. All the 3D I've played prior to that still feels clunky to me, but playing the Dreamcast feels primitive, but workable.
>> All the 3D I've played prior to that still feels clunky to me, but playing the Dreamcast feels primitive, but workable.
The Dreamcast was probably the first system I played where a 3D game looked just as it did in the arcade.
The Sega Naomi arcade system was basically a Dreamcast with more memory. It even used a GD-ROM drive.
It's worth revisiting some of your favourites in an emulator - these days PSX emulators can do perspective correct texturing to fix the jiggling and warping, which combined with internal upscaling makes games which were badly affected by those shimmering textures feel much more "solid".
Here's the first track in Ridge Racer Type 4, for example, which looks so much nicer without the track and wall textures wobbling about:
https://www.youtube.com/watch?v=BDJpmP9jfeA&t=204s
Edit: the original version, for comparison:
https://www.youtube.com/watch?v=Fk30NbG2Hx8&t=102
Except for the pixely UI elements, upscaled Ridge Racer could pass for a launch PS2 title.
And draw distance.
True, if it were a ps2 title the level would start out like that, and then suddenly open up to show off how much better they can do outdoor environments now.
For me it's the gameplay of this generation that didn't age well.
Developers were:
1. grappling with an entirely new dimension of gameplay
2. investing enormous amounts of engineering work into making 3D world run at all on these systems
And it seems to me that the result was that gameplay the gameplay for this generation at least for action-oriented titles, generally was a big step back from the 16-bit era.
There are certainly some early 3D action titles that still shine for me though. The PSX-based entries in the Tekken series and Metal Gear Solid come to mind.
It’s a minor point in the breakdown of the system, but I had absolutely no idea that the Memory Card Slots and the Controller Ports on the PlayStation were electrically identical, when I was younger I had recognised that they both had 9 contacts. But I hadn’t considered that they would be electrically the same. The only difference being in how they were addressed.
I regularly use my PlayStation instead of my PlayStation 2 for playing PS1 games, it appears to me that the video output on the PS2 while playing PS1 games is of a lower fidelity (while using an SCART lead), the output is always off centre on the PS2. I assume it’s something to do with the hardware differences in the video output between the two?
This (the linkages between the controller and the memory card) turned out to be problematic for us on Crash, actually. I've posted about this here in prior years so I won't rehash it. :)
https://www.gamasutra.com/blogs/DaveBaggett/20131031/203788/...
This is an awesome article! It covers a lot of ground in a way that makes sense for people that aren't game developers or system-level engineers. I love the tabbed sections and the model viewers too.
It looks like the author, Rodrigo, has done similar articles for a bunch of other consoles which is incredible.
https://www.copetti.org/writings/consoles/
Thanks for sharing! The next one will be about the PS3!
It’s always blown me away that the PS1 had a 33mhz chip and 2MB RAM. I know it’s a specialised machine, but still.
I think by modern standards though it’s very evident in most games, with the draw distance being so low.
The CPU lives on, in space.
?
It's a flawed comparison, but those specs seem a lot worse than PC specs at the time. The Playstation also didn't cost $2,000.
My Pentium from 1996 had a 133mhz processor and 8Mb of onboard EDO RAM (you could upgrade, but that’s what it came with). A 1994 machine would have been weaker, but still much stronger than PS hardware.
The PS was a specialized machine though. Don’t discount either the benefits of developing and optimizing for a single set of known hardware, rather than a wide wide array of PC hardware.
Well, the Nintendo Wii has 88MB of memory and a 730MHz single core PowerPC 750CL cpu. And yet games like Super Mario Galaxy or Skyward Sword are quite impressive considering the limited hardware.
The Last of Us for the PS3 never fails to leave in awe, Naughty Dog did some serious black magic to get those results out of the hardware they were targeting.
It's really amazing how much can be done when talented developers target specific hardware.
>Well, the Nintendo Wii has 88MB of memory and a 730MHz single core PowerPC 750CL cpu. And yet games like Super Mario Galaxy or Skyward Sword are quite impressive considering the limited hardware.
Max Payne ran on a PIII @1GHZ with 128 of RAM (not a bg step over 88MB considering W98SE could use about 32MB) and the graphics were on par to Mario Galaxy if not better.
>The Last of Us for the PS3 never fails to leave in awe, Naughty Dog did some serious black magic to get those results out of the hardware they were targeting.
It's really amazing how much can be done when talented developers target specific hardware.
Textures, textures, textures. Max Payne had amazing textures, so did most console games from Konami and such. Yet, a lot of UE1 based games had so blurry-ish and shitty textures they indeed look worse than a Game Cube game.
I am not talking about the texture size, but the quality of the artwork.
> Max Payne ran on a PIII @1GHZ with 128 of RAM
There was a port to the original Xbox, which had only 64 MB of RAM!
The Nintendo Wii case is an interesting one, because instead of introducing a completely new architecture, both CPU (Broadway) and GPU (GX) come from well-known Gamecube hardware (Gekko and Flipper). So I presume the existing toolkit and game's codebase were easily ported. Thus, more time could be spent in improving the quality of the game.
Ok, this article had me at "...which is a bit dense to summarise in a few sentences, so why don’t we start with some historical context?"
One can get cycle-accurate hardware emulations of 2nd (Atari), 3rd (NES) and 4th Generations (Genesis) video game consoles for FPGAs now days. I assume this is because the systems are quite simple by today's standards, even in their graphics ASICs, and even the less-simple bits have been around long enough that there's been plenty of opportunity for in-depth study.
Is something like that feasible for 5th Gen systems like the Playstation or have we crossed a threshold of complexity where if you want cycle accurate hardware, it's time to pony up the money to license the IC data from Sony and to have custom chips manufactured?
I remember building a MIPS processing from scratch in undergrad. We used SPIM to model it!
Crikey, I'd forgotten about SPIM!
We used PentiumPro PCs to run SPIM to write a VAX-subset emulator in MIPS asm. VMs all the way down :P
Truly excellent information, but the "tabs" that you have to click in order to read the next part is positively the worst UX I have ever seen on a static website.
The tabs were made to prevent the user from scrolling indefinitely if he/she is not interested in one section in particular. This only appears in desktop (not mobile).
I'm not a web dev though, so I don't mind switching to a better pattern. Do you know a better one?
FWIW I thought they were well implemented, though unique.
I think the difficulty for some readers (myself included) is that they are non-standard/different from how every other web page works.
I actually quite liked them, kind of like an extended aside.
Table of contents (made of links to sections) at the top?
I experimented a bit with a ToC wikipedia-style but the results didn't fit very well with the rest of the design. I'll try to allocate more time in the future to focus on the design.
Oh, many years ago I wrote a script to automatically generate a Wikipedia style ToC based on the semantic structure of an article.
I will find it when I get home and reply to this comment.
Ah don't worry about that, I use Hugo which has a ToC generator. My problem is regarding the style (CSS) which I need to spend more time to make it blend better with the rest of the site. Thanks anyway!
Having a page consists of a series of "tabs" is not a very good pattern because it's not at all intuitive what is going to change (and it's only going to be part of the page) when you actually click it.
Would rather just have a table of contents with items and sub-items.
There also all modeled after buildings right?