|
| 1 | +# Development priorities by version |
| 2 | + |
| 3 | +This project has repeatedly traded **progress** (how fast we can build), **functionality** (how much the app can do), and **performance** (how fast it runs on hardware). None of the three can be maximized at once; each prototype picked a different balance. |
| 4 | + |
| 5 | +After **v0.3** — when the UI is in very good shape — the plan is to optimize for **performance** again. |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +## The triangle model |
| 10 | + |
| 11 | +Every version can be drawn as a triangle with three corners: |
| 12 | + |
| 13 | +| Corner | Meaning | |
| 14 | +|--------|---------| |
| 15 | +| **Progress** | Speed of development; shipping visible changes quickly; iteration over polish | |
| 16 | +| **Functionality** | Features, settings, filters, metadata, screens, user-facing capability | |
| 17 | +| **Performance** | Responsiveness on a real 3DS; I/O cost; rebuild time; redraw cost | |
| 18 | + |
| 19 | +The **centre of gravity** (★) shows what that version optimized for. Closer to a corner or edge = stronger emphasis there. |
| 20 | + |
| 21 | +--- |
| 22 | + |
| 23 | +## Version history (narrative) |
| 24 | + |
| 25 | +### Initial prototype |
| 26 | + |
| 27 | +Built for **speed** and assembled **very quickly**. That pass produced a lot of **progress** and the app felt **fast** on device. Scope was narrow by design. |
| 28 | + |
| 29 | +### Next prototype |
| 30 | + |
| 31 | +Gained a little **more functionality**, with **less focus on progress** — more time went into features than into raw shipping speed. **Performance was left untouched**; what worked stayed as-is. |
| 32 | + |
| 33 | +### v0.2.0 |
| 34 | + |
| 35 | +Built with **functionality** and **rapid building** in mind. Filters, options, multiple screens, title database growth, and richer pick logic landed in a short window. **Performance took a hit** here: more work per reroll, full pool rebuilds, linear catalog scans, and heavier I/O were accepted as the cost of capability. |
| 36 | + |
| 37 | +### v0.2.1 (current) |
| 38 | + |
| 39 | +Focus is **UI**: layout, copy, inverted header/footer, paginator, filter section, fixed rows — built **rapidly** (**progress**) while preserving and surfacing **functionality**. **Performance has been hit hard** again: every interaction still triggers full `consoleClear()` redraws on top of the v0.2.0 backend costs, without backend optimization in this pass. |
| 40 | + |
| 41 | +### v0.3 (planned) |
| 42 | + |
| 43 | +UI should be in **very good shape**. Then **performance** becomes the primary optimization target again, rebalancing the triangle without dropping the features and UI already shipped. |
| 44 | + |
| 45 | +--- |
| 46 | + |
| 47 | +## Priority balance diagrams |
| 48 | + |
| 49 | +Each diagram uses the same three corners. **★** = centre of gravity for that version. |
| 50 | + |
| 51 | +### Diagram 1 — Initial prototype |
| 52 | + |
| 53 | +**Emphasis:** Progress + Performance. Minimal functionality. |
| 54 | + |
| 55 | +``` |
| 56 | + PROGRESS |
| 57 | + (rapid build) |
| 58 | + ▲ |
| 59 | + / \ |
| 60 | + / \ |
| 61 | + / \ |
| 62 | + / ★ \ ← high progress, high performance |
| 63 | + / \ |
| 64 | + / \ |
| 65 | + /_____________\ |
| 66 | + FUNCTIONALITY PERFORMANCE |
| 67 | + (minimal) (strong) |
| 68 | +``` |
| 69 | + |
| 70 | +| Priority | Level | |
| 71 | +|----------|-------| |
| 72 | +| Progress | ●●●●● High | |
| 73 | +| Functionality | ● Low | |
| 74 | +| Performance | ●●●●● High | |
| 75 | + |
| 76 | +--- |
| 77 | + |
| 78 | +### Diagram 2 — Next prototype → v0.2.0 |
| 79 | + |
| 80 | +**Emphasis:** Functionality rises; progress stays strong through v0.2.0; performance starts to slip at v0.2.0. |
| 81 | + |
| 82 | +**Next prototype** (lighter shift): |
| 83 | + |
| 84 | +``` |
| 85 | + PROGRESS |
| 86 | + ▲ |
| 87 | + / \ |
| 88 | + / \ |
| 89 | + / ★ \ ← functionality grows; perf unchanged |
| 90 | + / \ |
| 91 | + /_________\ |
| 92 | + FUNCTIONALITY PERFORMANCE |
| 93 | + (growing) (held) |
| 94 | +``` |
| 95 | + |
| 96 | +**v0.2.0** (same diagram family, centre moves): |
| 97 | + |
| 98 | +``` |
| 99 | + PROGRESS |
| 100 | + ▲ |
| 101 | + / \ |
| 102 | + / ★ \ |
| 103 | + / \ ← functionality + rapid feature build |
| 104 | + / \ |
| 105 | + /_________\ |
| 106 | + FUNCTIONALITY PERFORMANCE |
| 107 | + (strong) (weaker) |
| 108 | +``` |
| 109 | + |
| 110 | +| Version | Progress | Functionality | Performance | |
| 111 | +|---------|----------|---------------|-------------| |
| 112 | +| Next prototype | ●●● Medium | ●●● Growing | ●●●● Unchanged | |
| 113 | +| v0.2.0 | ●●●● High | ●●●● Strong | ●● Declining | |
| 114 | + |
| 115 | +--- |
| 116 | + |
| 117 | +### Diagram 3 — v0.2.1 (current) → v0.3 (planned) |
| 118 | + |
| 119 | +**v0.2.1 — today:** UI + progress + functionality; performance deprioritized. |
| 120 | + |
| 121 | +``` |
| 122 | + PROGRESS |
| 123 | + ▲ |
| 124 | + / \ |
| 125 | + / \ |
| 126 | + / \ |
| 127 | + / \ |
| 128 | + / ★ \ ← UI built fast; features exposed; |
| 129 | + / \ backend perf not addressed |
| 130 | + /_______________\ |
| 131 | + FUNCTIONALITY PERFORMANCE |
| 132 | + (strong) (weak) |
| 133 | +``` |
| 134 | + |
| 135 | +| Priority | Level | |
| 136 | +|----------|-------| |
| 137 | +| Progress | ●●●● High (rapid UI iteration) | |
| 138 | +| Functionality | ●●●● Strong (filters, pages, settings) | |
| 139 | +| Performance | ● Weak (full redraws + v0.2.0 backend cost) | |
| 140 | + |
| 141 | +**v0.3 — planned:** UI complete; centre of gravity moves toward Performance. |
| 142 | + |
| 143 | +``` |
| 144 | + PROGRESS |
| 145 | + ▲ |
| 146 | + / \ |
| 147 | + / \ |
| 148 | + / \ |
| 149 | + / \ |
| 150 | + / \ |
| 151 | + / ★ \ ← perf optimization pass |
| 152 | + /_______________\ |
| 153 | + FUNCTIONALITY PERFORMANCE |
| 154 | + (maintain) (restore) |
| 155 | +``` |
| 156 | + |
| 157 | +| Priority | Level | |
| 158 | +|----------|-------| |
| 159 | +| Progress | ●● Medium (polish + optimization) | |
| 160 | +| Functionality | ●●●● Maintain | |
| 161 | +| Performance | ●●●●● Primary focus | |
| 162 | + |
| 163 | +--- |
| 164 | + |
| 165 | +## Evolution at a glance |
| 166 | + |
| 167 | +``` |
| 168 | +Initial Next v0.2.0 v0.2.1 v0.3 (plan) |
| 169 | +prototype prototype |
| 170 | + │ │ │ │ │ |
| 171 | + ▼ ▼ ▼ ▼ ▼ |
| 172 | + progress functionality functionality UI/progress performance |
| 173 | + + + + + + |
| 174 | + performance (perf flat) (perf ↓) (perf ↓↓) (perf ↑) |
| 175 | + (function low) |
| 176 | +``` |
| 177 | + |
| 178 | +--- |
| 179 | + |
| 180 | +## Performance notes (v0.2.1) |
| 181 | + |
| 182 | +The UI pass did not fix underlying costs from v0.2.0. The main bottlenecks today are: |
| 183 | + |
| 184 | +- **SMDH / icon file read** on every reroll (`title_smdh_load`) |
| 185 | +- **Linear scan** of ~8,700-entry title database during pool rebuild |
| 186 | +- **Full pool rebuild** on every filter toggle |
| 187 | +- **`consoleClear()`** full-screen redraw on most interactions |
| 188 | + |
| 189 | +These are documented in more detail in code review and [`MAIN_C_FUNCTIONALITY.md`](MAIN_C_FUNCTIONALITY.md). A v0.3 performance pass would likely target catalog lookup, pick caching, lazy metadata load, and partial UI updates first. |
| 190 | + |
| 191 | +--- |
| 192 | + |
| 193 | +## Related |
| 194 | + |
| 195 | +- [`VERSIONING.md`](VERSIONING.md) — semver rules and release mapping |
| 196 | +- [`VERSION`](../VERSION) — current version file |
0 commit comments