nesdev.com

All code in my implementation of robotfindskitten is original, a clean room implementation of the functionality described in the RFK RFC (PDF). I do plan to include it in the source pack, as a source pack promotes what I see as the goal of Action 53, which is to encourage creation of a substantial* library of freeware for NES.


* Substantial in the Sony v. Universal sense.

_________________
Pin Eight | Twitter | GitHub | Patreon

So this is actually the first time I get to see my work printed out, looks nice.

The font issue for the box was completely my fault but it looks OK anyway.
I did use a weird non-standard process (I "traced holes" even then) to make those in the first place so I should of expected bugs, but what was used to print the label that was different then the box? Because for some reason the line width for the blaster guys was printed thin. It's obviously too late to fix, but I would like to know the program pipeline so that I can avoid such issues in the future.

Edit: Looking into it, whatever program rendered the label SVG renders stroke-width=".75" as 3/4 of a millimeter rather then 3/4 of the current transform unit. It renders correctly when the width has a leading 0 like stroke-width="0.75".

Okay well I'm going to go ahead and announce the release. Feel free to point out any corrections that need made, but the only potential significant danger I was concerned about was if there were complaints on pricing. But the past 6 months has given more than enough time for comments as I went with my proposed pricing from my Feb post.



Okay well either way, I consider you the resident expert when it comes to license requirements. Let me know the conclusion here and I'll adjust the webpage accordingly.


Yes, sorry I copied that from my scratch notes, nothing official coming from there anyway.


Yeah they turned out pretty good. Honestly I don't get all the complex file types, I asked the print shop if they had a preferred format and they said whatever I've sent thus far worked fine. I've never dealt with svg. I do recall them having issues with the label for some reason and I quick found a means to convert it to bmp. But looking at the files I sent, I'm pretty sure they converted from .svg themselves as my files don't have the thin lines. Future recommendation I would say use a format that isn't subject to interpretation .png or .bmp is prob best.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

I do not recommend SVG either, unless that is the format worked as the source file and you are making the source distribution. PNG is better. But for printed out files you might want CMYK or spot colors (although there aren't any good free color matching systems for printing as far as I know)

_________________
.

For everyone who will be receiving a copy of this, I apologize for the printing mistakes of incorrect fonts, odd thin lines and pixelation. I'm at fault for not rendering out the 600dpi sRGB bitmaps myself. That would of avoided all the trouble.

Fortunately the manual printed out perfectly, because it was a PDF file.