nesdev.com

This release adds polish. (Not to be confused with adding a translation to język polski.)

Executive summary:

• The menu with no games added is less astonishing, using POLAK (Principle Of Least Astonishment Key) principles.
• make dist builds both the .zip of the menu and the .7z of volume 3, both full and PowerPak subsets

Detailed changes:

• Menu: Don't include iNES header in menu-only binary to discourage accidental execution (requested by rainwarrior and dustmop)
• Menu: Display error if key block is missing a screenshot (requested by dustmop)
• autosubmulti: Map from mirroring to map mode bit 0 was backward (reported by RogerBidon)
• a53build: Prints exception message for each ROM that failed to load (requested by JRoatch)
• a53build: Paths are explicitly relative to config file's directory (requested by JRoatch)
• a53build: Config file can change path of menu binary
• a53build: Screenshot converter shares NES palette with savtool
• a53build: Filename of config file no longer hardcoded
• makefile: make dist builds and packages both the menu source and one or more collections
• Workaround for Info-ZIP Zip's nonzero exit status when no changes are needed (per Stack Overflow)
• Docs: Mention new features related to Action 53 mapper

This refers to the 64x56 pixel thumbnails that represent each game in the menu.


Now that volume 3 is final, that time is now.

The first improvement I can think of is expanding each screenshot to ten colors: gray ramp as background plus a sprite overlay to provide non-gray colors. Each 8x8 pixel area of the screenshot would use one of two 7-color palettes:

1. Black, dark gray, light gray, white, A, B, C
2. Black, dark gray, light gray, white, D, E, F

With this change, I expect screenshot sizes before compression to increase from 64*56*2/8+3 = 899 bytes to 64*56*3/8+8*7/8+6=1357 bytes. Compressed sizes may vary with the planned switch from PB53 to Bagel.

Sorry if I missed it earlier, but why can't the screenshots be allowed to pick any of the four sprite palettes per 8x8 region, in addition to the greyscale ramp behind the sprites? Other than the arrow, what are the other sprites up to?

I had planned on limiting sprite palettes per screenshot to two in order to leave room for future expansion should I revamp the menu to add sprites in other places.

How to write a config file entry for an activity

These fields define an activity's appearance in the menu:


Entries to a competition MUST give title, author, year, and description. The font is variable-width, and with most glyphs in lowercase text being 3 to 5 pixels wide, it allows about 28 characters per 128-pixel line.

• title=
  The game's title as it shall appear in the menu. (1 line)
• author=
  The name of the game's author or publisher, as it would appear in a copyright notice. (3/4 of a line)
• year=
  Year in which this version was first published. (4 digits, 1970 to 2099)
• players=
  Number of players for the game. If not specified, the menu builder uses 1. Valid values are as follows; if your game does not match these, I can add one. The "alt" means "alternating".
  1, 1-2, 1-2 alt, 1-3, 1-4, 2, 2-4, 2-4 alt, 2-6 alt
• description:
  Up to 16 lines of text. It should describe the game's premise, the control scheme on the standard controller, any other specialized controllers (such as the Zapper or Power Pad) that this activity uses, and (if you have room) some game tips.
  
  The colon instead of equal sign after description means that a multi-line value follows, where a . (period) on its own line terminates the value. (The convention used is the same as that of SMTP.)

Screenshots and patching information can be provided later, as I imagine that some games will get substantial graphical overhauls before release. Rock Paper Scissors... from the third compo did, and I expect Wolfling Zero from the fourth to as well. So here's what the full config for Twin Dragons looks like:


Most of the new fields are quite technical:

• page=
  Each activity appears on a page, whose name is displayed in a tab at the top of the menu screen. This is the only field that comes before the title.
• screenshot=
  Relative path to a 64x56-pixel PNG image with black and three other colors, representing the reduced by a factor of four in each direction. The color capability may be expanded if I get time.
• rom=
  Relative path to the ROM file. Activities using the same ROM file may have different entry points.
• prgunused0=, prgunused1=
  Comma-separated list of address ranges in each 32K bank of ROM on whose data the program does not depend. These are hexadecimal and inclusive; FFF0-FFF9 means ten bytes.
• patch1=
  Entries using the Action 53 mapper directly for runtime changes to nametable mirroring will need the write to register $81 (outer bank number) edited out of its init code. It's traditional to change a STA $8000 to a BIT $8000. I have also used this to fix NROM and CNROM games that inadvertently overwrite the CHR data that the menu loads into CHR RAM.
• entrypoint=, chrbank=, prgbank=, and mapmode=
  These are most often used when multiple NROM-128 entries are packed into one 32K PRG ROM bank. But if you have a separate activity within your ROM that you want to make accessible from the title screen, specify it as a separate activity with the same rom= and a different entrypoint=.
• exitmethod=, exitpoint=
  By default, the ROM builder patches the reset vector and an unused area of each ROM to return to the menu when Reset is pressed. Add exitmethod=none if your ROM wants to trap the Reset button for itself, with a menu option to switch in the last bank and JMP ($FFFC), or add exitpoint=FFF0 if your ROM already has the approved exit code at that address. If no exit method is specified, the entry MUST have enough prgunused to fit the exit code.

Any chance we could get custom characters added to the character set?

The game we plan to submit has a ż (lowercase z with a dot over it) in the title and our author name has an Ł in it (capital L with a slash through it).

_________________
www.mteegfx.com

Oops, ya got me.

I'll see what I can do for Unicode support. Would it be acceptable to support only "simple" characters, those that can be drawn left to right without having to contextual choices or align two horizontally overlapping glyphs relative to each other, such as precomposed characters in Latin and emoji?

If that's fine, we need to design glyphs. ł (lowercase l with slash) appears visually distinct from t. Are these glyphs for Łł Tt Żż OK?

In case there is space issues prohibiting the use of ż and Ł,

these letters have the lowest relative frequency in english (although game titles may not reflect typical use):


Chances are some of them won't be used.

Reserving two sprites and a palette to be identical is another makeshift option. Making the . character centered so it can be placed above z is another.


As for designing glyphs, the diagonal bar of Ł / ł should start lower than that of t. Preserving the dot over upper case Ż is also important (though it won't be used in this specific situation).

_________________
http://www.frankengraphics.com - personal NES blog

The article you linked states that barred Z is acceptable for uppercase, which is important with as little leading as I have to work with. I'll move the slash on the L down a pixel.

There are other ASCII characters more likely to be unused than Latin letters, such as the backslash. But the same font is also used for game descriptions. So I do plan on expanding it as needed.

But while I'm adding support for UTF-8 titles in the builder, I might as well put in other improvements (Zapper responsiveness and screenshot color depth). Screenshots in particular would require 56 tiles of background space, and I don't have that in the first pattern table of the current VRAM layout. I'm also already using sprite 0 to time Zapper reading.

$0000-$019F Borders (26 tiles)
$01A0-$047F Unused (46 tiles)
$0480-$045F Tab titles (24 tiles)
$0600-$0FFF Text area (160 tiles; 320 with palette hackery)
$1000-$137F Screenshot (56 tiles)
$1380-$139F Tab arrow (2 tiles)
$13A0-$13FF Unused (198 tiles)

So I'd have to move the tab strip to the second pattern table, producing a map more like this:

$0000-$015F Borders excluding top (22 tiles)
$0160-$027F Unused (18 tiles)
$0280-$05FF Screenshot gray plane (56 tiles)
$0600-$0FFF Text area (160 tiles)
$1000-$17FF Top borders (8 tiles)
$1080-$11FF Tab titles (24 tiles)
$1200-$157F Screenshot colored plane (56 tiles)
$1580-$1FFF Unused (168 tiles)

This produces a new burn-down list:

1. Move controller detection before title screen, relying on Reset press rather than hot plugging
2. If Zapper is connected, poll Zapper during 25% of frames even if display is updating
3. If Zapper is connected, shooting offscreen should change pages
4. Split Zapper polling loop into two: one for top 24 pixels and one for rest of screen
5. Rescale returned Zapper coordinates on PAL NES
6. Split border graphics into two files
7. Move top border and tab titles to second pattern table
8. Make a converter for 10-color screenshots
9. Display 10-color screenshots
10. Extend VWF routine glyph address calculation from 128 to 224 glyphs
11. Associate codepoints for additional glyphs
12. Add capital L with stroke, small z with dot, and arrows

I recognize the problem with diacritics above capital letters. But at the same time, the statement referred to in the quote above would assume the bar is legible via fine detailing of the die, vector file or high resolution raster. At a low resolution like this, it is hard or sometimes impossible to make it come across as a barred Z, let alone the pretty much standardized Ż. Even though i'm only half-polish from an expat parent, i dare say it is uncommon to see a barred z in polish print, historic or recent.

The usual ASCII text mode solution to capital letters + diactrics is lowering the height to make room for the diacritic, but still have it higher than the lower case ones. Going outside standard ascii, special symbols for diactrics on the row above looks a bit better whenever it is viable and can cover the needs of several languanges in less space.

_________________
http://www.frankengraphics.com - personal NES blog

Thank you both. Ten color screenshots sound sweet too.

_________________
www.mteegfx.com

I'm about halfway down the list. What custom characters do you see already?

Love the arrows and buttons. Should they also have colons after them?

_________________
www.mteegfx.com

I had been using a colon only after a letter, not a symbol. You see this in the first three volumes, where + is a symbol for "Control Pad".

So anyway, I managed to get layered screenshots implemented in the builder and menu. Later, I plan to post a Python demo program so people can practice drawing layered screenshots.

Looks great.

_________________
www.mteegfx.com