Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
The Polygons of Doom: PSX (fabiensanglard.net)
181 points by anyfoo on Sept 28, 2020 | hide | past | favorite | 29 comments


The game "Disruptor" by Insomniac is arguably way more "technically" impressive than DOOM on PS1. It has million polygon levels where as IIRC DOOM's levels are on the order of 2k to 3k polygon

https://www.youtube.com/watch?v=umZg7RFVm-A

Gameplay-wise though it was missing someting.


Interesting title. I would argue the level design is better than DOOM as well.


Another great PSX 3D engine would be the Quake II port done by Hammerhead. It's more of it's own engine rather than a port, but it looked amazing for the time, and still does.


Is Doom PSX a 'great' PSX 3D engine? Or is it just a decent 3D engine with a popular game attached.


IMO it's just very well executed. The job was to get Doom's sprites and level geometry onto the PSX, and this happened in time for 1995's holiday season.

PlayStation Doom had fewer framerate issues than most console Doom ports, and some nice extras (colored lighting). It preserved the aspects of the engine that Carmack valued most: subpixel correctness, perspective correct texture mapping, and diminished lighting.


Alien Resurection is another one. It came at the tail end of the generation and was technically impressive.


This entire website is fantastic. There is so much detail to be had and the articles are very readable.


Agree. I learn so much about programming by reading how he dissects old game programming techniques on relatively limited hardware. His piece on the Doom flames is incommensurate.


If you don't know it yet, https://www.flipcode.com/ is also a great source of information. It comes from era of early 3D realtime graphics, when everyone was making their own engines using early Direct3D, OpenGL and Glide APIs. A lot of those articles aren't relevant anymore, but they show many algorithms that were used in that period of time.


> A lot of those articles aren't relevant anymore, but they show many algorithms that were used in that period of time.

I would actually argue the inverse. There are many articles that are still very relevant, some just don’t realize it since modern engines abstract the logic away. But there are some developers that work in engines that still need that knowledge. BSPs, VFSes, raytracing, 2d blitting techniques, 3D mathematics, etc are all still very useful.

This is one of the reasons I’m so glad these archives have stayed online for so long.


I first wanted to make a raycaster for fun and to learn more about it, and now I'm making a game enhancing the Rise of the Trian engine (itself an enhancement over the Wolfenstein 3D engine) while still meeting original system requirements (386, 4MB RAM free). Fabien's site and flipcode have both been essential in my journey, I appreciate them both immensely.


Awesome! I just got into game programming, and I've been looking far and wide for a resource like that one. Google has only provided a ton of blogspam, but I knew there was some old 90s looking website somewhere filled with code and handcrafted images about vector math and other game engine tricks.


Bookmarked and I will visit later. Thank you!



> The major argument is somewhat philosophical. I don’t like what people expect out of CD games. Does anyone think that the cheeseball dialog in crash and burn is a GOOD addition? It turns my stomach. People expect CD games to have tons of digitized speech and video, and the 3DO is going to be strongly associated with it. The joke here is that if we ever do a CD version of DOOM, you are going to get the game and “The Making of DOOM” a one hour feature film. Companies spend hundreds of thousands of dollars putting all this media into their games, and it often actually detracts from it. We don’t want to be part of this crowd.

> I would rather cut down to the essentials and fit on a cartridge than uselessly bulk up on a CD. I have a minimalist sense of aesthetics in game design.

It's kind of surprising to see John Carmack have what amounts to a "640k ought to be enough for everyone" moment here. As a guy that I see as somewhat of a futurist, developing on the edge of technology, it seems strange to see him be so dismissive to the potential of the massive storage space of CDs at the time.


It seems more like a stylistic choice and preference of prioritizing gameplay over other elements of a game.

It's in line with similar other comments he's made, e.g. "Story in a game is like story in a porn movie. It's expected to be there, but it's not important."

It's not so much that he didn't think CDs brought advantages and new options to games, but that the aspects of games that they were commonly used for were, at that time, unappealing to the kinds of games he liked to play and make.


It seems to me his main problem is that the medium brings expectations, and those expectations aren't healthy for the game itself.

The same way that online updating/patching is inherently superior to master-copy, but it also generates a culture of poor QA if you're not specifically fighting it.

Or another way: now that we have 1TB HDDs, game data is actually becoming 10% logic, and 90% assets -- namely cutscenes and voice acting and etc. The problem Carmack was complaining about has only intensified since.


It's a assessment calibrated towards his goals at the time, which were focused on getting fast real-time images. It was only a little over a decade later that he was getting excited about "Megatextures" because he saw the possibility of streaming everything in - but he was always firm about getting the result at a high framerate, in a way that produced few compromises for game design.

And this is a good quality for developers generally speaking and game developers especially. It's easy for a game to get away from a principled result and just throw in even more smoke and mirrors because the justifications come so easily: "It's just a game", "nobody will notice" etc. And that is exactly the kind of justification that crept in with CD-driven game design that focused only on quantity of bits used. A lot of what filled the CD in 90's games was bad cinema and bad pre-rendered CGI.


That quote not being true aside, john carmack seems to be focusing much more on interactivity instead of mixing so much passive entertainment into a game just because it is newly possible.

I think he was absolutely right and it is impressive that he didn't get distracted from the what made video games desirable just because there were new possibilities.


> it seems strange to see him be so dismissive to the potential of the massive storage space of CDs at the time.

Sure you had all that raw storage but remember, the 3DO and PlayStation had just 2MB of main memory and 1MB of video RAM. So although the developers had a ton of space, there wasn't much they could reasonably do with it game asset wise. But media streaming from the disc was doable so that enabled high quality prerecorded sound tracks as well as video cut-scenes. Video cut scenes were always a bit painful or needless filler but some of the recorded sound tracks on CD games were really nice to have (Sonic CD is a good example IMO.)


Most of the voice acting of that time was terrible. It does sound a bit "old man yelling at clouds" but if you were there, you might understand


Indeed, he's references the 3DO console, and a similar statement could be made about SegaCD. The prevailing type of game enabled by that hardware was the Full Motion Video (FMV) genre with titles like Sewer Shark and Night Trap. They focused on the video over the gameplay, and the result was often a choose-your-own schlocky B-movie. They generally had poor reviews.


Just about everything Fabien writes is fantastic reading!


If you haven’t read it yet, I suggest his game engine black book series (mentioned in the article). If you like his writing online, you will likely like the books.


Good call out. I own physical copies of both the books :D. Really enjoyable stuff!


Another piece regarding PSX, it was the first console SDK to really push for C and C++ based SDK, finally making the pure Assembly cross from previous console generations.


> Ever since he had witnessed his daughter play on a Nintendo Famicom, Ken had been advocating for Sony to enter the market. He had even designed Nintendo’s audio chip (the SPC700) for their SNES against the advice of Sony VPs.

A man who's engineer enough to design an audio chip, and also advocating for entering the market to Sony? Sunny world of bright opportunities.


> That’s a stupid idea, Sony doesn’t know how to make hardware. They don’t know how to make software either. Why would we want to do this?

They know how to do hardware now, but software? cries in Sony Alpha firmware


Is this not a repost? I seem to distinctly remember reading this, and I'm fairly sure it was here on HN.. But it's a good read nevertheless :)




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: