====== LibTate Road Map ======

Project development is sporadic at best.

===== Base =====
Aims to have only the most refined, generic, abstracted code.

  * Status: //Done.//
    * Interestingly, much code was pruned from previous versions.
    * Only one actual source file.
    * Everything now is based on main, no longer bootstrapping
    * Also, no longer instantiating global classes at runtime within the library (except for tracking)-- this is left up to the user. As well there are currently no singleton classes.

  * TODO:
    * Test suite

===== Flow =====
This package is small, but very important-- enforcing and assisting in program flow control, and state machine logic... building on the fundamental classes in this package, any complex algorithm becomes trivial-- quick and easy to write.

  * Status: //Progressing well.//
    * All files are templates currently.
    * Suspect that this package may be finalized after TODOs are done. (No further work needed.)

  * TODO:
    * Not horribly fond of the "task" and "tasklist" names.
    * This may be the place to add a timing class. Not entirely sure-- it sort of fits, but if added, it would be not only the source file in this package, but the only platform specific source file so far. May better fit another package.
    * Test suite

===== MoreTypes =====
Surprisingly, this is the package with the most research against it-- the package with the most work and time spent on it.

  * Status: //Progressing well.//
    * Types currently implemented are fairly clean and complete

  * TODO:
    * Matrix
    * Quaternion
    * SoftFloat
    * Rational
    * Complex
    * MathFn for SoftFloat
    * MathFn for Fixed
    * Every class needs to be completely scrutinized for correctness
    * Optimizations for everything
    * Test suite for everything

--

===== Future Packages =====

  * **Bitmap** -- Somewhat unsure on how to progress on this
  * **Stream** -- This is back, but this time here's the idea-- java.io based streams are badly implemented-- Sequential Transducer Maps, and Tapes as abstraction classes will take the guesswork out of writing nested stream processors. Will heavily rely on the flow package.
  * **OpenGL ES 2.0 based** -- Definitely on the list-- this is the best choice for 3D; but would abstracting it better be the way to progress, or is it better to implement it as is? How do we handle different backends (software, opengl, directx, ps2, gba, ds) properly? And do we cater to non OpenGL 2.0 compliant folk somehow? Also, we can definitely implement uniform shaders (non standard), and on some platforms (ps2 for instance) we lack fragment shaders (and some other HW), but have geometry shaders (non standard), so what's the interface?
  * **EGL based** -- The pain in the ass that OpenGL ES depends on; where does it fit?
  * **Windowing** -- So the big question here is, which order-- windowing then 3d? 3d then windowing? Can't really progress on this without a solid gameplan-- a lesson learned from KempoAPI. Should support both for(;;){idle();} type processing as well as event-based.
  * **Input** -- argh. Not even sure how to begin on PC... DirectInput?
  * **Sound** -- argh. Two interfaces -- raw sound(for emulation and other purposes), and native sound playing.
  * **FMV** -- Probably not so rough, this has to be high level, and video files will more than likely be platform-specific.
  * **CPU (or Sim)** -- Everything is kind of building up to CPU emulation. Once there are some fundamental components(graphics and windowing) working, work on this can start. Will make heavy use of MoreTypes as well as Stream (possibly.) Graphics interfaces will be shader based (cool cool), but platform-specific.