hey yall, so i was trying to install sromcrom on my ubuntu laptop and when i type the npm installation script. it gives me a error, the error says: "Error: EACCES: permission denied, mkdir '/usr/lib/node_modules/@city41/sromcrom/node_modules/canvas/.node-gyp'
idk what this means so can you help me out with the error.

Originally I thought the two far right tiles in the main eyecatcher logo were empty. But they aren't. In a normal eyecatcher they contain bits of the final 'O'

Currently sromcrom expects a logo image that is 14x4 tiles. Instead it should accept a 15x4 tile sized image, and not emit the upper right or lower right corners into the CROM. If those corners are not empty, emit a warning. Those corners are not part of the eyecatcher CROM tiles, as shown in this image from the wiki

Tilesets need to support auto animation. This will be very similar to how cromImages support it, but each individual tile is examined to see if it needs it.

A tileset specifies it wants auto animation with the autoAnimation?: 4 | 8 key. If this key is present, then the provided png is divided into 4 or 8 frames, depending on the value. When generating the tile sources for this tileset, need to examine frames 1-n for each tile. If all the frames are empty (alpha=0), then this particular tile does not have auto animation. If any tile is not empty, then slurp them up as child frames for this source. From there the existing auto animation system will take over.

During tileset code emit, need to also emit the autoAnimation flag, but I think that will already happen.

I had copyrightCharacter as a key to eyecatcher in resources.json, but it should be copyrightCharacterImageFile. Despite this, sromcrom never complained, and failed to add the copyright character to the rom.

Detect unexpected keys and error out.

Just like cromAnimations, but for srom tiles.

Now that my game finally has a large animation, sromcrom is pretty slow, it takes about 30 seconds to process all my game's images, now that the title screen animation is in place

probably not worth investigating, but will keep an eye on this as my game grows.

EJS is just brutal, oh my god. Switch to something else, ie Handlebars, Pug, etc.

Hey, So anyways i just installed the sromcrom program to convert png to graphics roms for the Neo-Geo AES. but then i got the issue when i tried to type make srom on the terminal it gave me a error. The Error Says: make: *** [Makefile:37: srom] Error 127 idk what to do for this problem!

Hello, so anyways I want to install the sromcrom program using npm but when I try to type the install command in the terminal it gives me a npm install error! So here is the question how do I fix the error message?

Enable generating alternate palettes for a given set of tiles. The user could render the set of tiles to a sprite using the alternate palette for things like player 2 palette swaps, stuff like that.

the approach

Each input should have an alternatePaletteImageFiles: string[] key. When a generator first creates the tile with the canvas source, if it sees this key, that tile will also have alternatePaletteSources: Canvas[] set.

"cromAnimations": {
  "inputs": [
    {
        "name": "player",
        "animations": [
            {
              "name": "spawn",
              "imageFile": "./player1_spawn.png",
              "alternatePaletteImageFiles": ["./player2_spawn.png"]
            }
         ]
    }
]

Immediately after main palette generation is done, these alternate palette sources are consulted, using the main generated palettes, to generate the alternate palettes. For each tile, the tile's main Canvas source, the palette it got assigned and the alternate palette sources are cross referenced to generate the alternate palette.

During palette code emit, more metadata about palettes is needed. Currently just the palette data is provided, but also need to specify whether the palette is an alternate, and if so, which tiles it is an alternate for.

eyecatcher tiles get deduped just like any other. But the eyecatcher isn't expecting this, so deduped tiles end up blank/garbage.

The eyecatcher needs the tile at 0xff to be blank. This is done by adding cromFFBlankGenerator to the generators in cromOrchestrate. Which is fine and correct.

But later on in CROM positioning, Math.max is used to find the last already positioned tile, and then the rest of the tiles are dumped from there. That causes these tiles to get dumped at 256 on, and leaves a big gap in the CROM

Currently sromcrom doesn't care if a tile has too many colors. It will keep trucking and ultimately emit palettes that are too large and bad crom data.

The old version used to throw an error then dump the bad tiles to pngs for inspection. Bring this back.

Rather eyecatcher images should require specific colors that match the system palettes

Today the json input format is simply defined as Record<string, unknown>. Statically typing it would help a lot. Also validate the input json meets the type at runtime.

Since tilesets are mostly used to create level graphics, they should support multiple imageFiles per input. This will allow things like parallax backgrounds.

Wherever a png can be used, an aseprite file should be usable too.

• sromImages: the aseprite is just converted into a static png and proceeds as normal
• tilesets: the aseprite's frames are used for auto animation (#2 needs to be implemented first)
• cromImages: the aseprite's frames are used for auto animation. If the given cromImage does not want auto animation, then the aseprite is treated as a static png
• cromAnimations: the aseprite's frames are use for frame animation

Probably the easiest thing to do is convert the aseprite into a corresponding png in a system tmp directory, then just proceed as if a png was provided.

Tilesets do autoAnimations better. They only set tiles to autoAnimate that need it, instead of the entire tileset. cromImages set the entire image to auto animate.

Have cromImages work like tilesets here, which was implemented here: 57501f0