Naughty Dog's GOAL was PS2 specific and essentially chock full of what would be called intrinsics these days that let you interleave individual assembly instructions particularly for the crazy coprocessor setup of Emotion Engine.

My understanding is that the mental model of programming in PS2 era was originally still very assembly like outside of few places (like Naughty Dog) and that GTA3 on PS2 made possibly its biggest impact by showing it's not necessary.

▲

deaddodo 2 days ago | parent [-]

If by "mental model" you mean "low-level" programming, sure. But you might as well conflate "religion" with "Southern Baptist protestantism" then. You're working with the same building blocks, but the programming style is drastically different.

The vast majority of PSX games were done completely in C, period. Some had small bits of asm here and there, but so do the occasional modern C/C++ apps.

To your last point, before there was GOAL there was GOOL (from the horse's mouth itself):

https://all-things-andy-gavin.com/tag/lisp-programming/

And it was used in all of Naughty Dog's PSX library.

▲

p_l a day ago | parent [-]

The quote I recall reading about long ago summarized the semi-official guidance as "write C like you write ASM".

Because outside of ports from PC, large amount of console game developers at the time were experienced a lot with with programming earlier consoles which had a lot more assembly level coding involved. GTA3 proved that "PC style" engine was good enough despite Emotion Engine design.

Didn't help that PS2 was very much oriented towards assembly coding at pretty low level, because getting the most of the hardware involved writing code for the multiple coprocessors to work somewhat in-sync - which at least for GOAL was done by implementing special support for writing the assembly code in line with rest of the code (because IIRC not all assembly involved was executed from the same instruction stream)

As for GOOL, it was the way more classic approach (used by ND on PS3 and newer consoles too) of core engine in C and "scripting" language on top to drive gameplay.

	▲	deaddodo a day ago \| parent [-]
		> The quote I recall reading about long ago summarized the semi-official guidance as "write C like you write ASM". You could read that in pretty much any book about C, until the mid-00s. C was called "portable assembler" for the longest time because it went against the grain of ALGOL, Fortran, Pascal, etc by encouraging use of pointers and being direct to the machine. Thus why it only holds a viability in embedded development these days. I've written C on the PSX, using contemporaneous SDKs and tooling, and I've reviewed source code from games at the time. There's nothing assembler about it, at least not more so than any systems development done then or today. If you don't believe me, there are plenty of retail PSX games that accidentally released their own source code that you can review yourself: https://www.retroreversing.com/source-code/retail-console-so... You're just arguing for the sake of arguing at this point and, I feel, being intellectually dishonest. Believe what you'd like to believe, or massage the facts how you like; I'm not interested in chasing goal (heh) posts.