1) Assuming you're parsing GLSL, then allow for constants to have UI elements (like uniforms).
Would you like this because uniforms have some (little) performence penalty? Maybe I should implement uniform locking like in the Fragmentarium. It basically replaces uniforms with constants.
For non-realtime, say rendering a procedurally generated movie slight performance difference can really add up. For realtime (coupled with nanosecond rendering time) it allows for a more accurate estimation of how much GPU budget a given implementation is consuming. Having a variable as a constant opens up more optimization to the backend than a uniform. Additionally it's slightly less runtime overhead.
Personally I'd slightly prefer:
. The idea is "what you write is what you mean" and it's purposefully invalid GLSL. This is only a minor point however. Some other thoughts in this direction are: Having a command-line interface coupled with your future scripting support to allow exporting from the internal format to some (potentially custom) format used by the target application.
2) Print out the rendering time
FPS counter isn't sufficient or do you mean rendering time in progressive mode? Of course I could add this feature. (maybe tomorrow).
For realtime, FPS stands for Freaking Pointless System (of measurement). What you really want is ns/frame and/or ns/fragment. FPS numbers are too course grain and the inverse time nature makes it very misleading. Consider 200 fps. Gosh that's fast! Except it isn't if your targeting 60 fps for everything. It's 30% of your total GPU budget. And 100 fps is 60%, 80 is 75%...see what I mean. It's much easier to think in linear things.
3) Engine generated quasi-random provided as a uniform. Say a vec4 where the values are updated once per progressive frame.
This will be possible when I implement scripting support.
Scripting support is even more awesome.
As of 2D rotation component I will start implementing it today