Added blank and filled Spinda sprites (groundwork for procedural Spinda spots)

[rawr51919]

Ported from https://github.com/msikma/pokesprite/issues/26. Original sprites found/made by @5310.

[route1rodent]

Thanks for the PR but I am not in favor of this, reasons here: https://github.com/msikma/pokesprite/issues/26#issuecomment-590512235

If you are interested in procedural Spinda, here is some work already done: https://codepen.io/5310/pen/vmXONE?editors=0010

I'd vote for closing this issue, unfortunately.

[route1rodent]

I guess it doesn't hurt to have this as templates for the procedural code (code that I wouldn't maintain in pokesprite IMHO). The only thing I see it's missing are the shiny ones and probably an update of the json data file If I am not wrong @msikma

[rawr51919]

The procedural code should live in it's own repo, I agree there. But that's for @5310 to decide

[5310]

Whether or not scripts to generated procedural spinda find a place in this repo is definitely something @msikma et al get to decide. Most of the old (and rarely used:) scripts have been removed in the recent refactor after all. Such a script could always exist in its own repository and have this one as a submodule, perhaps.

However, I would like to think that the blank and filled bases should have a place in this repo, along with masks for the four spots.

More to the point, that old Codepen is very much a made-up algorithm. I sort of assumed that the box-sprites were too small to actually represent the real variety of patterns, so maybe we could cheat some fake variety and get away with it.

Later I did take a look at the algorithm the community believes to be correct, and realized it wasn't that difficult to emulate for even pre-LGPE/SWSH-era box-sprites, and especially now, even if a smaller number of the patterns would be visually distinguishable. I still couldn't find a really conclusive write-up of it anywhere except for the thundaga SpindaPainter implementation, so I didn't continue.

It's just four static masks randomly rearranged within four bounding boxes. And for each game, these spots are—apparently—hard-coded (although only for the battle-sprites and later textures and not box-sprites:) Even if we don't have the generation code in here, they should be assets, however unusual, considered for inclusion.

[msikma]

Sorry for not having looked at this yet. I think it would be good to include the empty/full sprites for Spinda in this repo. I'll need to update the pokemon.json data file to add it too, and add the shiny sprites.

Regarding the code to implement the mask, I too think that's best off being in another repo, but if someone implements this we could link to it from the readme file.

[rawr51919]

That would be great. This means that we could have the Spinda spots RNGed like in the real games. Another huge feature I'd be welcoming to pokesprite (even if it requires an additional script to use).

[msikma]

I've just pushed some changes - Spinda sprites for each of the three versions (gen 7, 7x and 8), plus shiny, and changes to the data file. I did a very small change to the sprite you made, but if you prefer I can undo that.

[rawr51919]

@msikma, it looks good to me. @5310, do you approve?

[msikma]

I've made a little proof of concept to test this: https://msikma.github.io/spinda-spots/

This is similar to the Thundaga Spinda Painter, except that it uses an SVG mask to draw the spots instead of using canvas. I'm not 100% sure yet if it's completely accurate but it looks OK.

You can use the Thundaga link to get a personality value to test. The default is 88889898 which centers the spots on Spinda's ears and eyes. A value that mimics the generic box sprite is 6A475844. Might want to zoom in using your browser to see more clearly.

[PoshoDev]

@msikma This is perfect for reasons I can't say right now. Is there way to fetch the painted sprite from an URL with a given HEX parameter?

[rawr51919]

@msikma This is perfect for reasons I can't say right now. Is there way to fetch the painted sprite from an URL with a given HEX parameter?

With the parameter being exactly what hex address corresponds to the spot pattern you'd like to display? Might be a way to get this implemented without the need for another script.

[msikma]

Unfortunately that won't work with this specific test, this just masks the filled sprite on top of the blank one. But I agree that would be a nice way to implement this. I just know I'm not going to host that because then I'll need to do it forever. 😅

edit: oh wait, do you mean to ask if it's possible to preset something other than the default value using a get parameter? I should add that yeah.

Anyone who's interested could recreate this in such a way that it outputs actual PNG data. See the getCoords() function especially (combined with the offsetCoords() function which makes the coordinates work with the smaller box sprite). Then you could just load an image like https://example.com/spinda.png?hex=88889898.

Pre-generating the sprites is impossible of course. Seems with the current implementation there are 1234800 possible sprites (since the sprite is quite small, the number is a lot lower than the theoretical 4 billion possibilities as a lot of them look identical).

[msikma]

You can now link directly to sprites in the test.

[PoshoDev]

That was fast, m'dude. 👍

[route1rodent]

LGTM 👍

[5310]

:trophy: :ok_hand: :100:

Emojispam aside, I'd like to try making a generator that creates flat PNGs from Personality values and, especially, tries to adjust for some of the perspective differences between the regular Advanced-era battle-sprites and box-sprites. Even if it can't ever be a perfect fit, maybe a bit of shearing could help. @msikma did pretty much all the work anyway!

...But I'm out of town for a little weekend trip (and COVID-19 party, apparently :mask:) so it might still take a while :relaxed:

[msikma]

Emojispam aside, I'd like to try making a generator that creates flat PNGs from Personality values and, especially, tries to adjust for some of the perspective differences between the regular Advanced-era battle-sprites and box-sprites. Even if it can't ever be a perfect fit, maybe a bit of shearing could help. @msikma did pretty much all the work anyway!

Awesome. Yeah, as you can tell it's not 100% accurate, but then fortunately since the box sprite is so small there's more room for error anyway. There's also the fact that the battle sprite Spinda looks into a slightly different direction.

But in any case it seems this is enough to support a future implementation. So I'm merging this and then if you or anyone else happens to make an implementation we can link to it from the readme.