summaryrefslogtreecommitdiff
path: root/TODO
blob: 9e45a26e0e3f0c7b26262415eb5abef55400daea (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
- 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.

- Switch to an ncurses UI for choosing the device/connector, maybe add ability
  to reconfigure the drm video mode and more sophisticated topology changes?

- 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