On 25.11.2011 07:00, Philip Wyett wrote: > * GL scaled to support older hardware and run. CS so auto scales > back and run on any sys dependant on it's capabilities.
The capabilities are already there; the main issue here is maintaining the shaders such that “fallback” versions for old hardware is provided. That said, there should be a minimal GL version (resp. HW generation) specified for which we promise support. Even so, if that target is too low, it will just mean extra developer burden (and testing effort) to keep the compatibility level. In practice, I strongly believe we shouldn't even consider supporting anything below GL 2.0 (i.e. GLSL availability): having to maintain fixed function shaders is catering to a technology that is not simply dying but is already partially decomposed. AFAIK current mobile graphics (GLES >= 2.0) is built around GLSL shader programs. > * Add GLES support (CS on mobile) Something that would benefit from having GLSL as well. > * Remove bad licensed code or additions. We can write it ourselves. I suspect you mean the few splotches of non-GPL code in CS? > * Drop apps that are fantasy. Please elaborate what “fantasy apps” means here. > * CS will base on Windows - Oldest supported. > * CS will base on GNU Linux - Debian stable and RHEL > * CS will base on Apple - Oldest supported. > * CS will add platforms that will be supported. I'm not sure I get what “oldest supported” means here. > * No new features or API changes without approval. I'm with Mike here: (a) Approval by whom? (b) The existing process seems to work well enough; changes certainly tend to happen quickly enough. > * If it not documented it does not get in. If you do not > or will not document your code or add into the docs. Your > addition will be dropped! I'd just like to point out that such a requirement can also act as a deterrent ;P > * Upgrade to website. This needs manpower; ideally, a dedicated person. > SVN: > * No merges into trunk. Commit code only. No merges into trunk > from branches will be allowed! This seems against the existing practice to work on changes which are deemed too experimental/risky/unstable/breaking/interfering on it's own branch and merge this into trunk later. Considering we're trying to keep trunk permanently “in working order”, mandating development should happen on trunk seems to pretty much oppose that idea. -f.r.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
_______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[email protected]?subject=unsubscribe
