There's a simple header, and then it's just a bunch of binary files concatenated together. In fact, as we'll see later, GOAL doesn't really distinguish the two concepts. However, don't be confused by the names - just because they imply code and data separately, the contents are in fact mixed and can contain both code and data interchangeably. It tends to be that CGO files are loaded into the common heap, and DGO files are loaded into the level heaps. There's no actual difference between them, I presume the names just reflect the usage (code/data?). If you look on the disc, the main files used here are called "CGO" and "DGO". So where does the loader get its data from? First we need to examine the file formats used here. Once the level is finished with, it just throws out the entire heap and starts again. The loader just uses a simple bump allocator to throw new data on the end. The common heap contains the core engine code and data. The game has two levels loaded at any one time, each getting their own self-contained heap (this is what allows you to seamlessly walk from one to another). The loader generally tracks 3 different memory heaps - the common heap, and two level heaps. That's basically it there's no VM or interpreter here. Once this is done the data is ready to go. It then relocates the pointers to the new address, and patches up any references to the global symbol table. It sits waiting, and when new data arrives from wherever, it allocates space on the heap and copies the data there. For whatever reason (lack of attention possibly), Naughty Dog forgot to strip the ELF symbols from this file, which means we can open it up in any MIPS disassembler and follow its logic through. This is the first thing that loads, and is just a regular PS2 ELF compiled with gcc. If you want to follow along at home, you'll need a copy of the PS2 J&D disc or ISO, and the source code I've posted at the end here. What this means is that if we can understand the data format, we can get a complete symbolic disassembly of the whole game. Therefore the symbol table must be present in the runtime data. There is no offline linker, everything is dynamically linked. And this is what this article will be picking apart, as it forms the gateway to everything else.īecause GOAL has its origins in Lisp, one of it's hallmarks is that symbols are considered a first-class datatype. This is the equivalent of their DLL loader it's just a simple stub program to load the rest. The only part of the game not written in GOAL is the loader/linker, which is written in C++. I don't know of any other games out there that do that. To create your own programming language, from scratch, and then write the entire game engine in it. It's a hell of a thing, when you think about it. GOAL is a fully natively-compiled general purpose programming language, and the whole game is written in it. I want to really nail this point home here - some people think it's some kind of bytecoded scripting language. GOAL, standing for "Game Oriented Assembly Lisp", is the programming language J&D is written in. There's a lot to talk about, but today I'm going to ignore all the cool graphics tech and such, because I want to focus on the most amazing element: GOAL The audio contains some additional Q&A not in the slides. The Technology Of Jak & Daxter, Stephen White (GDC 2003) The most important for you to read would be Stephen White's 2003 GDC talk, "The Technology Of Jak & Daxter", which I can't find a link to any more but I've mirrored here: There's not much information out there about it, but there's a few snippets here and there. Of course, because it's not open source, it doesn't get the recognition that more famous engines like Quake get. The J&D engine may possibly be one of the greatest engines ever made. A game where you could see and explore a vast world with no boundaries. Here was a game running at a silky-smooth 60Hz, never missing a beat, and somehow managing to draw more polygons than any other game out there. But Jak & Daxter, hereafter referred to as J&D, blew me away. I was used to PC games like Quake which were software rendered, or games like Mario 64 which I played (and completed!) on UltraHLE at a woefully poor framerate. It was one of the first 3D games I'd actually seen run at 60Hz. I've always had a fascination with Jak & Daxter ever since it came out, way back in 2001 on the PlayStation 2.
0 Comments
Leave a Reply. |