robotfindskitten (VWF version)

After reading about Scoth42's implementation of the Zen simulator robotfindskitten, I whipped up my own in a few days. But to avoid stealing his thunder, I delayed releasing it. I have decided that now is the time. Here it is, including 2-player support using a variable-width font all packed in a 4K engine. With this and byte pair encoding, an NROM-256 should be able to hold a large variety of NKIs.


Screenshot

Questions? Comments? NKIs you don't understand? Additional NKI suggestions?

Nice work! I like the quotes

What keeps the number of on-screen NKIs limited to ≤ 31? How hard would it be to increase the number of on-screen NKIs further? (Maybe add a compile-time error if it's too big?)

I encountered an invisible NKI in a build with NUM_ITEMS=31 ... Don't know if I tickled that by increasing NUM_ITEMS or if its something more... (If it helps I have an FCEUX save state for it)

Because I made them sprites to allow more colors in a small place. More than that would probably introduce sprite dropout by potentially putting more than eight on a line. So the RAM and VRAM layout does not anticipate more.


I would have to cut colors by using background NKIs.


Were there more than 8 things on one line in that run?

Nope, it was the only item on that line.

I figured out why NKIs after the first 15 would be invisible, and it has to do with how the robot and heart symbols are loaded. This would need me to redesign the VRAM allocation. For this, how high should one expect to push the NKI count?

I dunno, 24? 31? Is there a quantity between 16 and 31 at which the amount of effort increases?

I figured out what's causing items 16+ to be invisible and 32 to crash it. The line buffer used by the VWF code is 128 bytes (16 tiles) long, at $0100-$017F. Data written past $0180 never gets copied to VRAM, and data written past $01F8 overlaps return addresses. I changed load_item_shapes in bg.s to copy glyphs to VRAM after each line of 16, and it handled 27 NKIs with no sweat. Moving item_typehi and item_shape from zero page to BSS let me push 47.

here's some I came up with. Also would you accept a image of a robot in the place where "titleguy" used to be?

Thanks for the NKIs. One was too long:


Yep, you got me: the title screen code is cribbed from RHDE's help screens. I need to explore possibilities for what robot might look like: probably based on one of those 1-wheel robot designs. But adding robot would cause the engine to exceed 4096 bytes, something I had been trying to avoid.

Our of curiosity, why not include some NKIs from upstream?

A lot of items in default.nki are based on vanilla.nki, with a twist that ties them to the NES homebrew scene, to other popular culture, to my fetishes, or even just to a thread of plausibility. Each item is sort of a riddle, letting you play on two levels: finding kitten or figuring out what each NKI means. (If someone doesn't get one of these, I can explain if you find me in #nesdev.) Perhaps it's my way of opening up to the world. Here are hints:

• There are lines taken from vanilla.nki but with allusions to other things added, like panda dogs, Xenu.net, cannabis, brain-computer interface, Futurama, South Park, The Care Bears Movie, Animal Crossing, Who Moved My Cheese?, Portal, Super NeSnake 2, Pokémon, Lagrange Point, Cookie Clicker, Blue's Clues, The Time Machine, and most of the games on the first two volumes of Action 53.
• Instead of "It's Mary Poppins!" I have an artifact she might have left behind, which doubles as a Wii Play Motion allusion.
• To "A flask of hydrochloric acid is here" I add what the HCl might be used for.
• Instead of "It's a cat. Are you too late?" I have other animals whose young are called "kittens".
• To "It's a Linux install CD" I add allusions to a couple distros.
• Plenty of stuff derived from the world-building in the wiki on my web site.
• Even the description for the other robot hints at why robot seeks kitten.

Would anything stop you from placing NKIs using both background tiles and sprites? It seems like that could broaden available colors as well.

I see a few challenges:

• I'm already using 128 tiles for the status. I might have to use sprite 0 to change to the other pattern table for background items.
• I'd have to compensate for the misalignment between the 8-pixel-tall lines of the NES tile grid and the 7-pixel-tall game grid.
• Adding a routine to draw the first few NKIs to the background would put it over 4K.
• Going too far beyond 48 items might exceed the 2048-byte RAM budget. Currently I use 1024 bytes of RAM to shuffle up to 512 NKI text pointers, 384 bytes for transfer buffers (128 for VWF and 256 for OAM), 80 bytes for a text decompression buffer, 16 bytes for local variable space, and let's say a couple dozen bytes for miscellaneous game state variables. Each item takes 6 bytes for location, identity, and appearance.

I personally think 48 items is enough per level. The engine you have now is already quite good.

As for the 4k limit for the engine, I think it's not too far-fetched to consider the intro text as not part of the engine and compress it as non game NKIs.
Also if the master text pointer array grows too big or is too much in the way, there's the ram in the other unused nametable. I think it's only used to generate a new level during a screen blank, so it should work?

I just read the source code. Pretty clever, your bcd8bit. The VWF code is also surprisingly short. The mbyt macro is interesting, too. Would recommend using "@labels" rather than "labels"in macros, so that local labels in invoking code will not be impended from working across the macro invocation.

Now on GitHub, in part to clarify the choice of NKIs and in part so that I can reuse its DTE decoder in another NES project that might hit size constraints

As with Thwaite, I'm on an effort to make sure all my major projects on GitHub have at least one tag (that is, one release). I've released v0.10, which contains mostly behind-the-scenes improvements.

• Update for recent coding standards (.inc not .h, Python 3, recent ca65, etc.)
• Update DTE compression and VWF drawing from 240p Test Suite
• Add instructions to README
• Add provenance of most NKIs in comments
• No more zip bombing

See the release on GitHub or grab a snapshot below