On Fri, 2011-11-25 at 14:15 +0100, res wrote: > 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.
Do some testing and come back with the rubbish you say above. > > > * Add GLES support (CS on mobile) > > Something that would benefit from having GLSL as well. > Of course. > > * Remove bad licensed code or additions. We can write it ourselves. > > I suspect you mean the few splotches of non-GPL code in CS? > Imagelib and splotches of boost code. > > * Drop apps that are fantasy. > > Please elaborate what “fantasy apps” means here. > All that are not basic function tests. walktest is fine. Why do we need 2 water demo's. The tests like avatar need lowering. > > * 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. > Anything not End OF Life like XP etc. With Linux I was very specific. > > * 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 > Tough, do the docs or I or others will delete it. > > * Upgrade to website. > > This needs manpower; ideally, a dedicated person. > Yes, we will look for a volunteer. > > 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. I have dealt with this. Regards Phil ------------------------------------------------------------------------------ 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 Crystal-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:crystal-main-requ...@lists.sourceforge.net?subject=unsubscribe
