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. >
GL 1.2 should be a base at least. We need to be open to all app dev both 2D and 3D. 1.1 would be better. Why keep high when devices may support lower. We have the time and effort to create from the base correctly and support all. > > * 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? > All need to go. > > * 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. > Well, here it means what is the oldest OS release supported by the vendor. For Windows it would be XP. > > * 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. > A new system will be put in lace where commits are verified by non devs or early devs. Ancient devs like you and me will not be included. I know we are not old - OK, I am. > > * 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 > Rubbish, This one stands no matter what! > > * 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. > Merges into trunk cause much hassle and tracking. Many want to see changes into trunk as a diff not a merge and not go here and there to find the diff. Trunk should be pure code. If a dev cannot diff there own tree and commit with an explanation, they should not be a dev. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[email protected]?subject=unsubscribe
