text: update README and TODO

2 files changed, 33 insertions, 19 deletions

diff --git a/README b/README
index e05473e..4f9dbb6 100644
--- a/README
+++ b/README
@@ -1,3 +1,10 @@
+rototiller is, rendered entirely in software:
+	roto: a simple fixed-point tiled texture rotation
+	ray: a multi-threaded ray tracer
+	sparkler: a fireworks-like particle system with spatial interactions
+
+---
+
 This is a quick little graphics hack I put together to experiment with libdrm
 and this "dumb buffer" thingy David Airlie added to the kernel back in 2011.
 
@@ -18,14 +25,6 @@ resolutions and abundant memory for 32bpp with page flipping.
 
 In my testing so far, this seems to work without even requiring root.
 
-The test machine is a 1.6Ghz Core2 duo w/i915 and 1400x1050 (x61s w/SXGA+), and
-rototiller64 only uses 30-40% of one core, rendering a flawless 50HZ.
-
-As for the files, they're identical, except rototiller64 writes 64-bit words at
-a time to the graphics buffer, rototiller32 writes 32-bit words at a time.  On
-the test machine 64-bit is good for a few % CPU savings.  I included the 32-bit
-version since it's simpler to read and maybe you have a 32-bit box.
-
 Before you try to run these things, realize this is direct libdrm graphics,
 it's going to compete with your X/wayland server.  Switch to a plain virtual
 console to run the program.  You don't need to quit X, just switch away from the
@@ -33,7 +32,7 @@ X vt so it's not visible.
 
 To quit it's as simple as Ctrl-C, rototiller will otherwise run forever.
 
-Do not try switching back to X while rototiller is running, Ctrl-C it first, or
+Do not try switching back to X while rototiller is drawing, Ctrl-C it first, or
 X will get angry and exit when it tries to do drm things and can't.
 
 Your display may be left in an inconsistent state after exiting rototiller.
diff --git a/TODO b/TODO
index 2a006b8..9e45a26 100644
--- a/TODO
+++ b/TODO
@@ -1,18 +1,33 @@
-- Split out the rendering functions into their own listings, consolidate into
-  a single main, it'd be neat to just have a bunch of rendering plugins for eye
-  candy you can select on the commandline.
+- Figure out why drm isn't restoring the console automatically when killed,
+  when a VT switch restores everything, this starts to look like a drm bug.
 
-- Replace the dirty mess of libdrm calls with a flexible drm setup thingy, so
-  the user can choose the crtc/encoder/connector/mode etc.  It's all hard-coded
-  currently, requiring you to go change ~3 lines to make it display on an
-  external monitor for example.
+- Switch to an ncurses UI for choosing the device/connector, maybe add ability
+  to reconfigure the drm video mode and more sophisticated topology changes?
 
-  I'd like a commandline interface for selecting the outputs, an interactive
-  text one for navigating the drm topology and selecting what you want would be
-  a nice alternative as well.
+- Optimize the ray tracer, a spatial index would be nice, there's an octree in
+  the sparkler particle system that may be applicable.  A k-d tree is probably
+  better though, since once can play with the hyperplane heuristics to better
+  suit ray tracing and adapt to the scene complexity.  The threading could also
+  use some love, I haven't had a chance to test it on anything greater than 2
+  cores.
+
+- autotools?  my Makefile is very quick and dirty
+
+- If keeping the stdio drmsetup, fix the bugs in it (input isn't really checked
+  properly)
 
 - Figure out if it's possible/how to page flip and synchronize multiple crtcs
   at once.  Can we have a drm program running discrete effects on multiple
   monitors, in a tear-free fashion on all of them?  I think this is actually a
   complicated problem they're struggling to deal with in X/weston land general
   multihead.
+
+- Add more colorful explosions to the sparkler
+
+- The sparkler can produce drastically different simulations with little
+  change, it would be neat to generalize it further to where there are just
+  profiles of sorts which describe the system then the sparkler runs the
+  simulation.  Turning sparkler into just a platform which manages memory,
+  indexes space, and runs the chosen rules would be neat.  As-is one would just
+  clone the sparkler module to a new tree and start tweaking things and adding
+  new particle types, which is fine just inelegant.