alttpj / memeforcehunt Goto Github PK

Currently, the whole compressed spritemaps are being saved and shipped.

This has a few disadvantages:

• Other sprites, like the AG arrows, are being overwritten
• Waste of code
• Hard to export by other tools
• No palette information
• Not easy to render

There will be a little "memehunt-native" format, which is easy-to-read, easy-to-implement, and easy-to-use. However, zspr is already well-known and. Users should therefore be able to import and export from/to zspr. A few advantages:

• Well-known format
• Can be adapted without too many hazle to only store 4 tiles
• Allows recompression of existing sprites in the same tile, i.e. no existing sprites are overwritten
• Easier to render than just the .bin files, because it includes a palette number.
• Helps the roll-your-oown in the same release.

… instead of fixed.

• set min width of right buttons
• set min width of skin buttons
• set preferred size of stage.

• missing preview link standing in front of a chest
• save/load to/from yaml and zspr
• maybe add a background layer of arbitrary PNGs/JPGs, so users have it easier to draw?
• swapping colours
• make sure progress is not lost when app exists
• load pre-rolled sprites

The updated addresses are:
public static final int OFFSET = 0x18A800;
public static final int PAL_LOC = 0x104FE4;
public static final int PAL_OW = 0x10126E;

Maybe run on travis?

Use https://github.com/openjfx/javafx-maven-plugin

For each os in linux, win, macOS, do:
javafx:jlink

then package and upload to maven releases or similar.

When the repository question is solved, create an upload button, so users can share their sprite!

remove redundant code etc.

yes, the randomizer is skipping 0x800 byte before the next gfx

blocked by #14

In preparation for including the rest of the sprites that aren't there yet, let's get the metadata ready. If the metadata is there, but the sprite file isn't there yet, ignore it. The id tag should be sufficient with figuring out whether or not the thing is there or not.

Port to JavaFX

Create a web app consisting of:

1. a REST API
2. a frontend

• Query IDs and names by page
• Search functionality
• Browse with async loading of sprites.

publish API so other tools can adapt this.

Needs: https://github.com/alttpj/alttpj-library

blocked by #14

• add sprites from [ ] https://github.com/Artheau/MemeforceHunt/tree/master/src/main/resources

Simple changes, i.e. new grids and maybe some XML layouts and classes.

Instead of saving just the binary dump and the palette and description extra, I'd like to create a more specific format.

For easiness of use, that would be yaml with the following fields:

• ULID
• Sprite name (max 12 chars, only alphanumeric)
• Display Name - should reflect the sprite name, but with spaces and more characters.
  • E.g. if the sprite name is "B", the display name would be "[B]".
• Sprite author
• Description (optional)
• Creation date (optional)
• Base 64 encoded data, 4 uncompressed, packed tiles in one string or as 4 uncompressed, packed tiles separately
  • if it was 4 tiles in a single byte stream, that would be 90 uncompressed bytes
  • 90 raw bytes are 120 bytes in base64
• Base64 encoded png preview (optional, because it can be generated from the data).
• Colour palette name
• Tags[] (for search)

For later: Also supported gzipped extensions if it makes a difference.
This will also help creating an online repository or exchanging sprites.

Sprite name should be removed. The former idea was that it should reflect the filename.

TODO:

• Retain tags
• retain ULID

open the file and add a new field "description" for each sprite/skin.
https://github.com/alttpj/MemeforceHunt/blob/master/common/sprites/src/main/resources/sprites/sprites.yaml

The actual implementation.

Things which need to be included:

• 16x16px sprite editor
• previews (just the icon and link standing in front of such a chest)
• save/load to/from yaml and zspr
• transparent bg (small boxes white/gray)
• maybe add a background layer of arbitrary PNGs/JPGs, so users have it easier to draw?
• palette swapping (transform existing coloured pixels to another of the three palettes)
• swapping colours
• make sure progress is not lost when app exists
• make sure progress is not lost when switching tabs
• load pre-rolled sprites

Things to think about:

• Maybe a github repository? But users would need a github account and to know how to create PRs.
• ... other solutions?

What must be included when submitting:
One file named <spritename>.yaml which contains all the mandatory fields of #23.

• ini configuration in $HOME/.config/memeforcehunt/config.yaml
• Accept --offset=0xCAFEBABE as an override for the CLI when using the set command
• add GUI elements to restore the original and to update the config.yaml

Directories:

• Windows: %LocalAppData%/memeforcehunt or %AppData%/memeforcehunt (whichever comes first)
• Mac OS X: ~/Library/Preferences/io.github.alttpj.memeforcehunt
• Linux: ${XDG_CONFIG_HOME}/memeforcehunt or ${HOME}/.config/memeforcehunt (whichever comes first).

sth like this:

{
  "sprites": [ 
    {
      "id": "ULID",
      "author": "author",
      "spriteName": "spriteName",
      "uri": "uri",
      "preview": "uri",
      "created": "createdTimeStamp"
    },
    {
      "id": "ULID",
      "author": "author",
      "spriteName": "spriteName",
      "uri": "uri",
      "preview": "uri",
      "created": "createdTimeStamp"
    }
  ]
}

This can be used in the default (shipped) sprites, an online repository or for adding new sprites, etc.

ULID: https://github.com/huxi/sulky/tree/master/sulky-ulid

• extract the 4 tiles we need
• compress those again (not clear: each tile on its own or all 4 of them at once?)
• add the compressed tiles and the preview as base64-encoded fields to the existing yaml

• mvnw
• travis config with at least 6 JDKs (3x 11, 3x 14)
• copyright

At the moment, we ship the complete spritemap (see README.md).
This will always replace silvers and other sprites to the old sprite (depending on when the spritemap was created).

Instead, it would be better to decompress both sprite maps, read only the four corresponding tiles from the shipped sprites, put them into the decompressed spritemap of the ROM and compress it back.

The alltpj library can handle compression.