HN Theater @HNTheaterMonth

⬐ ElCapitanMarkla

Andy Gavin's blog on this is a 10/10 read - https://all-things-andy-gavin.com/2011/02/02/making-crash-ba...

It comes up every year or so on here and every time I end up rereading that series from start to finish.

⬐ stepupmakeup

"My Hardest Bug Ever" is also a fascinating read, also about Crash Bandicoot on PS1. https://www.gamedeveloper.com/programming/my-hardest-bug-eve...

⬐ Yliaho

The extended version goes more in-depth and I highly recommend watching it instead.

https://youtu.be/pSHj5UKSylk

⬐ Operyl

Thanks! I saw the original a while ago and didn't know there was an extended cut.

⬐ andrepd

All of that series of videos is outstanding. Here is another of my favourites: https://yewtu.be/watch?v=qzD9ldLoc3c

⬐ RL_Quine

I find it really hard to watch because of the really constant camera focus changes, I don’t know why anybody would edit video to be so annoying.

⬐ acomjean

Yew tube. (I expected trees..)

I’ve seen a few in the series. Less technical but The NES comes to America is pretty good

https://youtu.be/Sn5v09L_uDg

And the Ultima online tried create programmatic eco system is kinda hysterical.

7 minutes (with lord British)

https://youtu.be/KFNxJVTJleE

Ars (the publisher)has a whole list of them. Non YouTube but seem to have transcripts.

https://arstechnica.com/video/series/war-stories

⬐ andrepd

Oh yeah the Richard Garriot one is my absolute favorite. I love Ultima Online, and the B-roll footage of the wolf-head pipe just kills me.

⬐ NeveHanter

I highly recommend checking the GameHut channel (https://youtube.com/c/GameHut).

It's the channel of the Jon Burton, the director of the Traveller's Tales, he worked on games like Sonic 3D Blast or Crash Bandicoot: The Wrath of Cortex. It's full of interesting stories with technical details about how things were achieved on old hardware or why were they done in some funky ways.

⬐ atan2

I always loved this interview. Great gems there. I studied the PS1 tech for a while and it's amazing how even small artifacts (polygon jittering, affine texture mapping, etc.) became looks we now try to replicate for the sake of nostalgia. Fun times!

⬐ None

None

⬐ pxeger1

This guy is an excellent communicator. For a modern HN audience an explanation of virtual memory paging is not exactly necessary, but he does a great job of it and I'm sure this video would be really interesting for a much more general audience.

⬐ FZ_BA

This kind of creativity and ways to defeat limitations always fascinated me.

⬐ mkjonesuk

Watched this a few times since it was released. Real talent and determination.

Sounds bad but I've recently put this on a couple of times as background video to fall asleep to as well. Work's like a charm!

⬐ zxspectrum1982

I used this on the PS2. It worked too.

⬐ cosmodisk

This brought back some very nice memories when we used to play PS1 until our eye became red:)

⬐ CloudGreed

Damn, This stuff is interesting.

⬐ louthy

Anybody who did PS1 dev back in the day will have had to do some crazy hacking stuff to get performance or memory. The first project [1] I worked on I had a C version of my graphics engine and animation system, and in parallel I'd have a MIPS assembly version which was super optimised (the C version was effectively a reference).

I made the whole engine and animation system fit in 4K so it would fit into the instruction cache of the CPU. The whole frame update cycle wouldn't need to touch main memory (for the code).

Also, because loading from main memory was slow (4 cycles) and the chip was RISC (1 operation per cycle), you'd need 3 NOPs after the Load-op for the register to be loaded. The C compiler (if I remember right) never really filled those 3 NOPs with useful stuff. So, I'd do hand written concurrency (in MIPS assembly) by loading other stuff I'd need into those NOPs - this was particularly effective when working with 3 dimensional vectors or 4 dimensional matrices.

Trying to keep super-optimised hand-written concurrency in assembly, in my head, was a challenge and not something I'd recommend! Still, the engine had more throughput than Sony claimed of their machine. Every bit of performance gained would mean an edge over the other games.

Then the game was canned by Eidos. Pretty devastating for my first industry job :/

[1] https://www.unseen64.net/2020/11/16/lunatik-pure-entertainme...

⬐ smcl

> I made the whole engine and animation system fit in 4K so it would fit into the instruction cache of the CPU

That's an impressive feat. The screenshots in the linked article look pretty nice particularly for the a PSX-era game, it has a good futuristic, but dirty industrial cityscape thing going on. Did you manage to utilise any of the tech in another project, or was the whole thing just completely binned?

⬐ louthy

> Did you manage to utilise any of the tech in another project, or was the whole thing just completely binned?

At that time we used to bin everything and start again (from the engine point of view at least). Usually it was so complex and hacked together by the end that there wasn't a generalised system to extract. We'd obviously take what we learned into the next title, but less so the code.

PS2 was probably the first time I remember reusing engines.

⬐ dboon

Do you still work in the games industry?

⬐ louthy

Nope, I bailed in 2005 after 10 years. Healthcare tech now, and I hope to never need to do the kind of low level coding I did back then, ever again :D

⬐ xeromal

Funny how the most bland of work ends up paying the big bucks. lol

⬐ Psyladine

It sounds like Gavin went beyond that, cutting into Sony's forbidden library space; it helps that he was a lisp head and didn't respect the existing C prefabs.

I don't remember if it was the blog or the extended video but he also got into some of the close to the metal choices they made, like sharing variables and rolling dice on the compiler each build to fit with only a few kb spare in the whole cd space.

⬐ louthy

> It sounds like Gavin went beyond that, cutting into Sony's forbidden library space

Sure, this wasn't an exhaustive list of every trick we had to do, it's just another war story. This is the one that I remember the most vividly, but there were myriad tricks to bend the system to do what it didn't want to do :)

⬐ pjmlp

Thanks for sharing the experience.

This is effectively what younger generations that praise C don't get, the kind of tricks that most game developer had to do 20 - 30 years ago in home computers and game consoles, given the bad quality of C compilers in regards to code generation.

⬐ hbn

It's funny how C seems so low-level and primitive now, yet I watched a Computerphile video, I think it was David Brailsford giving a history lesson on C, and he talked of a time when when the attitude was C was considered to be very high-level and looked down upon by the "real programmers" who programmed assembly! What a different time.

Now it's the people who are 7 layers of abstraction from the machine looking down upon those who are 8 layers of abstraction away!

⬐ moonchrome

>Then the game was canned by Eidos.

I've seen this pattern so many times in my time doing development (although I haven't done game development professionally), and why I tell people to avoid early development optimization. Trying to get things working correct and fast at the same time is an insane ammount of work, by the time you're done the requirements probably changed or the project flops, you'd be better off just getting something to satisfy minimum requirements first then make it fast.

⬐ AdmiralAsshat

I see engine re-use quite alot in game development, though, so there's always the chance that if you make a really bang-up engine, it might eventually see the light of day in another project, even if the original one was canned.

In the context of Eidos, for example, I seem to recall that Gex 3's game engine (which was a mediocre game at best) ended up being re-used/tweaked for Soul Reaver (which was an amazing game).

⬐ louthy

Now for sure, but back then any generalisation would potentially cost clock cycles or memory, so an engine would be fine tuned for the game in front of us. It would be entirely possible to take that engine and use it for a similar game, but then you hit the problem of needing to extend it for the new game - which is hard when you've optimised it to the nth degree and you can't see the wood for the trees.

One thing I saw after I'd worked on 'Fireblade' for PS2 & XBox [1], we took its engine and tooling (which had also been used for 'Reign of Fire' [2] in parallel) for our next title 'Battalion Wars' for Nintendo. After 6 months of fighting the system we downed tools for 3 months just to refactor everything. It was the first time I'd seen a real aggressive, whole team, refactor - and it worked, but really the engine & tooling just weren't right for the game and shouldn't have been taken without a commitment to making it fit-for-purpose for the game we were about to build. It cost us time at the end of the project, and for a while we weren't sure if Nintendo would keep funding it - luckily it worked out (and is actually the game I'm most proud of working on).

But yeah, once the consoles got more powerful and had more memory it was possible to start building core tech for multiple games, which is what I did for the last 4 or 5 years of my time in games.

[1] https://en.wikipedia.org/wiki/Fire_Blade_(video_game)

[2] https://en.wikipedia.org/wiki/Reign_of_Fire_(video_game)

[3] https://en.wikipedia.org/wiki/Battalion_Wars

⬐ AdmiralAsshat

Oh, wow, Battalion Wars! I never managed to beat it (surprisingly hard, IIRC), but I remember being blown away that a developer had actually tried to implement both the top-down RTS mechanic and the grunt-on-the-ground 3PS mechanic in the same game. I don't think anyone had really tried that since Dungeon Keeper, and rarely since.

Off the beaten path here, but just for my own curiosity: did Nintendo seek you guys out when they wanted a third party to try their hand at the license, or did you go to them with the pitch for "3D Advance Wars in real time"?

⬐ louthy

> surprisingly hard, IIRC

It was much harder pre-release, we had to tone it down! Although that's relatively normal when you get a room full of hardcore gamers making games :)

> both the top-down RTS mechanic and the grunt-on-the-ground 3PS mechanic in the same game

Yeah, that was something I particularly liked - it took a loooooooong time to get the squad control right, but I think it worked nicely. One interesting artefact is the sweeping camera movements (when switching units) and the follow camera algorithm was something I originally invented (probably reinvented) for Lunatik and I built it into Battalion Wars - so it bookended my time in games!

> Off the beaten path here, but just for my own curiosity: did Nintendo seek you guys out when they wanted a third party to try their hand at the license, or did you go to them with the pitch for "3D Advance Wars in real time"?

I thought I remembered this, and I thought they came to us, but the more I think about it the less sure I am of that fact! I'm now semi-thinking that we pitched the idea (not as Advance Wars) and they said "Let's make it Advance Wars 3D". But, yeah, passage of time, makes me question that. Sorry!

⬐ djmips

It's too difficult to try and re-engineer at the end to make it fast. Imagine if we used this approach for making airplanes or bridges. You have to engineer to a spec from the start.

⬐ jayd16

>correct and fast

And usually you only need 'mostly correct.'

⬐ louthy

To a certain extent I agree with you. But when the game doesn't even fit in the RAM of a development system (4mb), never mind the 2mb of a real Playstation, or movement is 5 frames a second rather than 30/60 it's still very hard to get gameplay aspects right. And when the graphics engine, level editors, etc. don't even exist yet, you're not making any game!

In the 10 years I was in the industry (pre the era of off the shelf engines) I never saw a single title in a playable state until the last 6 months of the project, and sometimes later. My era was PS1, PS2, Dreamcast, original Xbox, Gamecube. I left as the PS3 was in its pre-release period.

I think for most games the dynamics are quite well known, and so it's less problematic if it's started later. But, in this case none of the dynamics of the game were worked out at any point, so it was doomed to fail.

On Lunatik I wasn't responsible for the game dynamics, I had one job: make the engine, and make it as fast as humanly possible so that the game and level designers can make a decent game. So, it's not either or, but it does take time to have the initial version that the team can work with (my C reference engine mentioned before).

One final point is that it's less about early optimisation and more about poor management, short timescales, and the balance of cash given to a team when signing with a publisher. When the money runs out, then you're in the lap of the publisher gods - it can go either way for many different reasons, some of which might have nothing to do with the game.

I suspect it's more professional now (and with better tooling), back then it was still pretty much a cottage industry: quite a large cottage industry, sure, but still pretty amateurish in terms of project management and planning. There wasn't a title I worked on that didn't overrun.

⬐ Melatonic

You ever develop games for the Dreamcast? What was that like?

⬐ louthy

Yes, although not a full title. It was the period between PS1 and PS2 and no publishers were committing until they knew what was happening with PS2 (because of the outrageous success of the PS1). I built a bezier-patch based engine for it and physics system, and we produced two fun little game demos to try and get publisher funding, but it didn't come.

It was super easy and fun to develop for (which after the pain of the Saturn was a relief). It's a real shame it didn't get more support, it just arrived at the wrong time.

⬐ bennysomething

That's interesting. Would it have been better if sega had wait until post PS2? The Dreamcast was the last console I loved. I bought one on launch day. But I think looking back it was always doomed. I can't recall properly but I think it was someone in EA or high up in sega America who tried to persuade sega Japan that they wouldn't survive with the type of games they were planning for the Dreamcast. Oh well in those two years the Dreamcast had some of my favourite games.

⬐ louthy

I'm not sure if delaying it would have made any difference. PS1 was a zeitgeist machine, especially with titles like wipEout. I remember going to underground nightclubs in London and there'd be a chillout room with Playstations in. The Dreamcast just wasn't cool enough I guess.

I think Sega also seriously fucked up with the Saturn. There were lots of claims of it being more powerful than the PS1, but nobody could extract that power really. A Saturn dev at a studio I worked at had a complete breakdown just trying to keep up with what I was doing on the PS1. I feel they burned a lot of industry bridges with that machine.

I'd have loved to see the Dreamcast succeed because I'd always been a big fan of Sega, but I think a lot of things just went awry for them.

⬐ bennysomething

Ha! I'm still playing wipeout (on retro arch though). I only bought a PS1 around 2010 as I'd been an N64 fanboy. I really had missed out.

I heard the Saturn was originally designed as a 2d machine, sega saw what the PS1 was going to be capable of and bolted on 3d. Hence it was a mess. Is it true it could only use quads not triangles for polygons?

⬐ louthy

> Is it true it could only use quads not triangles for polygons?

Yep, but obviously a quad could become a triangle with two shared vertices. I never worked on the machine myself, and my memory is definitely fuzzy on this, but I seem to remember one of the things stressing out my colleagues was the poor transfer rate of getting textures into the video hardware, and the space being quite limited. So, all textures ended up being down-res'd by 50%, which just made everything look terrible.

I'm sure there were other issues, that's just the one I can vaguely remember.

⬐ moonchrome

Wasn't trying to suggest it was premature (especially if you couldn't have more powerful devkit/device to prototype on) just envisioning someone burning long hours and stress to meet deadlines and then the work gets wasted because of various reasons. I've done that so often during early career - nowadays I'm much happier doing bare minimum untill it's absolutely necessary - I just don't have the 12 hours a day energy in me :)

⬐ AdmiralAsshat

The video certainly looks impressive for 1997! ...but I can also see why it might have been relegated to tech demo. Even just watching someone else play it, it seems like you guys weren't totally sure yet how to do full 3D movement in-flight in a way that felt fluid. When the ship moved up or down, it reminds me of someone holding the space-bar in e.g. Doom/Quake with NoClip mode turned on.

It also seems like the player might get rather frustrated that they can't hit an enemy ship that is five feet in front of them because the player ship is not exactly at the same elevation as the enemy ship.

⬐ mpyne

> It also seems like the player might get rather frustrated that they can't hit an enemy ship that is five feet in front of them because the player ship is not exactly at the same elevation as the enemy ship.

Ha, I even had this problem with a 'modern' game, Uncharted (2? I think?). The one with the tutorial level with you on a dock having to shoot pirates or something. Aiming was impossible on the DualShock because you'd either not move the crosshairs or the crosshairs would just way overshoot once it started moving.

I ended up having to run up to the goons to land shots.

Thank God for Gamefly, that game went straight back even though I'd spend hours already getting it installed and then mandatory patches done.

⬐ louthy

> they can't hit an enemy ship that is five feet in front of them because the player ship is not exactly at the same elevation as the enemy ship

And that in a nutshell was everything that was wrong.

How to make Defender in 3D when you can't line up with the ships in three dimensions. For a slower game it would have been less of an issue, but at the pace we wanted it didn't work.

⬐ AdmiralAsshat

Did you guys ever do a post-mortem on how you might have solved that problem, or even how other games solved that problem?

If this was 1997, this would've been around the same time as Star Fox 64, and while that game was mostly on-rails (like Panzer Dragoon), it did have the "all range mode" maps where your movement was fully 3D. I played that game quite frequently as a child, and I don't remember ever feeling like I was having trouble hitting the enemy ships. Maybe the game had a very generous auto-target/fudge factor turned on so that the player felt like their aim was more accurate than it truly was?

⬐ louthy

There were plenty of pre-mortems! :D

Obviously we all knew of things like Star Fox 64 which is still really just a 2D game in many ways (following a fixed route), the idea was to not be on a fixed route and be free roaming.

We tried putting the player and all NPCs on a height-map - so effectively your vertical movement was based on a height map, which meant everything was vertically aligned - it was the closest it got to being decent (not sure why it didn't make it to the demo). It did allow rapid movement, less concern about targeting, and avoidance of low buildings, etc. (which allowed some of the Defender pace). However watching your bullets going up n down along a height map was weird.

But even then the free roaming nature of the levels meant that there wasn't ever an urgency to get to a place and do a thing. Each level would have targets to get to within a certain time, but then it was going away from shoot-'em up into capture-the-flag. Really it was misguided from the start.

By the time we'd tried lots of different options we'd run out of cash. I was 21 at the time, and it was pretty much my first software engineering job (I did do some educational software before that, but nothing at this level). So I wasn't perhaps as reflective then as I am now - and I left the company not long after.

⬐ birracerveza

Oh wow. Why did it get canned? The tech demo looks amazing.

EDIT: nvm it's in the post

⬐ gambiting

It says on the website:

"But ultimately the project failed because the original concept (3D Defender) was next to impossible to do really well. We tried many different gameplay mechanisms to make it work, and none were working"

⬐ nsxwolf

I bet it was a lot more fun as-is than a lot of early trash on the PS1 that did get released.

⬐ louthy

I wrote a comment below the article with background of what happened:

https://www.unseen64.net/2020/11/16/lunatik-pure-entertainme...

⬐ djmips

Hey louthy, do you still have the source code for that PS1 engine? Maybe put it on Github for all of use to gawk at and/or use in some fun PS1 hacking around.

⬐ louthy

Possibly, I have some old CDs lying about. Chances of them loading up is slim after 25 years, but I'll have dig!

⬐ djmips

Thanks for considering it. That would be awesome!

⬐ louthy

So the CDs I have were the PC & PSX versions for an E3 demo (well the PC one was marked E3 demo, so I assume the PSX one was too - as they were together). The PSX version is actually playable on RetroArch, so I've uploaded it to github [1].

I have also found some floppy disks marked 'work backup 1..n' alongside the Psy-Q PSX drivers. I've ordered a USB floppy drive 'cos I don't have one any more. They may (if they still read!) have the source on.

[1] https://github.com/louthy/lunatik-psx

⬐ djmips

Wow! nice.

⬐ JohnBooty

Ah! I remember looking forward to that one. Based on the press coverage it seemed like a "modern" of Sinistar, a favorite of mine.

⬐ Thaxll

It looks like G-police.

⬐ ffhhj

Also reminds me of X-Com.

⬐ mikeryan

My first “tech job” was supporting DOS games at EA in the late 90s. Post windows 95 they still had some bargain flight sims that seemed popular. I can’t remember the exact numbers but one of the sims checked for sufficient RAM. I think you needed 16MB but there was a bug where if you had more than like 512 it would think you didn’t have enough (pre-internet so no real patches). The “fix” was a “boot disk” (on a floppy) that would create a RAM drive to partition off some of your RAM getting your available total under 512. RAM had just started to get “cheap” enough that some folks had 1GB and we were able to use the RAM drive (which worked like a physical HD) to install the game and play it from RAM instead of the old slow spinning disks.

But yeah memory hacks in those days were rampant.

Side note the most common problem for the PS support queue was PlayStations not reading disks properly. The fix was to turn the machine on its side or even upside down to get the CD closer to the laser.

⬐ rawoke083600

> Post windows 95 they still had some bargain flight sims that seemed popular.

The golden era of flight/space sim !

I miss my wing commander(s) (don't you dare mention/reply Star-Citizen !)

I think I played/broken through 2 crappy-cheap joysticks via the whole series. That perfect point in time (when you were young enough not to pay taxes, but old enough to get a soundblaster-card-kit with free wingcommander games)

⬐ nomel

Someone needs to port these to the Quest 2. VR, for flight sims, is pretty awesome, assuming you can stomach it.

⬐ rawoke083600

absolutely ! Im assuming 40year old me that can afford vr doesnt have the same stomach as 16 year old me :)

⬐ nomel

It just takes time. For me it was a few weeks, with longer and longer sessions each time. I’m someone who gets sick from spinning in circles a few times, so if you can stomach that, probably less.

Car sims took the longest. There’s just too much hard wired in there.

⬐ mikeryan

IIRC this particular issue was with one of the Jane’s Combat Simulator games. ;-)

⬐ rawoke083600

janes !! Damn that bring back memories

⬐ rawoke083600

Forgot to mention. Dammn that music of wingcommander

⬐ ansible

Wing Commander series, Chuck Yeager's Air Combat, Falcon 3.0, X-Wing series, Descent 1 & 2. Thrustmaster flight stick and throttle. Good times, good times.

I never really mastered flying the F-16 in Falcon 3.0, but I at least got to the point where I could take off and land OK. The mission planner for custom missions was very sophisticated too.

For Descent, I had also tried out the Logitech Cyberman 2 controller:

https://www.neogaf.com/threads/the-weird-and-wonderful-world...

In theory, it is ideal for flying your spacecraft in Descent, allowing you to move or turn in any direction in a a sort of intuitive fashion. However, it wasn't that satisfying in practice.

⬐ ansible

I also had at one point a steering controller that resembled a RC car controller. That worked a lot better for me than racing wheels that were much more common.

Pairing that with the original ReVolt RC racing car game (don't buy the ripoff version that was just released to Steam!) and you're talking many hours of fun.

⬐ hbn

> turn the machine on its side or even upside down to get the CD closer to the laser

I'm confused by this, doesn't that seem backwards? If it was sitting normally wouldn't it naturally be helped by gravity to be as close to the laser as the mechanism would allow? Upside down, gravity would be pulling it away from the laser. Right?

⬐ majormajor

The laser is on a mechanism that moves in and out from the center to the rim of the disk. You can see a picture here: https://gametrog.com/playstation-1-one-information-specs-ver...

I don't have a Playstation myself on hand, but from memory, these mounts usually had a certain amount of play in them - if you touched it, you could press it a bit lower, for instance. Whereas the clamp that grabs the disk on toploaders tended to make a very secure connection. So it's probably not bringing the disk closer to the laser, it's bringing the laser closer to the disc.

⬐ Wolfbeta

>Side note the most common problem for the PS support queue was PlayStations not reading disks properly.

I laughed when I read the following quote from Andy Gavin's blog, now I'm crying after seeing yours.

"Kelly asked how many of these CD hits Andy thought a gamer that finished Crash would have. Andy did some thinking and off the top of his head said “Roughly 120,000.” Kelly became very silent for a moment and then quietly mumbled “the PlayStation CD drive is ‘rated’ for 70,000.”

>The fix was to turn the machine on its side or even upside down to get the CD closer to the laser.

Was this the precedent for marketing the PS2 vertically?

⬐ rasz

Afaik putting PSX on a side fixed the issue of worn out plastic slider/sled. Early laser beds were plastic and would wear leading to slop and misalignment, later ones were die cast. People used to shim worn out sled with razor blades/other thin metal pieces.

There's a talk by one of the developers of Crash Bandicoot of all the hacky (and brilliant) things they had to do to get the game to load quickly off the (2X?) CD-ROM into the very limited RAM of the Playstation 1.

https://www.youtube.com/watch?v=izxXGuVL21o

Here's another example from a constrained environment: in Andy Gavin's interview with Ars Technica, he talks about a domain-specific compressor they made for storing Crash Bandicoot's animations, because storing each coordinate of each vertex for each frame would have been too large.

https://www.youtube.com/watch?v=izxXGuVL21o&t=21m12s

⬐ justinlloyd

Yep, in video games, especially on older systems, we did an awful lot of that. Storing vector deltas for bone animations rather than the full vector3. Compiled graphics on old PC games I worked on, which both helped in size, but also in speed of blitting to the display. Vector3 are made up of three 32-bit floats, but frequently stored as four 32-bit floats so that everything aligns on word boundaries, but you don't need to do that for data you aren't currently using, so you can save 25% of memory right there. Also, interleaving vector3's for packing and alignment on 3d models. Lots of bitmask manipulations and interleaved SIN/COS and DIV/MUL look-up tables. These last couple of techniques go all the way back to the original Atari Asteroids game from the arcades in the 1970's.

In the cause of Naughty Dog, it was Andy Gavin who introduced Lisp and GOAL and was one of the co-founders of Naughty Dog. He came from MIT and was a student of Rodney Brooks.

https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

https://all-things-andy-gavin.com/2011/03/12/making-crash-ba...

If someone hasn't seen it, his episode on Ars Technica's War Stories was awesome. He seems to be a hacker's hacker. It's a fascinating story because it's not really how I personally work (internally), so it's fun hearing someone describe just diving in like that.

https://www.youtube.com/watch?v=izxXGuVL21o

https://www.youtube.com/watch?v=pSHj5UKSylk

It was my understanding that Racket wasn't in use anymore at Naughty Dog. It would be cool if there was an update or someone who knows (I know Dan is no longer at Naughty Dog), because unfortunately the tale of Lisps in companies is normally that it eventually gets replaced or set aside (where new stuff is built in something else).

⬐ mtzet

I can highly recommend the interview with Jason Gregory of Naughty Dog from Handmadecon 2016. He gives a lot of insight into the reality of working with the scheme-based format in recent-ish times.

https://guide.handmadehero.org/hmcon/2016/05/

My impression isn't that scheme is being passed out just because Sony doesn't like it, but also because the language has issues. On the other hand, it seems they're putting a lot of effort into getting the nice scheme features, like hot reloading, in their C++ environment.

⬐ bitwize

> because unfortunately the tale of Lisps in companies is normally that it eventually gets replaced or set aside (where new stuff is built in something else).

Any sufficiently advanced Common Lisp or Scheme program will eventually be rewritten in C++, Java, Python, or JavaScript.

⬐ boppo1

Why? Is there a reason other than "most people don't know lisp and it's cheaper not to teach them?

⬐ bmitc

In my experience, companies are deathly afraid of doing something even perceived as different when it comes to software. And my experience has been at places developing advanced novel hardware, so I would always try to point out the discrepancy. Why are people willing to try new things and train on advanced hardware projects but software gets relegated to the least common denominator? If it's not Python, C, or C++, it's a hard sell to try anything else, no matter the many multipliers that could come from switching.

⬐ zelphirkalt

Could it be a lack of trust in the capability for learning new (old) things? The thinking, that a software developer is but a script kiddy?

⬐ Jach

I wish it were so simple, yet I think the rapid advances in the last 10 years or so in Java, C++, and JavaScript, which developers have been expected to learn and keep up with, are sufficient to more than cast doubt on that. The changes on whole are nearly broad enough to count as new languages. If that's not enough, then there's the mobile development side of things, which have seen actual language shifts in Objective C to Swift and Old Java to Kotlin.

⬐ bcrosby95

I think it makes sense. When I start a new project, I tend to limit the number of risks I'm taking at a time. If I'm using a brand new language, I'm probably not going to also use a brand new database. If I'm going into a brand new domain I'm completely ignorant of, I'm going to use non-risky tech. And so on.

⬐ fulafel

Successful programs tend to attract reimplementations, and those are probably written by different kinds of people than the originals.

⬐ lispm

People even completely rewrite older Java programs into newer Java programs, changing large parts of the technology stack...

⬐ xenomachina

That's probably part of it.

Another possible factor: When I was at Google there was a similar phenomenon where any sufficiently complicated Python system seemed to get reimplemented in something with static types. A problem we had with Python (and I imagine this would be true of most Lisps -- yes, I know typed Racket exists) was that once a system got too big to keep in your head all at once, large-scale refactoring became almost impossible without the help of static types.

⬐ baq

yup. fortunately, static typing support in python has made significant progress on both tooling and language fronts in the past few years.

⬐ bmitc

I agree that static types is certainly a barrier. My day job is in a dynamic language for the first time ever, and it's certainly been a challenge and learning curve for me. It's in Elixir, so I just seemingly annoy everyone by putting typespecs on everything. Haha. Even if Dialyzer isn't ran, it still provides some documentation on what's going on where.

My personal opinion is that there aren't any huge barriers to making static and dynamic types meet more in the middle. There's the gradual typing approach like that in Racket and Typed Racket, but I feel that most of the times dynamic languages are really just dealing with fairly simple anonymous unions. Like a function make take a string or float and return some data structure or a boolean value.

⬐ lelanthran

> Any sufficiently advanced Common Lisp or Scheme program will eventually be rewritten in C++, Java, Python, or JavaScript.

I'd change that: `s/sufficiently advanced/sufficiently profitable/g`

The state of advancement is no indicator that something needs to be maintained, while the state of profitability is a reliable indicator that something will be maintained.

⬐ ryneandal

I love hearing Gavin talk about solving problems, even decades afterward, he seems genuinely excited.

⬐ praptak

> unfortunately the tale of Lisps in companies is normally that it eventually gets replaced or set aside

Wikipedia page on GOAL says exactly this happened.

"In all honesty, the biggest reason we're not using GOAL for next-gen development is because we're now part of Sony. I can only imagine Sony's shock when they purchased Naughty Dog a few years back, hoping to be able to leverage some of our technology across other Sony studios, and then realized that there was no way anyone else would be able to use any of our codebase."

⬐ rjtavares

Sounds exactly like the sort of thing execs think when buying a company but then don't include in their due diligence.

⬐ minsight

I used to work for a company which got bought out and it turned out that the technology that they wanted us for was exactly the one piece of our code that we white labelled.

⬐ andi999

Was does white labelling mean?

⬐ None

None

⬐ krageon

I would guess they got it elsewhere and just resold it under their own brand (at least that is what it broadly means in hosting).

This is a cool story on how the Crash Bandicoot developers hacked toe PlayStation to get free up more memory for their game.

https://youtu.be/izxXGuVL21o

I recommend watching this: https://youtu.be/izxXGuVL21o

Naughty Dog Co-founder Andy Gavin discusses various hacks that were used on the Playstation to get Crash Bandicoot to run smoothly. The fuller version is also worth watching.

⬐ omegaham

For those who like text, his series of blog entries is also extremely good. https://all-things-andy-gavin.com/video-games/making-crash/

⬐ Waterluvian

This one is my favourite. I would call this kind of programming both art and beauty.

⬐ sushsjsuauahab

If I remember correctly the two main hacks were making draw lists such that only certain polygon faces were rendered based on Crash's xyz position (the theory being that it isnt possible for other faces to be seen from that location), and also that he removed functions/files from Sony's standard C libs on the PS1 SDK?

⬐ Waterluvian

I believe two other huge wins were how they padded the disc for faster reads(though maybe this was common) and how they could trivially cull polys based on the constraint that the game is on a rail. By knowing your position on the rail you just lookups what polys can be culled via precalculated tables.

⬐ sushsjsuauahab

Right, for the polys I think we are talking about the same thing :)

For the disk, I guess they viewed the disk as merely just an extension of RAM? If the read/write speeds were sufficient for them... page files galore :)

I also remember that they used to write bytes to disk in specific orders so that they would maximize the correct bytes being read into the buffer every microsecond

⬐ sgtnoodle

They realized that untextured polygons were way faster to draw than textured ones, so rather than texture the Crash model, they cranked up the polygon count and simply colored them. Often times, the triangles were on the same order of size as the pixels. It also avoided the playstation's lack of perspective correction on textures. It both made the character look gorgeous for the day, and made the code run faster.

⬐ sushsjsuauahab

Yes, I played many many hours of crash as a kid and he looked extremely vivid and bright. When I code in Three.js these days I also skip loading textures and just go for hex colors on polygons :)

⬐ shapefrog

The art of working with constraints does not seem to be lost; just look at late cycle console games.

A PS4 was/is effectively unchanged hardware between Nov 2013 and today, yet the late lifecycle games look great. Upon release of the hardware devs had plenty of performance to play with, then 5 years in they have honed their craft and are able to use all the tricks at their disposal to squeeze as much graphical and performance life out of a limited resource budget.

Nope ; Motorsport is always drivers' skills coupled with engineering ingenuity. It's always about "what can I come up with, which gives me an edge, and still somehow is within the rules?" I don't know anything about Nascar, but the history of Formula 1 is full of such little tricks as well. It's just easier to regulate "other sports" than it is to regulate sports that come coupled with a lot of technological involvement.

If sth gives you an edge for half a season until rules are adjusted, that might be enough to win a championship. It's a cat-and-mouse game, but it's also exciting, and important for the whole thrill of it.

Decades past Gordon Murray designed a fan quite literally sucking cars to the ground, which somehow was within regulations, because no one even considered something like that https://www.youtube.com/watch?v=Hb6DAmm7sZg In rally driving, they would sometimes come up with fake reasons for a start to be delayed, so they wouldn't have to drive in the front car's dust all the time. Audi entering with their 4-wheel car back in the days was only possible, because they pushed for a rule change and no one else really knew what was coming. Sometimes manufacturers straight up "cheated" (almost, sometimes for real) https://www.youtube.com/watch?v=6lo4dGTrzr8 ; it's a thin line, but also what makes it exciting.

I would say that it's the hacker's / engineering ethos almost. What can I do within the framework? Whether it's building a bridge (to make it more stable while still following this brash design), a road car (how can I create something fun, with torque, sound, emotion, down force, power, but a nice shape, and still get a road legal car within environmental regulations), computer games (consider https://www.youtube.com/watch?v=izxXGuVL21o ; computer games are full of hacks to get the most out of the hardware), even legal (how can we pay almost no taxes, while not being busted for tax avoidance?) ; not every ingenuity is necessarily good, but it will always be cat-and-mouse, that's the point of living.

This got meta quick ... and quite a more detailed answer than I anticipated. Sorry for that, hope I gave you a different perspective though.

⬐ geocrasher

Excellent comment. I watched the Audi/Lancier video in full. Wow. Amazing stuff. Thanks for all the info!

⬐ Wxc2jjJmST9XWWL

Thank you. After having written the comment I also stumbled upon https://www.youtube.com/watch?v=0rtzM-IUAx8 and https://www.youtube.com/watch?v=rnIjQC08qKk ; both videos about rule bending / engineering ingenuity within Formula 1, both about 10 minutes. Since you've liked the Audi/Lancia documentary, I thought you (or anyone else who appreciated my comment) might enjoy those as well. Cheers

⬐ samstave

Was watching the formula 1 series, and one team appeared to fully copy the body stylings of the mercedes team, and while it was technically legal, it was morally frowned on and a lot of other teams were pissed off.

⬐ cellularmitosis

> Decades past Gordon Murray designed a fan quite literally sucking cars to the ground

This reminds me of a similar story (and I'm having trouble finding a source now, perhaps it was the Lotus 78?), where the team bragged to the press about a new technology they had developed which reduced the losses in their differential, which explained their recent competitive advantage. On race day the pit crew even covered the part in rags as they ran to the back of the car to swap out the differential mid-race, lest their competitors catch a glimpse of this new technology.

Only there was no fancy differential technology. That was all a ruse to distract from the aerodynamic skirt they were using which literally sucked the car onto the track :)

For anyone that hasn't yet seen it, I'd highly recommend watching Ars Technica's video interview on Amnesia and how it created its unique atmosphere: https://www.youtube.com/watch?v=sMl2la8-3-o

Along with the rest of their War Stories videos, for that matter. The interview with Andy Gavin on Crash Bandicoot is great, even though I never played the game: https://www.youtube.com/watch?v=izxXGuVL21o

> no additional cost

The additional cost was an enormous step up in seek time and read time, which for some games manifested as load times everywhere, and for others meant a herculean effort in managing asset streaming, per the fascinating Andy Gavin talk that Ars published a few months ago:

https://www.youtube.com/watch?v=izxXGuVL21o

⬐ simias

That's fair, but as long as you packed your assets correctly it was bearable for the time IMO. So much available storage meant that you could duplicate textures instead of seeking all over the disc for instance.

Also streaming assets was rather uncommon at the time, Naughty Dog is really pushing the envelope here. It was especially uncommon because most games streamed the background music in real time straight from the CD, so if you wanted to side-load assets on demand you had to be very clever about it lest the audio got interrupted.

As a result you generally had long loading times at the start of levels but that's about it. Some games were really bad about it though, and had long loading times all over the place (some even when you do something as trivial as opening a menu) but that could generally be attributed to shoddy programming, not a weakness of the console per-se. Overall I think in hindsight the decision to use a disc drive was the right one and cartridges ended up being a rather severe liability for Nintendo at that time, although of course it's far from the only factor at play when comparing the successes of both consoles.

⬐ mikepurvis

I never owned a PSX, but my impression is that a lot of games did that thing where the actual game content was a few dozen MB at most, and the rest of the disc was either empty or used for background music, FMVs, etc.

this is relevant but not same system https://www.youtube.com/watch?v=izxXGuVL21o

For anyone interested how it was developing for the original PSX (and therefore under hardware constraints)

How Crash Bandicoot Hacked The Original Playstation

https://www.youtube.com/watch?v=izxXGuVL21o

Immensely interesting video! "Old" hardware makes me feel so humble regarding what we have now. Hardware limitations back then really pushed developers towards novel approaches and solutions.

⬐ glandium

Extended version: https://www.youtube.com/watch?v=pSHj5UKSylk

⬐ blondin

awesome! thanks for sharing.

⬐ junke

Andy Gavin (in the video) was also responsible for the development of GOAL, Game Oriented Assembly Lisp (https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp)

⬐ thomasfortes

Naughty dog (the studio founded by Gavin and Jason Rubin) is also home of the ICE team, a technology hub for Sony titles, I wonder if Sony saw the tech expertise culture in the studio and decided to put a team to handle psx dev tech with them.

https://en.m.wikipedia.org/wiki/Naughty_Dog#ICE_Team

⬐ kabes

While hardware is a lot more performant now, game devs are still pushing the boundaries, I'd say even more than back then. Modern triple A games like red dead redemption 2 are a giant collection of such tricks.

⬐ grawprog

>Modern triple A games like red dead redemption 2 are a giant collection of such tricks.

It's just too bad somewhere along the way they forgot games were supposed to be fun as they were slapping eachother's backs over how ingenious they were to be able to render every flea and tick on a horse's asshole while you clean it out and feed them a carrot.

⬐ AmericanChopper

Those war stories videos are very interesting and impressive. But I’m personally glad I’ve never been asked to program a video game in assembler using a trackball and no keyboard.

https://www.pcmag.com/news/first-kirby-game-was-created-with...

⬐ ddoolin

Agreed, on both counts. I've seen some other War Stories videos and they're pretty good. It's interesting to see some perspectives from people involved other than developers (although they can be a bit hyperbolic/dramatic at times). https://www.youtube.com/watch?v=BQ3iqq49Ew8

⬐ newswasboring

On the same note, I discovered this[1] yesterday. An explanation of why things looked a warped in PS1 games. The explanation actually blew my mind. I had heard the term zbuffer before but didn't really know what it did.

[1] https://www.youtube.com/watch?v=x8TO-nrUtSI

⬐ foota

That was cool, also check the comments for a neat thread by someone that worked on an early PlayStation game!

⬐ MrBuddyCasino

He got lots of things wrong though: https://www.reddit.com/r/Games/comments/fnl0o1/why_playstati...

⬐ agavin

Thanks for the interest in our shared video gaming past. I had a lot of fun making that video. The PS1 was a fun machine as it was capable, complex enough that you felt it had secrets, but not so bizarre or byzantine that you felt learning them was a waste of time. And you were pretty much the only one in there as the libraries were just libraries, not really an OS. Still true of the PS2 although that was a complex beast, but by the PS3 there was more of a real OS presence. If you want some more, slightly different, slightly overlapping info on the PS1 or making Crash, I have a mess of articles on my blog on the topic: https://all-things-andy-gavin.com/video-games/making-crash/

⬐ 2600

I really enjoyed your "Making Crash Bandicoot" blog posts and the "War Stories" video. I would love to read about your work on Jak & Daxter and working on the PS2.

⬐ kernelbugs

Me too, the Jak & Daxter games have a very special place in my heart as my childhood introduction to gaming. I'd love to reach about it!

⬐ s0fa37

Oh wow, this is akin to spotting a celebrity out on the street!

I happened to already be half-way through the extended "war stories" interview on the making of Crash you had done and it is superb; you are a joy to listen to! I remember reading these blog articles of yours many years ago but will definitely be revisiting!

As an aspiring hobbiest game developer, I often feel I have missed out on this golden age of game development - where you really had to think outside the box and hack your way around the architecture to achieve your design and performance goals.

This is part of a great series of interviews with the developers of some of the most influential games in history.

Two of my favorites are Andy Gavin on Crash Bandicoot:

https://www.youtube.com/watch?v=izxXGuVL21o

and Sid Meier on Civilization:

https://www.youtube.com/watch?v=XwUM33VJRbY

⬐ monocasa

A new one released today on Homeworld.

https://www.youtube.com/watch?v=Q38556KTTR0

I'm loving this series from ARS, another great one about Crash Bandicoot where apparently they needed extra RAM so selectively overwrote the sony libraries in RAM with their own data, by experimenting which areas were needed on whether it crashed or not.

https://www.youtube.com/watch?v=izxXGuVL21o

⬐ jacobush

Wow, that's so crazy and wonderful. And yet very okay, since it wasn't like there would be any other application running. :)

If I recall correctly, (original) XBOX games would often go the the next level of whatever game by just loading a new EXE and start over from scratch, rather than bothering with some kind of "level loading and init" code.

⬐ nottorp

The original x-com (the good one from 1994) had separate executables at least for the geoscape and tactical battles.

In spite of being a 32 bit application using a dos extender, so not limited to the first 640k ram.

⬐ dfox

Almost all Microprose PC games from early 90's were structured as small .COM driver that switched between some number of separate .EXEs. IIRC there is notable exception of Civilization that used proper overlays.

⬐ Insanity

guess that could make sense in a way. Dump all 'state' to disk, start new exe that begins by reading that state, and go from there.

⬐ ascagnel_

It was fine on consoles, but on PC it'd lead to some weird behavior, like the monitor switching modes as it returned to the desktop and then went back into 3D mode as the newly-launched EXE ran its init code.

⬐ jacobush

And often that state would be minimal. What character am I playing, what is the total score, stuff like that.

⬐ anoncake

They needed that code anyway for savegames.

⬐ akx

Reminds me of how Emacs is built, with a `temacs` executable whose state is dumped to generate `emacs` which boots faster... https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...

⬐ anthk

The Italian Job for PC works like that too.

⬐ remarkEon

The Command and Conquer episode from last year is also excellent:

https://youtu.be/S-VAL7Epn3o

⬐ ansible

Crash Bandicoot on the OG Playstation was such a marvel. The graphics looked so much better than many other titles on the same platform, even those coming out years later.

⬐ mywittyname

I also get a kick out of their technique for constantly loading pages of memory from the disk, resulting in a few thousand seeks per level then come to find out Sony only rated the disk drive for <100k seeks.

I wonder how influential the decision was to not tell Sony brass about it.

⬐ maxsilver

This would also explain why early PlayStation's CD drives would die so routinely...

⬐ glandium

There is an extended version of the interview. https://youtu.be/pSHj5UKSylk

⬐ skocznymroczny

So that's why it's called Crash Bandicoot

Andy Gavin has a great interview on the technical-side of developing Crash Bandicoot [0], which they wrote in GOOL, the precursor to GOAL. In fact, they wrote GOOL explicitly for Crash Bandicoot. Later, when writing Jak & Daxter, Naughty Dog developed GOAL. Sony ended up buying ND -- among other things, they were hoping to use ND's code, and were quite surprised to discover that it was all written in a homebrewed Lisp dialect.

You can see some GOAL here: https://web.archive.org/web/20070127022728/http://lists.midn...

[0] https://www.youtube.com/watch?v=izxXGuVL21o

⬐ bitwize

The two Lisps Naughty Dog developed had different (heh) goals. GOOL was more of a scripting language; GOAL was developed for close-to-the-metal programming and was used to write much of the engine for J&D.

⬐ kbenson

I just saw that interview with Andy Gavin last week, and I highly recommend it. The title is "How Crash Bandicoot Hacked The Original Playstation" and it truly fits. So much of what they did seems to have been crazy and beautiful performance hacks. Anyone that's had to work with severe limitations to achieve their goal and found crazy ways to make it work will see a kindred spirit.

⬐ lowtolerance

I saw this interview, too. It blows my mind that Crash himself accounted for a third of their budget for onscreen polygons, something like 550 polys, which is more than many PS1 games managed to render for an entire scene.

⬐ candeira

They also didn't use any texture memory for Crash; only shading. This went against all received wisdom, and shows how much they were ready to face every challenge posed to them by going back to first principles.

They also wrote a software-based Z-buffer implementation. And a custom compression system that allowed vertex-based animation. And scene streaming from disc. And...

https://all-things-andy-gavin.com/2011/02/02/making-crash-ba...

Previously: https://news.ycombinator.com/item?id=9278082

⬐ aliswe

Nitpick:

> Crash was 512 polygons in the first game, with textures only for his spots and his shoelaces, and his model didn’t change much through the 3 platform titles. It took me a month to settle on the perfect 512. As Andy said, we went with non-textured polygons instead of textured ones on most of the characters. Instead of texture, we used corner colors to create the textures that seemed to be there.

> There were many advantages to this strategy. The simplest was that we got more polygons. But we also solved a texture stretching and warping issue inherent in the PlayStation’s renderer that tended to make textures look terrible. Since you spent most of your time looking at the character, and he could get quite close to the camera, avoiding texture mess meant a lot for visual quality.

> And there was another important issue solved by using polygons instead of textures. The PlayStation tended to render every polygon as a pixel, no matter how small it got. Had Crash’s pupils been texture, they might have disappeared when the got smaller than a pixel. But by making the pupil 2 polygons (a quad), they almost always showed up as long as the total eye, including whites, was more than a few pixels tall. Subtle, but trust me, it made the game so much more clean looking. It’s the small things that matter.

Source: Jasons comments in part 3 ( https://all-things-andy-gavin.com/2011/02/04/making-crash-ba... )

⬐ candeira

Thanks, I'd misremembered something read almost a decade ago.

⬐ recrudesce

Duplicate of https://news.ycombinator.com/item?id=22439752 from 4 days ago.

⬐ dmbaggett

What a great video. Beyond the slick presentation with all the cool animations, it really captures what Andy's like as a person. Amazing talent of course, but also an almost perverse joy in doing things you're not supposed to be able to do within the constraints you have.

This brought back so many memories, including heroic stuff Andy and Mark did on the character animation that I had completely forgotten about. I also personally postdated the discussions about how to deal with an extra dimension -- I joined soon after work on Crash (then "Willy") began -- but that part was super interesting.

(For those wondering: I worked on Crash 1 and 2 with Andy, Jason, and the other mid 90s Naughty Dogs.)

⬐ mdonahoe

This is you, right?

https://www.gamasutra.com/blogs/DaveBaggett/20131031/203788/...

I really enjoyed that story.

I had a random question about this: I remember Crash 1 had a password-based "save" system where the player could skip ahead to a level if they entered the password for it.

Was the creation of that system motivated by the as-of-yet-unsolved memory card bug? Or was it just standard practice to support players that didn't buy the memory card? I can't remember many games using something like that, but it was a long time ago.

⬐ dmbaggett

That is me, yes -- thank you! Actually the password save capability was mandated by Sony. At that time they wouldn't approve your game if you didn't offer a card-less save mode. I guess they thought requiring people to have memory cards made the base system too expensive.

Fun fact: the code to convert the bits of saved game state to PS controller buttons used modular exponentiation, as in the RSA algorithm. Carl de Marcken suggested this method; I asked him to recommend something because at the time I really didn't know anything about hashing or crypto. There's an HN post somewhere from a guy who reversed engineered it.

After Crash I joined Carl at ITA Software (now Google Flights), where he was Chief Scientist.

⬐ ridv

Link to the post referred to in case anyone else is curious https://news.ycombinator.com/item?id=9376793

⬐ nolok

Many, many games of the older gens (before 2000) worked by "hacking" their console, if by hacking you mean using part of it in ways it wasn't supposed to or to do something entirely different from what it was supposed to do. From very old 8 bit era "gaming computer" cheating around their CPUs or CRT screens to achieve effects that shouldn't be possible (also very popular in the demo scene), to games on the Saturn being forced to use the mashup of random chips to their best advantage (like running some graphics computation on one of the audio chips), they had to make with what they had.

It's not so much that modern dev are not as capable, but modern console are much more malleable and offer much more power relatively speaking. Basically they're PC. The last console which required special tricks was the PS3, because the Cell was a weird ass architecture totally unsuited to mainly single core games, so devs had to do what they could to make it run well. When you look at old stuff, it's less "wow they were great to achieve that with such poor hardware" and more "I genuinely don't think it's possible to do that with the resources available ..." So they cheated. Or hacked. Whatever you want to call it.

The Saturn and PSX had some insane stuff. Go look at the tech specs of the PSX and tell me as a dev you think it's reasonnable to expect games like Metal Gear Solid, Crash Bandicoot, etc ... To run on that thing.

But still, the crown of "dev has to cheat around to do anything that wasn't 2d" remains with the Saturn, the best worst design ever for a console.

On PC we have few equivalent because our chips have always been very multi purpose, historically they were merely vastly underpowered compared to specialized hardware console had (which is why Carmack's 2d and 3d marvels in the early 90s were so impressive, getting an engine similar to keen or wolfenstein or doom isn't very hard, getting it to run fast on the hardware of the time ... Well there is a reason the guy's name is known the way it is).

War stories of developpers of that era are some of the best things to read as a non-dev game that enjoy reading about doing stuff you shouldn't be able to do. I remember reading such a thing about Panzer Dragoon II Zwei on the Saturn and it was so great, but apparently I didn't save the link and can't find it back.

⬐ chongli

Same goes for old PC games. My favourite example is Elite for the BBC Micro (and other machines as well). This classic GDC talk [1] goes into some of the details of what they accomplished. Brilliant stuff!

[1] https://gdcvault.com/play/1014628/Classic-Game-Postmortem

⬐ 737maxtw

FX fighter is my favorite example on PC. Sure, the mechanics were a little shallow and camera bugs because it's 3d in 1995, but it ran on a 486/66 surprisingly well!

Tie fighter and X wing are other examples in their own right as well. Maybe the graphics weren't that great, but I'm sure managing the game world, dynamic music and 3d at the time was quite the task.

⬐ nolok

Every 3d game on pc that didn't require a dedicated 3d card ans still ran somwhat well is basically a marvel, tech-wise

I also had a 486/66 and I loved that thing but it was slow as hell, what so many dev achieved with it is humbling

⬐ flatiron

I used a 486 66dx2 with 20 megs of ram until 2001 when I got a laptop for college. FreeBSD and console only programs but it got the job done. Did all my high school work on it and an external X2 modem. Even brought it to college and slapped a network card in it to act as a proxy server. They have us 1 gig of data per day. But they did it by MAC address not port. So I just had all my friends proxy over to that box and it would just change MACs right before the gig. Unlimited data!

⬐ Newtonip

Fun fact, FX Fighters development was originally on the SNES.

⬐ temac

A 486/66 ran Doom well and Duke Nukem 3D mostly ok. (Even a 386 run Doom, although quite poorly.) It's quite reasonable to be able to draw a few polygons on it at low res, although it can depend on tricks and skill of the programmer - including math approx yielding a visually good enough result for a fraction of the computing power required for the exact one - to get very good or mediocre results.

⬐ raverbashing

The Cell was a nice idea on paper but for games it seems beefy cores are the way to go

Though I find it ironic that (old) game developers would go out of their way to find out ways of making their games faster while modern ones are saying the Cell was too hard (but I get it, it's a different environment and business now)

⬐ BubRoss

The cell wasn't meant to be the main cpu at any point. It was thought that it could be the GPU. Sony out a separate GPU in later and left the CPU, GPU and cell all mixed together.

Also a lot of great stuff was eventually done with the cell. Hacks and tricks are great in small quantities, but the reality was that the cell had lots of power and potential, but sony have developers practically nothing to start. The documentation and examples were supposedly basically nothing.

Even for the CPU and Nvidia GPU each game studio had to come up with their own low level drawing. Studios were really starting from scratch with very little help from Sony. Add in that supposedly the cell required fine grained cache control and scheduling, and suddenly it starts to make sense why it left lots of studios frustrated. Sony marketed its power and then left studios to spin their wheels trying to live up to consumer's expectations.

⬐ pjmlp

Which is why they eventually had to release something like PhyreEngine.

⬐ pjmlp

Programming the PS3 only really took off when Sony released PhyreEngine.

https://en.wikipedia.org/wiki/PhyreEngine

Here some videos how it looks like

https://www.youtube.com/watch?v=rOptZgaPrSk&list=PLd4fN5qM6i...

⬐ pjmlp

Yeah, hence why the Demoscene was so interesting back in the day. Nowadays one has to create virtual limitations for the same sort of challenges.

Even game coding on one of the ESP32 or Arduino based consoles is much easier that it was for us.

Regarding "hacking" the PC, a famous example would be mode x, https://en.wikipedia.org/wiki/Mode_X

⬐ CM30

Well, you don't have to create virtual limitations. You can also work within real ones by coding for long since discontinued video game systems. The homebrew scenes for home computers like the Amiga and ZX Spectrum, and consoles like the NES and Game Boy are still going strong now.

Working on a game for those systems can be an interesting look into how development worked back in the 80s and 90s, and really test what limits you can push these systems to.

There's also the ROM hacking and modding scenes for old games as well. Whether its console games like Super Mario World or Sonic the Hedgehog or PC games like Doom, there's some insanely impressive stuff being coded for mods these days.

⬐ pritovido

The most interesting thing for me was the use of Lisp they did:

https://all-things-andy-gavin.com/2011/03/12/making-crash-ba...

To read this was a very important resource for my own education. I was shown the power of Lisp by a man that looked wired to emacs and so fast typing I could not follow him on the screen that solved problems orders of magnitude faster than me using this "wizard language" I could not understand.

It was mind blowing but at the same time very confusing, so I started searching material over Lisp that I could digest one step at a time and(combined with books I bought) that was very useful because it talked about real problems, not super simple simplifications like books did.

⬐ Flockster

A nice writeup about making Crash is this one: https://all-things-andy-gavin.com/2011/02/02/making-crash-ba...

⬐ favorited

That was written by the guy from the video, in case you didn't realize.

⬐ _bxg1

I've heard cool stories from game development before, but this guy is on another level. These aren't just neat hacks, these are serious engineering feats. Several of them. For Crash Bandicoot.

- A custom animation compression system

- A custom memory paging system between memory and disc

- Reverse-engineering the hardware and standard lib

Edit: Apparently at the time he already had a PhD from MIT and had worked with the Jet Propulsion Laboratory and MIT Artificial Intelligence Laboratory: https://en.wikipedia.org/wiki/Andy_Gavin

⬐ ddingus

I love to feel SONY recognized that.

"How things worked" ended up being two sheets of paper slid across a table... The SONY engineers:

"We have to tell this guy..." while thinking about seeing their hardware shine, perhaps brighter than intended.

⬐ ftvy

The animation compression system really stood out to me as well. It seems back when hardware was the limitation, people had to be literal geniuses to develop games. Now with so much middleware and so many pre-cooked engines available, people are left less with the challenge of accomplishing the technicals and more on creating an enveloping story and challenging gameplay mechanics.

⬐ NegatioN

The more I hear about Crash Bandicoot, the more I wish someone like Fabien Sanglard wrote a book about it. It seems like there are so many cool solutions implemented in it. It was also made at what seems like such a pivotal time for games, forcing so many innovations, such as those mentioned in the video.

Like the custom LISP-like scripting language called GOOL[0] which in its evolved form is still in use in some games for at Naughty Dog even today.

[0]: https://mobile.twitter.com/JoakimRi/status/11019084263540572...

⬐ karmelapple

Are you familiar with the 13 part blog post [0] from Andy Gavin that's basically a short book all about Crash's making?

[0]: https://all-things-andy-gavin.com/2011/02/02/making-crash-ba...

⬐ nicoboo

Really interesting video and great way to present with animations and awesome explanations.

⬐ grecy

That's really cool. I played Crash 1 extensively on Connectix Virtual Game Station, which was able to play virtually every major PS 1 game perfectly.

Impressive it did so well given all the tricks employed.

Does anyone have a write-up or details on the how/what/whys of Connectix Virtual Game Station? (And, while I'm there, what about Ultra HLE?)

⬐ apfsx

No info on the Connectix Virtual Game Station but you might like this video about UltraHLE. Sparks memories for me and I remember the day when Ultra HLE was released.

https://www.youtube.com/watch?v=2NF5sU_n0uk

⬐ _bxg1

I feel a little bit regretful that I became a programmer in an era when technical achievement doesn't usually translate to meaningful improvements in video game size/complexity/visuals. The games created today at AAA studios who employ hundreds and are constantly pushing the envelope only end up looking, subjectively, maybe 10% better than tiny indie games that run in Unity and have decent art direction. For most of us, there aren't meaningful limitations to be inspired by anymore.

⬐ nikofeyn

that time must have been such a special time to be a programmer and computer engineer. so much uncharted territory!

⬐ lostgame

Couldn’t agree more. I’m definitely never as impressed by AAA titles as I am with clever use of design in indie titles.

⬐ koralewski

What a great series! I also greatly enjoyed the Lorne Lanning (Oddworld) episode, he's a great hero of mine: https://www.youtube.com/watch?v=Y7f0YtzWBG4

⬐ manifoldgeo

I was very excited to see Blender used as the program for explaining 3d graphics concepts like bones. I was expecting them to use Maya or some other proprietary software. Excellent video all around!

⬐ Psyladine

Related articles:

https://news.ycombinator.com/item?id=9737156

https://www.gamasutra.com/blogs/DaveBaggett/20131031/203788/...

Context helps; Crash was the playstation mario (or more appropriately, Sonic), a mascot, first-tier title & hoped-for killer app for the new console. I used to have a direct link to an article where they copped to tapping system memory in violation of Sony's developer rules, but justified by the ends.

⬐ stordoff

The article mentioned in other comments (https://all-things-andy-gavin.com/2011/02/04/making-crash-ba...) seems to go into it:

> First and foremost, they didn't follow PlayStation's library restrictions. Other developers often complained that Crash was using some sort of secret Sony library. That is the exact opposite of the truth. The truth is that Crash used as little as it could of Sony's library and the programmers basically hacked everything right to the hardware.[...]

> Hitting the hardware directly was against the rules. But by the time Sony saw the results they needed a Mario killer. It was too late for them to complain.

⬐ bitwize

Sony's developer rules are like YouTube's content policy: arbitrarily restrictive, but may be waived for favored parties. For example, SCEA (but not SCEJ!) had a "no sprite games" rule. The American marketing for the PlayStation leaned heavily on its 3D graphics and overall "next-gen-ness". Games that relied heavily on 2D sprite graphics were seen as detrimental to the console's image because they looked like something from the fourth console generation. But big-name developers could get exceptions for flagship titles, as Capcom did for Street Fighter Alpha and Mega Man 8. So we lost out on interesting sprite games from smaller developers that were released in the Japanese market because of this policy.

It's no surprise, therefore, that Naughty Dog got away with violating a Sony policy -- even about messing with system memory -- to create a "system seller" title.

⬐ Psyladine

Yes, the article in reference mentioned other developers harboring conspiracies like ' secret PlayStation libraries' supposedly at naughty dog's disposal, but actual credit by the developers was to their use of Lisp as a secret low level language, though admitting they also bent\broke some rules in the process.

⬐ AdmiralAsshat

Has anyone ever dumped/reverse engineered the official Sony SDK/libraries for the PS1? I'd just be curious what the C code looked like.

⬐ archeantus

I loved every second of this video. And I also loved every minute I spent playing and beating this game as a kid. Such an amazing game!

⬐ marknadal

This was a phenomenal interview, learned many rich nuggets.

I'm curious to go back to the "old days of graphics" with limited RAM, loading from slow CDs, etc. & program like that myself, where can I start?

⬐ SeanFerree

Loved this game!

⬐ sokoloff

Admittedly way less thorough/cool than the YouTube video, but we created a limited pre-emptive multi-tasking system on the original Playstation to run our physics engine at a constant frequency. Sony US and Sony Japan said it couldn't be done.

We eventually figured out how to use the vertical blank interrupt to save all the registers, modify the return addres 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: our game was comparatively terrible and I remember being in awe of what the Crash Bandicoot team accomplished in gameplay and graphics.

⬐ dmbaggett

That is super cool. At the time -- I was like 12 -- all those horizontal and vertical blank hacks on the Atari 800 seemed like total black magic to me. I had no idea you could even hook the VBLANK or HBLANK interrupt on PS1. Wow.

⬐ someperson

Which game was this?

⬐ sokoloff

NASCAR Racing - https://en.wikipedia.org/wiki/NASCAR_Racing_(video_game)

Even as the tech lead on the product, I have to agree with the critical commentary in the PSX section of that page. Our company's stock in trade was realism and it hurt us with the mainstream gamers on the PC side, but was even more severely limiting on the console audience. (We also didn't crush it on the execution side on the PSX port.)

⬐ jakearmitage

Dude, you have to blog about stories like these. It's amazing. Don't underestimate how interesting and fascinating your experience is!

⬐ EvanAnderson

Based on the grandparent poster's comment below re: the coordinate system and physics engine I have to second this comment. I never played this game and have little interest from a gaming perspective, but I'd love to hear about it from a development perspective.

⬐ Lutzb

I have to use this opportunity: Thank you for all the great IndyCar and Nascar titles released over the early years of the PC platform. The Papyrus racing title hold a very special in my heart/childhood.

⬐ LoSboccacc

one of my most memorable quotes from childhood is not the halo theme but

"I'm Paul Page, from papyrus, this is Indy car racing two"

⬐ sokoloff

Thanks! There's definitely a cult following and a lot to be proud of, but I have to say that Dave, Randy, Adam, John, Matt, Charles, Anne-Marie, and the rest of the team deserve 99+% of the credit. I played but a bit part (and really enjoyed every moment of it).

⬐ ploek

Oh wow!

For reasons unbeknownst to me, my father had that game for the PC. It was one of two games in our household at the time (The other being "Mario Is Missing!" https://en.wikipedia.org/wiki/Mario_Is_Missing!).

I played that quite a bit, but I think I spent most time painting the car, because I wasn't any good at the actual racing.

⬐ nwallin

It was bundled with the matrox millennium, which was the best video card available.

Unbenounced to 14 year old me, the matrox millennium had a flat shaded polygon 3d acceleration capability, which made NASCAR run pretty well if you turned textures off. (which is why it was bundled with the card) I kept textures on because I didn't know any better, and the game ran fairly poorly. Ultimately I never played it very much because the framerate was frustratingly low.

Damn shame. It was years later that I found that out. Of course I was terrible at it anyway, so it probably wouldn't have mattered anyway.

Anyway, that's probably why your dad had the game.

⬐ sokoloff

Yeah, you have described the essence of the problem. The game was quite realistic, enough that rookie Cup drivers would use the product to get familiar with tracks they'd not yet raced on, but that level of realism made it not so fun for the casual gamer. (It turns out that racing cars at the top professional level is actually hard and not something you pick up in 15 minutes.)

We would go to NASCAR events, weigh and measure car components, talk to the crews/drivers, and most of us even got the first level of competition license (typically 3 full days of classroom and on-track instruction and then 3-6 more days of individual mostly track time) so we understood what driving a racing car near, at, and slightly over the limit was like.

The PSX product introduced a feature that later made it back to some of our PC titles, called "Arcade Mode". It was still racing (in that skill mattered), but arcade mode gave the cars far better braking, allowed them to slide and pivot more but spin out less (by changing tire slip curves), and gave drag reduction to cars that were losing the race. We also introduced the smoky burnout/donut ability which immediately made it into the PC title (but had a bug that caused a smoky burnout to be the fastest way to launch the car from a standing start, which critics [rightly] hated).

At the end of the day, fairly few people are interested in very realistic racing. (Many of the ex-Papyrus team are over at iRacing now and they're on the ultra-realistic side of things.) If you want to sell a mass-market game, ultra-realism doesn't sell as well as fun and engaging gameplay.

The end state of this drive for realism was https://en.wikipedia.org/wiki/Grand_Prix_Legends which I worked on some of the early code for, but left before it shipped. Even in the early stages, with the best computer and graphics card of the day, a full set of physical controls (including force feedback steering), it was difficult to drive the car around for a single lap at 9/10ths pace, let alone race them in traffic.

⬐ siver_john

I remembered attempting to play this game on my Dad's playstation as a kid and always crashing. Glad I can now blame it on the fact the game was "too" realistic and not my poor skills as a young child. (But let's be honest it was definitely the fact I was a young kid who had no clue what I was doing). This was a fun memory to walk down though so thanks for that!

⬐ mirsadm

Thanks for taking the time to write that! It's super interesting. Have you stuck with games dev since then?

⬐ sokoloff

No. If I wanted to stay in games, I’d have 100% stayed with that crew at Papyrus then Sierra and then gone to iRacing with them. Excellent colleagues all around: super talented, super interesting to work and eat/BS with.

I wanted a family and financial security and the game industry wasn’t going to take me where I wanted to go (and I worked on generally successful titles for a successful company; most game devs have it even worse). The Sierra Online acquisition was great; loved meeting and talking about games with Ken and Roberta, but then the subsequent spate of acquisitions just killed a lot of the joy and essence of what made the day-to-day work fun, so that also made it easier to leave.

⬐ InitialLastName

If it helps, one of those Indycar games got 6-year-old me into a sim racing addiction that has followed me for decades.

I went from driving backwards on track to make crashes happen (thanks for not making rules that stopped me from doing that!), to driving faster than anyone else (because my engine was turned up and I turned down the AI), to actually trying to race as my cognitive abilities (and interest in challenge) improved.

⬐ burnte

Back then you could still sell PCs as a small shop and make money. I had a guy buy an entire PC custom built just for that game. I remember him and this game very clearly because I was cycling, dislocated my kneecap, and had to go to the ER, so his delivery was delayed. I found him in my driveway when I got home from the ER. he looked at my leg in a brace and said, "Oh, I'm so glad you're actually hurt!" He though I was scamming him and waited for me to see if I was really injured.

⬐ J5892

Ha. The guy's train of thought was clearly, "If this guy's legs aren't broken, they're going to be."

⬐ agumonkey

Oh you worked at Papyrus !

Man I spent so many hours playing the PC version (Matrox Millenia era) and the physics engine got me hooked (and the car body editor). Saving replays just to see how multi car crashes would look like (sometimes even self cancelling multi agent collisions)

A time traveling thanks

⬐ ndesaulniers

Ditto, I remember driving around the course backwards and wrecking all opponents. I probably spent many hours as a seven year old just doing that. So much fun!

⬐ agumonkey

Same same, although my favorite was trying to bump opponents on there rear wheels, just enough so they'd make long drifts and chaotic spins.

⬐ ilikecakeandpie

FWIW my dad, who is a lifetime NASCAR fan, loved the realism

⬐ sokoloff

Cool. I'm not involved with the iRacing team at all, but they have a NASCAR offering and your dad may consider checking that out.

⬐ zelon88

I remember playing this on DOS with my dad. It was one of the games that got me into computer gaming, so thank you for that. For me, personally this one was up right up there with Wolfenstein 3D and the Wing Commander series. One of my favorite parts of the game was decorating the cars with paint and decals. Papyrus also had Indy Car Racing which I also enjoyed.

⬐ beardedwizard

Dude this game was therapy for me as a kid. Thanks.

⬐ 6374532

This was one of my favorite games to play as a kid. I played it for many hours. The physics, engine sounds, in-car view were really impressive. It is still my favorite racing games to this day. It left a greater impression on me than any other racing game I played since. One question I had is, why weren't cars able to flip upside down in the game? This wasn't a large negative, as the the way the cars crashed and showed damage was quite good. I laughed so much as a kid playing this game, it was pure excitement for me.

⬐ apearson

I share somewhat the same memories. I remember putting hours and hours into that game to see what was possible and what were the limits. One of the earliest memories I have of figuring out how software works and what it's limits are.

⬐ sokoloff

The coordinate system for the race management/graphics engine in that game was a 2D system (and in fact was (lat, long) on the track, rather than (X,Y)). We'd convert the (lat, long) into (X, Y, Z) coordinates, take into account the banking and track surface under each tire [painted lines were slightly more slippery than asphalt], do all the physics computations, then cast the (X, Y, Z) back to (lat, long) to send it over to the race/graphics world.

Why? Longitudinal measurements are natural for "who's in the lead?" type of questions and all of our track editing tools also worked in lat/long coordinate space.

⬐ unwind

Just to clarify, do you mean polar coordinates [1]?

That would absolutely make sense for a game centered (heh) around racing around a closed track, clever!

[1] https://en.wikipedia.org/wiki/Polar_coordinate_system

⬐ sokoloff

Not exactly. Polar is r-theta. The system we used was an x-y system, but one where the coordinate system alignment changed for each track segment. So, think of a world where a straight line in y ["longitude"] was projected into a constant path relative to the centerline of the track's racing surface.

(While most NASCAR tracks are ovals and could be represented in polar coordinates fairly naturally, they do have some road courses and the physics and game engine originated in the IndyCar game, which has even more road courses.)

⬐ raverbashing

Wow, that's amazing, a lot of time spent on that game :) Thanks for a great game!

Your coordinate system make sense, and the 3D engine/physics was pretty good for something running on CPU only. (If I remember there was only one or two non-oval tracks)

⬐ michaelgrafl

I think that's pretty cool.

⬐ saber6

Wow this is a great story!

I remember playing Crash Bandicoot on the original PS and being wowed at the physics.

Thanks!

⬐ weinzierl

Sounds awesome and reminds of the good old times. I don't know much about consoles but in the home computer era, a ton of the awesome stuff was accomplished by clever trickery triggered by interrupts generated by the electron beam.

The Commodore 64 for example could trigger an interrupt at an arbitrary screen position and not just H-blank or V-blank. We used to call these raster interrupts. Graphics on the screen border, simultaneous graphics and text mode, split screen effects, more than 8 hardware sprites and the light pen were all things that were only possible on the C64 because of that capability. If you want to learn about this check out Shallan50k on Twitch, he does awesome streams about these techniques. The Acorn is a good counterexample of a much more powerful machine which lacked the ability to do raster interrupts and that is in my opinion one major reason the Acorn had relatively poor graphics.

⬐ jlarcombe

Yes. It's possible to do on the Acorn but few games at the time took the trouble to do so. It requires very accurate cycle counting. There have been a number of recent demos that take things to the next level though, and someone has even got raster interrupts working on the Electron, which is frankly astonishing: https://www.youtube.com/watch?v=PUl1SGUSkbI

⬐ weinzierl

I've also heard that there is a hardware mod to give the Acorn true raster interrupts.

⬐ ddingus

Like the Apple 2, having so much logic exposed, due to use of discrete logic chips, there are mods to do lots of things.

⬐ sokoloff

I cut my teeth on the Atari 8-bits, where we used vblank and hblank interrupts for all kinds of tricks like you described. The inspiration for this solution came directly from that experience.

Side note: I was always jealous of the way better sound hardware on the C64. It's also crazy to me to think that I paid probably around $1000 in 1981 dollars (equivalent of $3500 today) to buy an 8-bit computer with 48K of RAM.