Store piece sprites as vector graphics

[tsevasa]

Lichess stores all its piece sprites as vector graphics (see here, for example) and each piece is less than 1KB in file size. In contrast, our spritesheet is a png file and takes up 1MB in total.

We should also store piece sprites in svg format.

[Naviary2]

This would be great, and a huge performance boost!! As long as we can convert the vector graphics back into textures on startup!

[Naviary2]

All piece's have now been converted to an SVG! Next we can take steps towards using those svgs and re-forming the spritesheet on the client-side with them!

See discussion here
https://discord.com/channels/1114425729569017918/1261070585476288674

[Naviary2]

I imagine we would group all the classical pieces into one http request (as svgs are just text afterall, there has to be some way to split them into individual svgs eith javascript afterward), and other fairy pieces may or may not be in groups! Atleast, a pair of a black and white piece should atleast be merged into one request.

[Heinrich-XIAO]

I imagine we would group all the classical pieces into one http request (as svgs are just text afterall, there has to be some way to split them into individual svgs eith javascript afterward), and other fairy pieces may or may not be in groups! Atleast, a pair of a black and white piece should atleast be merged into one request.

We could combine them in one big JSON object or something.

[Heinrich-XIAO]

[Naviary2]

Is this the time it takes the request the spritesheet?

[Heinrich-XIAO]

Is this the time it takes the request the spritesheet?

Yeah. The 1MB file.

[Naviary2]

We don't even need to combine them all. If 95% of games are classical, we can just merge all the classical piece's svgs into one request, and only send the other fairy pieces when needed

[Naviary2]

All pieces have already been converted into SVG's and been compressed. All we need to do from here is:

• Write a method JavaScript method that will take a list of SVGs and create a spritesheet PNG from them (maybe could use inspiration from checkerboardgenerator.js?? Idk, ask ChatGPT how to do this)
  EDIT: Like this
• Merge all the classical piece SVGs into one API request.
• Create APIs for fetching all the other fairy pieces.

[Naviary2]

I'm going to start on this. I'm writing an outline of what I need to do:

1. Create a resource that contains all the classical piece svgs in one svg document. Done

2. Do the same, but one API/resource for each pair of white & black fairy pieces. Done

3. Load the classical piece svgs upon loading the play page. Done

4. Figure out how to use javascript to convert an svg into a texture. Done. Changes will be pushed to separate branch.

5. Write a script for converting any number of input svgs into a large spritesheet image of any dimensions. Done

6. Upon loading a new game. Fetch the required svgs, then use the above script to create a spritesheet for that game. Perhaps I need some sort of loading animation if there's a delay. Done

7. Cache the piece svgs in memory, so that when it loads new games it doesn't have to re-request the same svgs. Done. BUT, it's very messy and there's a lot of bugs. I'm adding the following:

8. Allow the client to cache svg resources like it caches other normal resources, like html pages (is this even possible for a fetch request?) I checked production and the client already automatically caches the spritesheet resource, and that's a fetch request, so I think it will automatically cache the piece svgs when they're fetch requests too 🤞

9. Clean up the entire code. Done

10. Fix the svgs that look off, not like themselves, or different, than their spritesheet counterparts. Re-convert their image into an svg, compress that, make sure there aren't any graphical glitches, make sure it looks identical to the spritesheet counterpart, than replace their svg in the public assets. Pieces that are different are: Chancellors, white amazon (nose too big), black amazon (mouth cavity filled), black royal centaur (top of hat should be solid black). Done

11. Hunt for and fix all newly introduced bugs. Done

12. Add a loading animation screen while the game is generating the spritesheet, with an error message if it fails.

[Naviary2]

The classical piece svgs take up just 9KB

[Heinrich-XIAO]

Why do we have to convert it into a PNG spritesheet? Isn't one of the main benefits of using SVGs (Scalable Vector Graphics) the scalability?

[Naviary2]

Why do we have to convert it into a PNG spritesheet? Isn't one of the main benefits of using SVGs (Scalable Vector Graphics) the scalability?

WebGL can't directly render vector graphics. BUT, we can create a texture of any resolution out of an svg. I've programmed the spritesheet generator to aim to make the spritesheet large enough so that each image is atleast 512 pixels. That is more than enough for crisp clarity at all zoom levels. The spritesheet size won't exceed the maximum size supported by your device, but that number is VERY big for most devices.

[Naviary2]

The current spritesheet size has all the pieces at a width of 256 pixels, and there's a little bit of fuzziness when zooming in. But doubling this looks great!

[Naviary2]

#374 Added the majority of these features. All that remains now is to add an error message to the loading animation if by chance the page fails to load the svgs for a loaded game.

[Naviary2]

Okay an error message now shows if one of the fetch requests fail during spritesheet generation. However there isn't a retry button or automatic-refreshal, it just asks you to refresh. If you try to leave the game while the error message is up it totally breaks it.