Procedural Spinda

[5310]

Adding to the list of barely significant variations, I made a simple script to procedurally draw spots on spinda: https://codepen.io/5310/pen/vmXONE?editors=0010

It makes no sense to statically render spinda variations. But if the sprite-sheet generator tool can host this generator as an addon then these blank and "filled-in" sprites might become useful. They may also be useful even to a user who to generate their own spinda spots manually or in-engine, they can just generate the clipping spots and composite the blank and filled-in layers.

What do you think, too trivial? @⏝@

[GiacomoLaw]

Does it do this on site? If so, how would it affect loading times?

I do like the idea though 🙂

[5310]

It needs to load the two base images to generate any number of spotted variants, and the actual generation is takes an imperceptibly small amount of time. They're just tiny 40×30 images after all. After the spots are generated the resulting canvas can be exported to a file (on, say, Node) or used as an image (on the web) as is!

If we make a custom ellipse-drawing function for aliased spots the generation time may increase a bit, but it should still be very small.

[msikma]

I think the most sensible way to implement this would be to write some JS that generates the dots and masks them onto the icon properly. It can be done on the fly at essentially zero cost, just like you did - it would have to be part of the main JS code.

However that would really only make sense if the spots actually match the spots on the in-game model, which means you need to do some work to convert the data format into coordinates.

Also, the spots would have to look precisely like the spots on the original icon - no softening or anti-aliasing, that is.

[5310]

What's why I'm proposing at least the blank and filled-in variations of the spinda sprite be included in the repo, even if no code is.

At the moment the spots generated by that CodePen are fuzzy because I'm just using the Canvas API's path drawing functions, but I plan on making them solid soon.

I don't however think it's desirable or even feasible to make them match the in-game sprites. Not only because we don't know for sure what sort of mapping is used in game other than the number of possibilities cited, but we also can't possibly support the entire set of variations in the tiny confines of box-icons. As such, I think just the perceived variety of a couple of hundred spinda being different (and always having 1~4 possibly overlapping spots of varying sizes and no more, matching the games) is good enough to capture their nature without going overboard!

On Mon, Apr 24, 2017 at 3:37 PM Michiel Sikma notifications@github.com wrote:

I think the most sensible way to implement this would be to write some JS that generates the dots and masks them onto the icon properly. It can be done on the fly at essentially zero cost.

However that would really only make sense if the spots actually match the spots on the in-game model, which means you need to do some work to convert the data format into coordinates.

Also, the spots would have to look precisely like the spots on the original icon - no softening or anti-aliasing, that is.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/msikma/pokesprite/issues/26#issuecomment-296604141, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG5EreiWEGld__msK9RofoEQnULfElyks5rzHRogaJpZM4NFtjC .

[msikma]

Well, I don't really see the point otherwise. It would be kind of funny to try and emulate the same spot placement as in-game, which shouldn't be too difficult since the algorithms are available. Of course you'd get a lot of icons that look the same despite having a different spot configuration, because the icons are much smaller.

Anyway, I understand that this is quite a lot of work for a silly minor feature. But otherwise I just don't think it's worth it to include this and maintain it. Having Spinda icons show different spots, without them actually matching the in-game models, sounds like it's just confusing to me.

[5310]

Are these algorithms known? I didn't know that! Could you link me to one, I'd definitely be willing to implement it.

On Mon, Apr 24, 2017 at 4:33 PM Michiel Sikma notifications@github.com wrote:

Well, I don't really see the point otherwise. It would be kind of funny to try and emulate the same spot placement as in-game, which shouldn't be too difficult since the algorithms are available. Of course you'd get a lot of icons that look the same despite having a different spot configuration, because the icons are much smaller.

Anyway, I understand that this is quite a lot of work for a silly minor feature. But otherwise I just don't think it's worth it to include this and maintain it. Having Spinda icons show different spots, without them actually matching the in-game models, sounds like it's just confusing to me.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/msikma/pokesprite/issues/26#issuecomment-296620220, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG5Ep9dYbbdd1TZvgckcBGCMq5TYQzdks5rzIGQgaJpZM4NFtjC .

[msikma]

Well...I'm still not actually sure if it's really worth it because I very much doubt anyone would want to use this. 🙂

I'm pretty sure you can find it on Project Pokémon somewhere. Or ask there. It's been a while since I saw how it works but I'm pretty sure as of generation 5, there was a certain range of numbers in the data that corresponded directly to coordinates for the spots.

[rawr51919]

Any updates on this?

[rawr51919]

I for one am OK with this. EDIT: PR's up for this. Check PR #56

[route1rodent]

I don't think we would ever do something like that and I don't think we should basically because:

1. Spots wouldn't be noticeable in the mini sprites without zooming them in
2. There aren't even official sprites for the patterns (of course, because they are random)
3. A Spinda's spot pattern is determined by its personality value, meaning that there can be exactly 4,294,967,296 different variations of Spinda
4. Pokemon HOME is not doing that even though it has every absolute Pokemon form image. So if you bring a Spinda with a particular pattern is not shown, even though internally the data for that is kept.

I think @5310 codepen code is an excellent resource and anywone wanting to have this on their projects they should do it. but it's out of the scope of pokesprite IMHO

[rawr51919]

So you're saying that we should be better off either ripping the 4294967296 Spinda variations and randomly selecting from those, or keeping Spinda as it is.

[route1rodent]

I only meant that having that procedural code and maintaining it is not in the scope of this project and without it there is no possible way to have all variations as static images.

[msikma]

Here's a test for procedural Spinda sprites using the blank/filled sprites. This is just one example implementation for these sprites. The sprites themselves will be merged into the project.

[route1rodent]

LGTM 👍 👏 @msikma

[msikma]

This has now been merged.