| |
| ▲ | dmbaggett 20 hours ago | parent | next [-] | | I don’t know about other developers at the time, but we had quite a lot of hand-written assembly code in the Crash games. The background and foreground renderers were all written in assembly by hand, as was the octree-based collision detection system. (Source: me; I wrote them.) And this thread comes full circle: Mark Cerny actually significantly improved the performance of my original version of the Crash collision detection R3000 code. His work on this code finally made it fast enough, so it’s a really good thing he was around to help out. Getting the collision detection code correct and fast enough took over 9 months —- it was very difficult on the PS1 hardware, and ended up requiring use of the weird 2K static RAM scratchpad Sony including in place of the (removed) floating point unit. GOOL was mainly used for creature control logic and other stuff that didn’t have to be optimized so much to be feasible. Being able to use a lisp dialect for a bunch of the code in the game saved us a ton of time. The modern analogue would be writing most of the code in Python but incorporating C extensions when necessary for performance. Andy made GOAL (the successor lisp to GOOL) much more low-level, and it indeed allowed coding essentially at the assembly level (albeit with lispy syntax). But GOOL wasn’t like this. | | |
| ▲ | deaddodo 5 hours ago | parent [-] | | I've never seen the Crash source code, so was making my statements based on second hand knowledge. So thanks for that clarification. I do think it's worth pointing out that Naughty Dog and Insomnia were two companies well known for making highly optimized software for the PSX; so probably not a standard most other companies matched. Additionally, I have written my own PSX software as well as reviewed plenty of contemporaneous PSX software. While many have some bit of assembler, it's usually specifically around the graphics pipeline. About 90+% of all code is C. This is in line with interviews from developers at the time, as well. The point wasn't that ASM wasn't used at all (in fact, I specifically acknowledged it in my original post), it was that the PSX was in an era passed the time when entire codebases were hand massaged/tuned assembler (e.g. "the 16-bit era" and before). | | |
| ▲ | dmbaggett 11 minutes ago | parent [-] | | Insomniac was down the hall from us when we wrote Crash 1 and yes, the Hastings brothers definitely wrote some very tight assembly code! |
|
| |
| ▲ | p_l 2 days ago | parent | prev [-] | | 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 2 days 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. |
|
|
|
|
