Check in updated docs before break

Ideas.md

@@ -141,6 +141,21 @@ Probably mostly DRM free. Will want some sort of account server early-on though.
   representation before we go live. JSON support shall remain, but the
   production application will not _write_ JSON files, only read them.
   (This way we can ship drawings in the git repo as text files).
+* The app will support reading three types of files:
+  * `.canvas` files are the lowest common denominator, raw drawing data. It
+    contains a Palette and a pixel grid and nothing more.
+  * `.map` files are level maps. They include a Canvas along with level
+    metadata, Doodad array, attached files, etc.
+  * `.doodad` files are for doodads. They include a Canvas along with
+    metadata, embedded JavaScript, attached files, etc.
+* JSON versions will have `.json.<ext>` file suffixes, like `.json.canvas`
+  or `.json.map`
+* The **production** app will be only be able to read the binary format of
+  the files. The JSON reading code is for dev builds only.
+* Shareware/Demo builds will have even more restrictions on supported file
+  types. For example it won't be built with the code that allows it to
+  read _or_ write a Doodad from disk, as it will be limited only to built-in
+  Doodads and won't support authoring custom ones.
 
 ## Common Drawing Files
 

README.md

@@ -114,7 +114,7 @@ As a rough idea of the milestones needed for this game to work:
   OpenGL or something later on.
 * [x] Implement a command line shell in-game to ease development before a user
   interface is created.
-  * [ ] Add support for the shell to pop itself open and ask the user for
+  * [x] Add support for the shell to pop itself open and ask the user for
     input prompts.
 
 ## Alpha Platformer
@@ -157,11 +157,11 @@ As a rough idea of the milestones needed for this game to work:
 * [x] Create a "Main Menu" scene with buttons to enter a new Edit Mode,
   play an existing map from disk, etc.
 * [x] Add user interface Frames or Windows to the Edit Mode.
-  * [ ] A toolbar of buttons (New, Save, Open, Play) can be drawn at the top
+  * [x] A toolbar of buttons (New, Save, Open, Play) can be drawn at the top
     before the UI toolkit gains a proper MenuBar widget.
   * [x] Expand the Palette support in levels for solid vs. transparent, fire,
     etc. with UI toolbar to choose palettes.
-* [ ] Add a "Canvas" widget that will hold level drawing data and abstract it
+* [x] Add a "Canvas" widget that will hold level drawing data and abstract it
   out such that the Canvas can have a constrained width and height, position,
   and "scrollable" viewport area that determines rendered pixels. Will be VERY
   useful for Doodads and working on levels smaller than your window size (like

docs/Grid Data Structure.md

@@ -0,0 +1,49 @@
+# Grid Data Structure Ideas
+
+Ideas for managing level pixel grids.
+
+## Chunks
+
+Divide the grid into Chunks of an arbitrary size. The canvas metadata would
+specify the chunk size (e.g. 1000x1000 pixels) so it's able to vary by the
+drawing itself.
+
+A `ChunkManager` structure would wrap around the chunks and give each one a
+coordinate value. To convert an absolute pixel value into a chunk coordinate
+you multiply it by the chunk size.
+
+So a pixel coord of `123456` in a map with 1000x1000 chunk sizes would be
+`(123456) / 1000 = 123.456 = 123` (rounded down). This would give you a chunk
+index and then that chunk is responsible for knowing where the exact pixel is.
+
+## Chunk Types
+
+Each chunk could organize its pixels into two types of structures depending
+on the density of the chunk:
+
+1. A hash map for sparse chunks.
+2. A 2D array of fixed size for dense chunks.
+
+So if a chunk is <70% filled it would use a hash map and when it gets heavier
+than that, switch to a 2D array.
+
+Something like,
+
+```go
+type Chunk struct {
+    Type int `json:"type"` // map vs. 2D array
+    Map map[Point]int      // map of (X,Y) points to Palette entry
+    Grid [][]int           // 2D array of Palette entries
+}
+```
+
+## External Chunks
+
+For normal single-player maps that aren't infinite in size, all the chunks
+are stored in the singular level file. Larger maps can start saving their
+chunks to disk in external files.
+
+Some internal threshhold can be used to decide when to start saving chunks
+as external files. If the chunk size is 1000x1000 pixels it could start saving
+external files after (say) 9 different chunks are allocated for the first time,
+or some time/space tradeoff like that.