summaryrefslogtreecommitdiff
path: root/TODO
diff options
context:
space:
mode:
Diffstat (limited to 'TODO')
-rw-r--r--TODO35
1 files changed, 25 insertions, 10 deletions
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.
© All Rights Reserved