http://www.mobygames.com/developer/sheet/view/developerId,34...
Interestingly, they obviously got over it as BB was used for 3DO DOOM.
Longer answer: The overarching idea is to respect the person's wishes and stated identity. In most cases, and certainly in Rebecca Heineman's case from what I've read, she always identified as female even when she was known as Bill Heineman. So out of respect we would typically refer to her as Rebecca (or with female pronouns) no matter which part of her life we're referring to.
There could be exceptions. In some cases, a person's former gender might be directly relevant to a story. (Imagine you're writing about a person, now female, who was sent to a boy's boarding school as a child. I think, at the least, you'd perhaps need to clarify that she identified as male at that point in her life...)
http://en.wikipedia.org/wiki/MOS:IDENTITY
2nd bullet point
Interestingly, it seems to include a translation of Carmack's Jaguar rendering engine into C. The original was implemented in assembly for the Jaguar's proprietary RISC coprocessor. The processor's tiny instruction memory required that the renderer be split into 9 independent "phases", and that organization is preserved in the 3DO code.
"The library builds and runs for the Xbox 360, PS3, PS4, nVidia Shield, iOS, Mac OSX, MacOS, Android, OpenWatcom for MSDOS, OpenWatcom for Windows, Visual Studio 2005, Visual Studio 2008, Visual Studio 2010, Visual Studio 2013, Codewarrior for Windows, Codeblocks 13.12 for Windows, Codeblocks 13.12 for MacOSX, OUYA, Nintendo Wii, Nintendo DSi and Linux." - Burgerlib[0]
I don't know why, but I find that immensely satisfying.
switch (gamemap) {
case 24: /* Secret level? */
nextmap = 4;
break;
I'm seeing QuickDraw PICT files, the make files seems to use Classic Mac-style file paths (Disk:Directory:File), and there's even an AppleScript in there referencing DeBabelizer 1.6 (who else remembers THAT app?)
edit: looks like the official 3DO development kit was Mac-based, and there was even a NuBus card with 3DO hardware on it for debugging
So I apologize for posting this and being a little off topic, but how do people disect these effectively?
- clone it so I can read the code in emacs, and use cscope or similar tools on it
- try to figure out the build system and the directory structure: how is the main program built? are there libraries or tools that are also built? where do their sources live? (so, here, I'd start with source/doom.make and look at the things it references)
- if my primary interest is the main program, I would then try to track down main() and jump through the functions that look interesting with ctags or similar code navigation tools;
- usually it makes sense to jump back and forth to the header files that are being referenced, not only to understand what the types and globals are, but also because they tend to reveal information about how the code is organized.
I usually focus on an area I'm especially curious about if I'm not trying to understand the whole program. For example, in games like this, I'll try to find assembly files or places with inline assembler, because it's usually interesting to see what the developer felt was performance-critical or hard to achieve from C. Then I'd find the functions that call those assembly routines and read them, et cetera.
Taking notes can help, like sketching the module structure or the major data structures on a whiteboard and trying to fill out how they interact. These days I use org-mode for taking notes about code I'm reading, because it makes it very convenient to capture links to specific sections of code (or specific commits, with org-magit) and make notes about them.
If I really have to understand it, I try to get it to build, add tests to the codebase, and maybe try adding a specific feature. But that would apply more to something like the Doom codebases that still build on modern platforms rather than a retro artifact like this.