Project Diary : robotfindskitten2600 by Jeremy Penner You are robot. You find kitten.

20:13 25/10/2003 After a 6-month absence or so, I've randomly come back to this project and put together what I consider to be a fairly decent text-copying kernel. Any given NKI can have a variable number of lines up to 15, and a variable number of characters per line up to 12. The kernel uses 12 scanlines per line of 6-scanline-high text, but it does it consistently -- calculating the number of scanlines to waste after all the text is displayed is completely straightforward. As well, I tightened up the font that I stole from Dark Mage, then undid my optimizations by uncommenting out the extra letters that weren't used. Grab the new demo. If you're trying it on a real TV, I'm aware that it'll roll when you switch from the text screen to the playfield screen -- it's just a lazy joystick button debouncing loop. It'll go away. =] I've also been thinking over my current method of storing the kitten positions as a gigantic, preformatted playfield that I just have to spew out in my kernel. I'm really beginning to doubt the wisdom of that. Calculating the NKI text associated with a given position will be murder, and it eats up a psychotic amount of RAM. A couple of scanlines pause in between rows while I calculated a new would be more than acceptable. And it'd be straightforward to sort the NKIs by display order when I generate a new game (whenever that code gets written), if a bit non-deterministic. I think I'd be happy with a TV roll on reset, though. Gives it an authentic flavour.

15:56 26/04/2003 The main graphics kernel is done! It outputs a steady 262 scanlines, joystick debouncing is implemented, and robot shows up properly. I'm not sure the flicker isn't a little much, but it's hard to say until I see it on a real TV. The alternative is to flicker the entire playfield to get everything looking uniform, so I imagine the flickering horizontal line of NKIs is good enough. I improved robot's flickering quite substantially by simply leaving GRP0 set while the playfield scanline was drawing; a '#' looks decent enough with any of its horizontal lines doubled. Now he kinda looks like he's got antialiased edges. Grab the latest ROM here. Jobs left: Collision detection, random playfield generation, merging the Stellar Track text engine. I've got acres of ROM space left still, so I'm hoping I can fit everything into 2k, and then have three 2k banks of NKI text. I suppose I should begin looking into bankswitching soon, since I really have very little idea how the various schemes work and which one might be most appropriate. Also, I have no idea how my choice of bankswitching might affect my ability to get actual carts built. I'm probably going to take on adding text next. I'm sick of my blobs. =]

16:17 23/04/2003 Progress! I've put together the first crack at the main game kernel (just an asymmetric playfield with a sprite on it), which reads the map out of RAM, displays it, and sort of shows robot. I had to do some flickering to get the sprite to work with the asymmetric playfield -- I just couldn't fit everything into the 20 or so cycles I had left in the kernel. And because it's asymmetric, I couldn't make it a 2-line kernel. No wonder I have so many problems with my graphics; all I do is 1-line kernels! =] There are still some timing problems with the flickering that I've been unable to figure out as of yet, but you get the new ROM here. You can move robot around (very quickly, no debouncing yet) with the joystick, and hitting the joystick button magically transports you to the winning state. (According to most Atari 2600 manuals, any transition to other screens is magical transportation.) The checkerboard pattern at the bottom is just to make sure that my asymmetric playfield kernel timing isn't off. Robot will find kitten on the VCS yet!

21:19 21/04/2003 I moved my developer diary over to Videobrewery.com, which is where I had intended to host it in the first place. I resisted the urge to take out the parts that revealed my ignorance of accepted advanced techniques of VCS programming (which is pretty much the whole thing up to this point). I have a nasty habit of liking to start from first principles, which really doesn't work very well with writing your first game for the VCS; especially if you have a set concept, and aren't creating your game based on the perceived limitations of the hardware. Anyway, nothing new code-wise, though that may come soon if I keep procrastinating from studying for my two finals tomorrow =]

20:27 21/04/2003 April 13, 2003 Brought myself to touch the rfk code for the first time since getting the end screen to work properly. I really need to get over my hangup of modifying working code if I'm going to get anywhere with 2600 programming. I stole some code from the Stella list archives to move sprites to a particular X position, given that position in a variable. This is something I was dreading, so I'm glad that it's a solved problem. Took out my horribly fiddly hardcoded "waste n cycles then hmove 3 over" code for positioning robot and kitten that took aeons to tweak properly and replaced it with the new routine, and it worked great. Wish I'd known earlier. I have like five projects at any given point (see my horrible neglect of the QNX Dreamcast Project) but I'm commiting myself to finishing all of them before I start new ones. Hopefully this means more VCS progress in the near future. We shall see. So, with horizontal positioning out of the way, the text engine being appropriated from Stellar Track, the only hairy code to write now is the random playfield generator, which assigns NKI numbers to playfield blobs, and the collision detection, which decides which NKI you've touched and swaps out to the text state. The kernel will be laughably simple; one sprite and a simple asymmetric playfield. My current idea is packing NKI information into the playfield data (which takes up ungodly amounts of RAM, but is really the only sensible way to do it) on the 2 unused nibbles of the asymmetric playfield line. I think. It's been awhile since I came up with the idea. Anyway, this is mostly just here to let people know that I do still intend on actually doing this.

20:27 21/04/2003 February 5, 2003 An email I just sent off to Paul Slocum, experienced 2600 developer at large: --- Hey there! > I noticed you're porting rfk to the 2600. Have you looked at the Stellar > Track text engine to display the text you need? It can be set up to > display 12 characters per line and up to 14 lines of text. I've used this > text engine quite a bit. It flickers but is interlaced so it doesn't look > too bad and doesn't use much RAM. Dark Mage uses the Stellar Track text > code and has it commented, source available here: I have looked at the Stellar Track engine, actually, though I looked at the Synthcart's use of it, rather than Dark Mage... That's just what comes up on google when you search for the Stellar Track text engine =] Now that I look at Dark Mage, I see the 22 bytes of "textPointer" buffer in the Synthcart isn't part of the Stellar Track text engine at all, which makes it low enough RAM to fit. (I've got like 90-some bytes earmarked for my main kernel, since the position and text of all 20 NKIs are random.) Good thing too, 'cause the text engine that I was dreaming up was starting to look pretty disappointing in terms of ROM use, as well as prettiness. (3-bit playfield text! Oi!) Of course, the player-based text kernel would mean I have to do absolute sprite positioning every frame, but we'll see how ambitious I have to be with it... could always just put robot in the middle and do a bunch of HMOVEs during VBLANK if there's not much going on =] Thanks for your suggestion! I should've known to look at Dark Mage.. --- So that's where we're at now. Stellar Track, here I come!

20:22 21/04/2003 January 29, 2003 So, it seems that "low-RAM text kernel" is, in the VCS world, something of an oxymoron. Basically, to do text on an Atari 2600, one must pre-process the string into a RAM buffer. This generally not only takes a significant amount of RAM (like 60 bytes per line of text!), it also takes a significant amount of time to do, limiting you to a maximum of, say, six to eleven lines of text. (The "eleven lines of text" kernel is perilously tricky for a beginner like myself to venture into.) A realization hit me yesterday, though -- storing a string as one-byte-per-letter is entirely inappropriate for the VCS' graphics hardware. Round hole, meet square peg. What such engines are asking the Atari to do is nothing short of decompressing data while in the middle of drawing the screen. Well, I rationalized, if I'm going to decompress data, I should at least compress it in its native format. I am currently toying with writing a C program to basically generate playfield data from a list of NKIs, and then "compressing" it into a format which is easily renderable with 2600 hardware. I don't store ROM for any letter combinations that I don't use, and I can re-use the ones I do. We'll see how well it compresses, but I'm fairly confident that text will be compact enough to use. The kernel will sure be cleaner than any text kernel I've seen, though. If you want to see the ending screen as it stands, you can download the ROM.

20:21 21/04/2003 January 27, 2003 Yes, you heard right -- robotfindskitten for the Atari 2600 is in progress. Here's a screenshot of what I have so far. It's only the kernel for the ending screen, but it's complete. It was basically my introduction to the VCS. I have the main gameplay kernel planned out, and am shopping around for a relatively low-RAM text kernel to use to show NKI text. I will update this with a little more detail as I do more work for it. Spoon?