World map compression and encoding

[naknode]

Currently, the world map is using arrays. Egads, right?

For even a 200x200 map, that's still a lot of data that can be compressed and encoded and a lot of bytes to save! Ideally, we can do

• Gzip compression
• Base64 encoded

And 200x200, or whichever, can be called upon as a nice, compressed string which would be decode and uncompressed. The map editor I am using is Tiled to do the encoding and compression.

There are tons of gzip and base64 libraries on NPM that we can use to get started.

---

No rush, as I don't see the need for the map to go over 100x100, yet... but there will come a time where this must be done.

[naknode]

Compression and saving bytes is good. This has been moved up to high due to the performance it will bring once the world map (starting at 200) gets going.

[naknode]

What we'd want to look at is this:

https://developer.mozilla.org/en-US/docs/Games/Techniques/Tilemaps#Performance

Drawing scrolling tile maps can take a toll on performance. Usually, some techniques need to be implemented so scrolling can be smooth. The first approach, as discussed above, is to only draw tiles that will be visible. But sometimes, this is not enough.

One simple technique consists of pre-rendering the map in a canvas on its own (when using the Canvas API) or on a texture (when using WebGL), so tiles don't need to be re-drawn every frame and rendering can be done in just one blitting operation. Of course, if the map is large this doesn't really solve the problem — and some systems don't have a very generous limit on how big a texture can be.

One way consists of drawing the section that will be visible off-canvas (instead of the entire map.) That means that as long as there is no scrolling, the map doesn't need to be rendered.

A caveat of that approach is that when there is a scrolling, that technique is not very efficient. A better way would be to create a canvas that is 2x2 tiles bigger than the visible area, so there is one tile of "bleeding" around the edges. That means that the map only needs to be redrawn on canvas when the scrolling has advanced one full tile — instead of every frame — while scrolling.

In fast games that might still not be enough. An alternative method would be to split the tilemap into big sections (like a full map split into 10 x 10 chunks of tiles), pre-render each one off-canvas and then treat each rendered section as a "big tile" in combination with one of the algorithms discussed above.

Basically, performance wise drawing the canvas offscreen. Or perhaps, draw +3 of all four directions so when they go it, it's already loaded.

[gamecodesolver]

Compression and saving bytes is good. This has been moved up to high due to the performance it will bring once the world map but unable fix this issue freefx4u