On Monday, 6 January 2014 at 16:52:50 UTC, Justin Whear wrote:
If the ultimate goal is a high-level, idiomatic D library for
people who
are not necessarily experienced in CG, then shouldn't we start
with the
high-level interface and work down? That way the end-result
I don't disagree with this, but in reality most graphical
applications are simpler if you decouple the world-model from the
visuals and hence input from output and generate the visuals from
scratch for every frame. Cocos2D is a popular library that
maintains graphical state for you, but if you want to decouple
the model from rendering you end up syncing two data structures
which in the end is more work.
I think most successful libraries are focused and do one thing
really well, so suggesting dependencies:
CG BASIC
- vec: SSE tuples with swizzle
- geom2 depends on vec: basic geometry
- geom3 depends on vec (and geom2): 3D geometry
- spatialcollections depends on geom3: acceleration data
structures
GPU
- gpu depends on vec: DX/GL abstraction with shader support
- textureloader depends on gpu: loading jpeg/png into gpu memory
with caching
- texturerender depends on gpu, geom2,svgpath,image loader:
render to texture
VG
- svgpath depends on geom2: implements all svg path primitives +
transformations
- fontreader depends on geom2, svgpath: reading font+metadata +
generating paths
- fieldfont depends on fontreader, svgpath: creates signed
distance field textures
- simplepostscript depends on svgpath: for building pdf/drawing
on canvas2D
OS
- input: cross platform solution for input for various devices
(might look at marmalade and other cross platform engines for
ideas)
SAMPLE ENGINES
- canvas3D depends on canvas2D, geom3, spatialcollections,
texturerender/loader,input
- canvas2D... etc
