Hello all. I was the lead programmer for the original version of Tomb Raider for the Gameboy colour. I remember seeing many other CGB games that were just GB games with colour. They made no use of the extra power the machine had. The x2 CPU speed was obviously an advantage, but the HDMA and VDMA + the double-size VRAM were the keys for me. I ran the game at 30 frames per second. All the sprites were double-buffered which meant all 40 of the 8x16 tiles (anyone who doesn't use double-height sprites needs looking at IMHO). I also kept a copy of the entire background screen in RAM. We never used it, but it meant as well as using animating characters (Dumping new data into the chars on a per-gameloop basis) the actual character-map of the entire screen could be altered. I saw this effect first on a C64 game in about 1986. They had a level set in a lava pit and big gouts of flame shot up, rolled over and dropped back into the sea of flames. Apparently, the programmer had decided (as I later did) to run the game in 2-frames (so 25 FPS on PAL) to add more to it. The character was made of multiple overlayed sprites (like TR GBC) and the gouts of flame were done by re-writing 16 characters AND reprinting the appropriate background characters. The C64 had a 1MHz 6510 and no DMA, so this was quite a task. He also scrolled the colour-map (in color mode, the c64 had 2 fixed colours per character and one you could change). Since scrolling the whole screen (40x25) too too long, he assigned colour on a per block (blocks were 4x4 tiles/characters) and simple did 1 read & 4/7 writes (4 for one-axis scroll, 7 for both axes scrolling). Even further in the past I helped design the conversion of a vertically scrolling arcade shoot-em-up. I told the artist to use 1 colour in each column of the block so only 4 reads & 4 writes were needed to scroll a 4x4 tile/character map. Looking back, I'm annoyed I wasn't as well up on digital electronics as I am now. I know the machine had a 68000 for game logic, a graphics engine with hardware sprites, playfields and DMA AND a Z80 based sound-board. I remember the musician having to get someone to play through the whole game so he could listen to all the music and SFX (which he recorded on a tape deck). I remember that the ribbon connector betwen the main board and the sound-board was 16-bits. I am betting now that it was 8-bit data, 8-bit address. With a simple logic-probe I could have a)tested the signals going to the board & b)make the board play all the music and SFX at my command. I cannot remember who did the game, but I'm pretty sure that the sound board was similar to the Megadrive/Genesis. I don't know if anyone else has written a Z80 player for it, but it was jolly useful to the coders of the day. They just dumped the code and ran it. Then it was 1 call to start/stop music and another to select a SFX. The ODD thing about the Genesis sound was that the channels were numbered 0,1,2,4,5,6 suggesting that it was a cut-down 8-channel chip. I keep remembering how much trouble I had with the last 3 channels working properly. I used to do a multiply (well, shifts and adds) to get the channels control-register address. Then I had to add a check for greater than 2 and if so, add 1! I did some code on the N64 as well. It was, in fact, an excellent maching as long as games were designed with it's hardware in mind. It had a small texture cache but it did support trilinear interpolation and such. It even had a nice 3D algorithm. Those who remember, will tell you that the N64 had a CPU and a GPU which was, in fact, another CPU except it could only run from it's own scratch-pad (scratch-pads use 1/2 the silicon of an equivalent cache). You loaded the sound code, updated the stereo-DAC buffers, then loaded the matrix engine, finally you loaded the render code and voila, your image became real. The N64 had some really cool tricks. It used the parity bit off the RAM so that the Z-buffer was 18-bits. It was a pity the main CPU couldn't access memory like that. But, hand it to Nintendo, it was a GOOD idea. Later, I will update my experiences on later machines...
Hi! Well, you said about N64 and Tomb Raider. My favorite console and my favorite game. =) Seeing you worked with N64, can you tell if it was possible to make the first Tomb Raider in the N64? Or, back in 96, the only issue was the cartridge size? Thank you. ^^
Well, it could have fitted onto a cartridge with judicious texture redesign. The problem was that the N64 had a very specific way of doing it's 3D. It was great if your game was designed with that in mind, but by the time we came to do an N64 title, we had already commited to a route not suited to the platform. Also, since Eidos were publishing the title, the initial outlay in cartridge production would have been a HUGE outlay. We did convert Fighting Force to the N64, but frankly it was a second rate game to begin with. Oh, interesting fact, Sega agreed to give us a BIG discount on disc production if we released the Saturn version a month before the PS1 version. What a powerful weapon Lara was back then. Of course, then Core dropped the ball with the PS2 version by choosing an inexperienced lead coder. He had done 1 game before and even the we had to draft in another coder to sort the mess out. He did something like 8 months work for the PS2 version and then left. He was Danish and so was all his commenting of the code. Hence the project was restarted with 8 months left... and thus it was screwed.
Thanks for the post Piglet, I enjoyed reading about your history in the industry. I myself can only dream of having such a skill set to talk about, especially when it comes to the GBC for which I have a very big soft spot :thumbsup:
Well, my friend, I MAY be able to place the TR source-code. It was developed using the Intelligent Systems hardware devkit, but I'm sure you could get it working. The engine could do so much more. In the second game (I wasn't involved) Dan (the coder) added colour splits and parallax effects. The fact it dumps the entire screen per gameloop means that massive, impressive effects. I think I still have a modified GBC for the IS kit, so maybe you can make use of it? Whatever else, please feel free to ask me any questions, any at all. If I can answer, I will. If I cannot, I will ask others. The GBC is a wonderful platform to begin your coding career. Remember, it's NOT a Z80, it's an 8080 with the Z80 bit instructions added (oh, and LD A,(HLI), LD (HLI),A and HALT. TR ran in about 1.5 frames so I halted the CPU until the VBlank interrupt brought it back to life. If I remember correctly, Jeff Frohwein did some power-usage tests on various games and TR was sort of mid-table. I learned to code from a mixture of demos (age 13-14), from hacking and improving commercial games (C64 Ghosts and Goblins had a sprite-multiplexor but his sort routine sucked. It was a bubble-sort but it didn't take advantage of the fact that on each outer-loop, one more item is sorted so for his 16-sprite multiplex, the loops should have been 16,15,14,13... and so on. You can also flag than nothing was swapped so your finished. Well, the sort could take 1/2 a frame so the game dropped into 2 frames. I rewrote it, added a trainer & a very simple copy routine (SYS XXXX to turbo-save to tape, SYS YYYY to slow-save to tape, SYS ZZZZ to save to disc. All it did was switched out the BASIC rom to save data behind it (similarly with the system ROM which sat over the last 8K. Then the graphics stuff sat between $d000 & $dfff. After saving upto that point, I copied the data over previously saved data & repointed the source. It just meant that you could load the game from tape or disc and enter a single command to save it out again. The turbo-load was stolen from a magazine. We also stole the Novaload source (it displayed pictures, had a block counter and a text string scrolling across the bottom). We rewrote it a lot to increase speed from 3000 baud to 3400 baud, changed the front-end and called it 'Potato Load'. Fun times in the early 80s. Please, feel free to ask on any subject. I love to share knowledge. When I was young, people like Tony Crowther and Jeff Minter would give me routines and stuff. In fact, Tony gave me a copy of the stolen Ocean developement kit which linked a C128 to a C64 and transferred the data over a parallel connection. Wow, it made SUCH a difference... Regards, Sean ;-) PS, Like I said, get a GBC emulator, run TR and hit down,right A & B all at once. You see a series of hi-res images, the first one is me. We used the trick of rewriting the palette on every line (we could only do 1/2 on each line) still, we got 2304 colours on-screen and impressed Nintendo...
Nice read! I did myself some GBC coding but nothing as much advanced... yet. Checking others sources is a bit spoiling but I wouldn't mind if you posted it. Some time ago guys at Slitherine were about to publish T-Tex sources but I think it didn't happen unfortunately.
Fascinating read. I'll admit some of it went over my head, but it surprised me how much of it I picked up. I've also got a bit of a soft spot for the GB range and TR is one of those titles you happen to hate or love. I happen to be a fan and would love to hear more about it.
Hi! Thanks for sharing these infos. Everything is greatly appreciated. Well, if you can answer some more questions... ^^' Eidos simply didn't thought about releasing Tomb Raider for N64? I mean, in the Dreamcast days, with The Last Revelation and Chronicles. With compression technology like those used in Pokémon Stadium, Resident Evil 2, some Star Wars games, etc. Could Eidos get that kind of technology? Or because Eidos is UK based and the N64 wasn't an Europe success they simply didn't want to? Can you tell about Tomb Raider 2 and 3 and Sony? There was an exclusivity contract? And, sorry for so much newbie questions... But, you think the Dreamcast could handle The Angel of Darkness? =D
hmm.. I see you're a guy of concrete talking. Don't like to wonder things... Well.. if someday you wanna answer, just throw me a pm... It'll be very nice. =)
