v2.0 Glorified Wishlist

[20kdc]

separated out from v1.6 wishlist

v2.0 stuff

Do these in the v1.5-maintenance branch (touches engine)

• [x] Image Editor should be using WSIImage for the generic IO.
• [x] Premultiplied alpha (MUST consider effect on image editor, audit the universe, etc.)
  • "Helpfully," moving Image Editor to WSIImage conveniently sidesteps this problem. Define WSIImage as being straight-alpha, and IImage as being premultiplied.
  • Expanded BadGPU's Texture Conversion Engine. ( https://github.com/20kdc/gabien-common/commit/181ed17f51a8f939d17276f7af09eca1b5021c2c )

"Black-Hole Data Compression"

• [x] To reduce merge conflict risk, route IDM3Context / IDM3Data classes in v1.5-maintenance
• [x] Implement modification squawking and states (in v1.5-maintenance)
• [x] PSYCHE!!! the User type strikes again
• [x] Replace MagicalBinder with either 'advanced' DM paths or just dedicated schema elements on a case by case basis
• [x] Global undo/redo manager, UI; this needs to be planned assuming both ObjectDB and Image Editor are going to be poking this, in fact it should be tested with the Image Editor
• [x] Integrate this with ObjectDB
• [x] Undo/Redo: Actually GOOD UI
• Undo/Redo: take over image editor's EDS responsibilities? nah
• [x] Undo/Redo: what about the memory leak risks

"Accelerator"

~~Layout Cleanup: UIFlowLayout Layout Cleanup: Actually use UIFlowLayout~~ Where? it doesn't really fit UIAppendButton layout semantics~~

• [x] Layout Cleanup: "Scroll-less Stack" (for items that will always be hosted within an SVL; skips stuff)
• [x] use UIListLayout

"Pizzazz"

• [x] Symbols should be using PVA Pixelorama, PVA 'costs too much' render-wise here without significant further work

"Atom"

• [x] Datum the command database
  • This should be a very 'loose' Datuming, similar to how theme resources work. Automate the conversion as much as possible without losing comments. If convenient, DMKey the command indexes. Much more mileage will be gotten from this change than anything else that could possibly be done.
  • Implemented 'kind of'. on the plus side DBLoader is officially gone so in theory it's just a matter of code refactorings now

"All The Stuff That Really Really Really Clearly Needs To Be Done Before Just Going And Calling This v2.0"

• [x] Map looping support
• Clean up the really bad stuff that came from the Datumization
  • [x] Command names
  • [x] C datum
• [x] Figure out what to do with the help system
  • Current ideas being thrown around involve Twine, but there are problems lurking beneath the surface due to issues with story format embedding and Twee export, so on and so forth
• [x] GaBIEn Natives have unreleased changes. Release them
• D/MVM: Types (implemented but badly)

"These Things Are Getting Kicked Down The Curb"

v2.1 wishlist time xdddddddd

• D/MVM: Better Types
• Componentize UIMapView services (StuffRenderer etc.)
  • New backends should be able to add and pull services from StuffRenderer independently of the rest of R48 code. Think dependency injection, but, like, without the injection.
  • USLX now has a class for the core of this!
• Make UIMapView replacable - a new backend should be able to just throw it all out, if necessary
• Implement a library in D/MVM for better JSON access using macros
• RMMV: Schema
• RMMV: System
• RMMV: Rendering

[20kdc]

outdated, see datamodel.md

Writing this down here because it might be useful: It might be an idea to have a dedicated "patch" object. These will be needed for undo anyway, and also can be used to batch the changes for undo/redo and do all sorts of useful stuff. The patch can then be "submitted" to a central object which can filter it down to the IRIOs. The main thing to worry about, then, is preventing writing patches "early", somehow (while also still having that as a transitionary feature or for special cases). Patch objects also need to maintain IRIO identity, somehow.