3 ms·

Very good, how did you do the infinite grid ? I am also working on an infinite grid pixel art tool :)

and0 10y ago
I made an (unreleased) roguelike engine with a (virtually) infinite world, like Minecraft etc, in Java. I did it as a Hashtable<int, DataContainer>. In your case DataContainer would be some part of the canvas, maybe a 32x32 pixel area. And the int key would be the index of the x&y coordinates of that particular area. The image dimensions could then be a max size of the square root of an unsigned int, and to get the index of each tile you'd just do (y * dimension + x). You'd throw all this into a little wrapper so you have a "virtual" canvas that could be as big as you'd ever need it to be. Also, don't actually initialize each piece of canvas until a pixel is actually placed in it, instead returning a static empty section of canvas if the key isn't in the hashtable yet. This allows for zooming way out smoothly.
- RodgerTheGreat 10y ago
  Building on this, the general approach you're describing is a "sparse" data structure. For example, https://en.wikipedia.org/wiki/Sparse_array https://en.wikipedia.org/wiki/Sparse_array A cousin to this approach would be using some type of space partition with the assumption that most of the partitions represent large, uniform (empty or solid-filled) areas: https://en.wikipedia.org/wiki/Space_partitioning https://en.wikipedia.org/wiki/Space_partitioning You can see that these are fundamentally related ideas- pay for the complexity of the data you store rather than its volume.
  - and0 10y ago
    Right, I also wanted to mention using a Quadtree but that seems excessive for pixel art (or most applications, for that matter). e: Another consideration would be keeping level-of-detail versions of each chunk of canvas as well, so zooming very far out loads/shows a lower resolution rendering. That would let you make a Google Maps style collaborative pixel art canvas or something.

and0 10y ago

I made an (unreleased) roguelike engine with a (virtually) infinite world, like Minecraft etc, in Java. I did it as a Hashtable<int, DataContainer>. In your case DataContainer would be some part of the canvas, maybe a 32x32 pixel area. And the int key would be the index of the x&y coordinates of that particular area. The image dimensions could then be a max size of the square root of an unsigned int, and to get the index of each tile you'd just do (y * dimension + x). You'd throw all this into a little wrapper so you have a "virtual" canvas that could be as big as you'd ever need it to be. Also, don't actually initialize each piece of canvas until a pixel is actually placed in it, instead returning a static empty section of canvas if the key isn't in the hashtable yet. This allows for zooming way out smoothly.

RodgerTheGreat 10y ago
Building on this, the general approach you're describing is a "sparse" data structure. For example, https://en.wikipedia.org/wiki/Sparse_array https://en.wikipedia.org/wiki/Sparse_array A cousin to this approach would be using some type of space partition with the assumption that most of the partitions represent large, uniform (empty or solid-filled) areas: https://en.wikipedia.org/wiki/Space_partitioning https://en.wikipedia.org/wiki/Space_partitioning You can see that these are fundamentally related ideas- pay for the complexity of the data you store rather than its volume.
- and0 10y ago
  Right, I also wanted to mention using a Quadtree but that seems excessive for pixel art (or most applications, for that matter). e: Another consideration would be keeping level-of-detail versions of each chunk of canvas as well, so zooming very far out loads/shows a lower resolution rendering. That would let you make a Google Maps style collaborative pixel art canvas or something.