Is Graphics 2.0 going to happen?

Audio and Graphics
#1

Didn’t notice anything on the daily build logs and didn’t hear for a while about it…

Is it safe to say we are not going to see this in the next year? I see progress is made on other fronts so I’m just guessing this doesn’t have an urgent priority.

Any answer would be OK, we just need to schedule which games we develop first and our next planned game does need some of the features promised there… 

Also with the history of Corona Cloud and Levels you can’t blame me for having less confidence in this…

And a suggestion/question: why do you release such a huge feature as one big package? It’s just obvious you are going to get tons of bugs filed (not because of the quality of your work but just because that’s the nature of such big releases).

Why not split this to many updates in the daily build for example, you can introduce the display.newContainer as a standalone feature, you can add 2.5D transformations as another feature… why do you feel the need to bundle these all into one release and get it fire back in your face? I think your development process should be more agile and transparent. You should work more closely with your clients and keep releases as small as possible, small iterations with feedback from users. You do not need to guarantee anything works at first and just let the community play around with the new features one by one. You SHOULD use us, your loyal community as beta testers/QA, it will keep us involved in the process and I’m sure a lot of people would be very committed to helping out.

I think you’ll get better quality and happier clients this way. just my 2.5d cents :slight_smile:

#2

I would think, now that we’ve seen a number of demo’s from Corona, that Gfx2.0 will certainly happen. They’ve even named some of the library functions (eg: newContainer()). 

I’m sure the CCloud thing worried you, but I’m going to say, IMHO, Gfx2.0 is on the horizon and is being a single, large development because some things can’t be replaced piece by piece. It would be fine if we were talking about a single new function, but they are looking to replace the entire engine; You just can’t do that bit by bit.

Ok, fair enough, maybe there is a way to make it a plugin and introduce it as a partially complete piece which then grows over time, but I really think most people would hate that, considering that the graphics engine is such a deep underpinning of the Corona SDK - I would hate that and I doubt it’d be workable.

#3

@horacebury thanks for replying!

I have to disagree. The project scope is not an issue, from my own experience I was involved in much bigger updates than this one, for example revamping a trading engine that was responsible for millions of real financial transactions. We have worked on this for almost two year and released a deployable version each week. And every second week we released a new version that had some improvements and took advantage of our progress… We also got real feedback from the field and even in some case production issues that cost the firm money but in a small scale.

If we would have worked in the dark on this NO ONE would have the confidence to install it when it was done and we would have to put it through some rigorous testing and without the ability of having it live in the field even one minute. I assure you that at this stage we would have found issues that would causes us to turn back to the drawing table and redesign stuff which would cost us even more time.

Now this is an extreme scenario but it shows you that even systems that are dealing with critical data can be develop in an agile method with small releases, while it seems Corona is more “waterfall” oriented if you know the term…

BTW, the change we made was to retire our SQL DB layer and work with in memory structures without any risk of loosing trading data even on a crash, so you can understand this really involved changing the whole data model as well as the logic that was dependent on the DB transactions in general and the SQL language in specific. 

#4

Hi @gtt.  You’ve got a lot of questions that need addressed.  Let me try to answer what I can.

Graphics 2.0 is coming.  Walter said Summer 2013 and as far as I know that’s still on target.  Things can come up that may interrupt that, which is why we don’t give out firm dates.  An example is Android 4.3 changed font metrics and suddenly our apps display.newText() didn’t always display correctly.  We had to stop what we were doing and fix that.  Luckily right now those interruptions are few and far in between, unlike last summer where we had OS changes from Apple, Amazon and Barnes & Noble, new devices coming out from all of those vendors, and all of them requiring us to stop what we are doing and fix it.  

As for releasing incrementally, we do.  The Ouya controller bits is a good example of that as was plugins.  As we got something releasable we did in the daily builds.  We still are only going to do stable/public releases every couple of months, but the dailies lets us get out features and fixes quickly.  So why no Graphics 2.0 bits yet? Well we have released some bits but this project has so many moving parts, that all have to work together, we would rather release it when it’s something you can be productive with rather than limited.  It’s a huge change to the undying core, it can’t really be released until it’s mostly put together.   

I mentioned plugins above as a good example of incremental role outs.  It took months before we had enough of the system in place before we could start utilizing it.  Once the core was functional enough, we then rolled it out and are still working to get the final bits in place.

As for Agile development.  We are not an Agile shop and I don’t think Agile really would help  you very much.  We actually work faster than agile does with daily builds.   We can get fixes out faster and features out faster than going through a 2x2 sprint and release cycle.  Agile is great for online systems.  But for our product, Dailies + public releases every couple of months seems to hit the sweet spot.  

#5

I am sure there is also some need to keep things under cover long enough so you can leap frog ahead of competition once you release. This is a business after all and CL can’t play a totally transparent game and I fully understand that. My only wish is that when it comes it is fairly stable and that we don’t have to waste another 6 months trying to get things steady. 

#6

@Rob, Thanks for the reply! great to know it’s going to be release sooner than later :slight_smile:

Thanks also for your inputs, as for your development process I’m sure you guys have much more insight into what exactly suites your needs, but let me just say one thing.

Building daily is _not_ releasing. In any agile process a daily build is a MUST. In fact in the case I described we had an integration server that pulled any check in you made to subversion and immidiatly started a build + a suite of automatic tests that ran over 10,000 tests running over an hour… That’s how we had such great confidence in our product. and usually we had at least 5 builds daily…I am sure your builds have nothing to do with actual development interations, it’s just an automatic batch thing that runs on a schedule and catches whatever got completed that day. that’s great but not exactly the same thing…

I’m talking about actual development iterations that include sets of stories (content) that _must_ be implemented in this iteration (be it a week or two weeks). I know you feel your process works great but as an outside client I must say it doesn’t look this way. Don’t get me wrong, you have a great product which I love and I have no thoughts of moving elsewhere. But you have a very hard time giving us (and I’m guessing even to yourself) good relialble ETAs, and that’s usually not the signs of a healthy dev process.

Regarding “faster than agile”, well there is no real notion of speed here… I’m guessing we all try to work as fast as possible regardless of the process used. Releasing a fix the next day has nothing to do with this. I’ve been releasing fixes to production issues in a real time trading software within a few hours as you probably understand these system cannot really tolerate any known bugs, but again this has nothing to do with agile.

The difference with agile is that once you fix such a bug it gets pulled into the iteration and usually it kicks out a different story that wad previously scheduled to be completed. This is a great example of why the word agile is used, you instantly get to know what will and will not get done and with time you also learn what your velocity is and know to evaluate the length of small scope stories. that’s how you get real ETAs.

Now I’m guessing that if you take even Walter a few month back he would have simply no clue how much time is needed to finish Graphics 2.0. That’s because it’s just impossible to evaluate such a huge task… Even now when your are presumably very close to finishing you do not have a hard concrete date or even weeks timeframe (or you might have but do not publish which is fine).

To anyone who doesn’t understand what we’re talking about:

http://agilemethodology.org/

Not trying to convert you or anything :slight_smile: I just feel quite strong about this…

#7

Yes graphics 2.0 was probably the biggest reason I decided to renew my PRO subscription! (a little bit also because of IAP but since I am not making much with it…) So as you can imagine, I am very  eager:) Anyway, we will be able to do AR with it?

Thanks Rob for the update.

Mo

#8

One of my next projects will use some of graphics 2.0´s  features and won´t be possible without them. My company is using other SDKs/frameworks, too but I would like to create this with Corona :slight_smile:

#9

Sorry @gtt but Brent is right about the difference between online and application development. Just because one deployment methodology works in one scenario does not mean it will work for another - and that’s leaving out any contractual or otherwise legal requirements for keeping something under wraps (though I can’t think there would be any here except for good PR.)

Also, you’re wrong about agile: “In any agile process a daily build is a must.” No, I completely disagree. I run a web service project using Scrum and we only deploy to live when we feel the live users would actually benefit. We only deploy to business testers when we feel there is a mutual benefit from that level of testing. To say that daily builds are required by _any_ agile process is to completely misunderstand the agile methodology.

Further, auto-build, unit test and deploy is not a daily build - it is nothing more than Continuous Integration and is nothing more than a tool to get a job done. Specifically, the job would be rapid proving and regression testing of code. (Btw, CoronaLab’s Daily Builds are almost certainly not done on batch script as they do not appear every day and sometimes appear more than once a day. Of course, there will be plenty of automation, but it is not an automation which chooses to make the daily build published.)

None of my above points address what I consider to be your biggest misunderstanding, however: Daily Builds by CoronaLabs (or any other developer) are not part of CI, Agile or any other process. They are a courtesy and, in many ways, good PR for their customers. Daily Builds allow us to make use of the most recent developments and fixes which - and this is really important - CoronaLabs consider “done”, however reliable or not they may be.

You’ll notice the use of “done” in quotes as an Agile term being of two definitions. The latter, I suspect, being that a Public Build is made available and meaning that the feature is “done-done.” Neither of these terms actually apply to the features in the Daily Builds simply because WE are NOT part of CoronaLabs’ development team and as such are not (or rather, would not - considering Brent as already stated the lack of an agile process in-house) be part of the development cycle, hence the courtesy/PR.

Also, you’re original question was about whether or not Gfx2.0 is coming or not and it looks like it is, so I’m happy.

Sorry if I seem rather argumentative, but I do feel as though I’m responding in kind. It’s also very late here and I think I have food poisoning.

#10

Hope your food poisoning passes soon @horacebury.

I would suggest that if you guys want to discuss the agile methodology, its pros and cons, that you start a new thread in the Off topic forum.   The main thrust of this thread is about the availability of Graphics 2.0.

Thanks

Rob

#11

@horace, I would love to take this discussion offline, not in this thread but you are completely wrong about agile :slight_smile:

I have 6 years of experience managing a scrum team in a big financial firm, online or not (I dont know where you guys got the idea agile is good for certain things… our product was not online, it was an in house C++ backend server with over 10 million lines of code overall…) agile rules!

And if when Graphics 2.0 is out, and I’m guessing we’re going to see a lot of regression bugs I’ll wake this thread again :slight_smile:

#12

I would think, now that we’ve seen a number of demo’s from Corona, that Gfx2.0 will certainly happen. They’ve even named some of the library functions (eg: newContainer()). 

I’m sure the CCloud thing worried you, but I’m going to say, IMHO, Gfx2.0 is on the horizon and is being a single, large development because some things can’t be replaced piece by piece. It would be fine if we were talking about a single new function, but they are looking to replace the entire engine; You just can’t do that bit by bit.

Ok, fair enough, maybe there is a way to make it a plugin and introduce it as a partially complete piece which then grows over time, but I really think most people would hate that, considering that the graphics engine is such a deep underpinning of the Corona SDK - I would hate that and I doubt it’d be workable.

#13

@horacebury thanks for replying!

I have to disagree. The project scope is not an issue, from my own experience I was involved in much bigger updates than this one, for example revamping a trading engine that was responsible for millions of real financial transactions. We have worked on this for almost two year and released a deployable version each week. And every second week we released a new version that had some improvements and took advantage of our progress… We also got real feedback from the field and even in some case production issues that cost the firm money but in a small scale.

If we would have worked in the dark on this NO ONE would have the confidence to install it when it was done and we would have to put it through some rigorous testing and without the ability of having it live in the field even one minute. I assure you that at this stage we would have found issues that would causes us to turn back to the drawing table and redesign stuff which would cost us even more time.

Now this is an extreme scenario but it shows you that even systems that are dealing with critical data can be develop in an agile method with small releases, while it seems Corona is more “waterfall” oriented if you know the term…

BTW, the change we made was to retire our SQL DB layer and work with in memory structures without any risk of loosing trading data even on a crash, so you can understand this really involved changing the whole data model as well as the logic that was dependent on the DB transactions in general and the SQL language in specific. 

#14

Hi @gtt.  You’ve got a lot of questions that need addressed.  Let me try to answer what I can.

Graphics 2.0 is coming.  Walter said Summer 2013 and as far as I know that’s still on target.  Things can come up that may interrupt that, which is why we don’t give out firm dates.  An example is Android 4.3 changed font metrics and suddenly our apps display.newText() didn’t always display correctly.  We had to stop what we were doing and fix that.  Luckily right now those interruptions are few and far in between, unlike last summer where we had OS changes from Apple, Amazon and Barnes & Noble, new devices coming out from all of those vendors, and all of them requiring us to stop what we are doing and fix it.  

As for releasing incrementally, we do.  The Ouya controller bits is a good example of that as was plugins.  As we got something releasable we did in the daily builds.  We still are only going to do stable/public releases every couple of months, but the dailies lets us get out features and fixes quickly.  So why no Graphics 2.0 bits yet? Well we have released some bits but this project has so many moving parts, that all have to work together, we would rather release it when it’s something you can be productive with rather than limited.  It’s a huge change to the undying core, it can’t really be released until it’s mostly put together.   

I mentioned plugins above as a good example of incremental role outs.  It took months before we had enough of the system in place before we could start utilizing it.  Once the core was functional enough, we then rolled it out and are still working to get the final bits in place.

As for Agile development.  We are not an Agile shop and I don’t think Agile really would help  you very much.  We actually work faster than agile does with daily builds.   We can get fixes out faster and features out faster than going through a 2x2 sprint and release cycle.  Agile is great for online systems.  But for our product, Dailies + public releases every couple of months seems to hit the sweet spot.  

#15

I am sure there is also some need to keep things under cover long enough so you can leap frog ahead of competition once you release. This is a business after all and CL can’t play a totally transparent game and I fully understand that. My only wish is that when it comes it is fairly stable and that we don’t have to waste another 6 months trying to get things steady. 

#16

@Rob, Thanks for the reply! great to know it’s going to be release sooner than later :slight_smile:

Thanks also for your inputs, as for your development process I’m sure you guys have much more insight into what exactly suites your needs, but let me just say one thing.

Building daily is _not_ releasing. In any agile process a daily build is a MUST. In fact in the case I described we had an integration server that pulled any check in you made to subversion and immidiatly started a build + a suite of automatic tests that ran over 10,000 tests running over an hour… That’s how we had such great confidence in our product. and usually we had at least 5 builds daily…I am sure your builds have nothing to do with actual development interations, it’s just an automatic batch thing that runs on a schedule and catches whatever got completed that day. that’s great but not exactly the same thing…

I’m talking about actual development iterations that include sets of stories (content) that _must_ be implemented in this iteration (be it a week or two weeks). I know you feel your process works great but as an outside client I must say it doesn’t look this way. Don’t get me wrong, you have a great product which I love and I have no thoughts of moving elsewhere. But you have a very hard time giving us (and I’m guessing even to yourself) good relialble ETAs, and that’s usually not the signs of a healthy dev process.

Regarding “faster than agile”, well there is no real notion of speed here… I’m guessing we all try to work as fast as possible regardless of the process used. Releasing a fix the next day has nothing to do with this. I’ve been releasing fixes to production issues in a real time trading software within a few hours as you probably understand these system cannot really tolerate any known bugs, but again this has nothing to do with agile.

The difference with agile is that once you fix such a bug it gets pulled into the iteration and usually it kicks out a different story that wad previously scheduled to be completed. This is a great example of why the word agile is used, you instantly get to know what will and will not get done and with time you also learn what your velocity is and know to evaluate the length of small scope stories. that’s how you get real ETAs.

Now I’m guessing that if you take even Walter a few month back he would have simply no clue how much time is needed to finish Graphics 2.0. That’s because it’s just impossible to evaluate such a huge task… Even now when your are presumably very close to finishing you do not have a hard concrete date or even weeks timeframe (or you might have but do not publish which is fine).

To anyone who doesn’t understand what we’re talking about:

http://agilemethodology.org/

Not trying to convert you or anything :slight_smile: I just feel quite strong about this…

#17

Yes graphics 2.0 was probably the biggest reason I decided to renew my PRO subscription! (a little bit also because of IAP but since I am not making much with it…) So as you can imagine, I am very  eager:) Anyway, we will be able to do AR with it?

Thanks Rob for the update.

Mo

#18

One of my next projects will use some of graphics 2.0´s  features and won´t be possible without them. My company is using other SDKs/frameworks, too but I would like to create this with Corona :slight_smile:

#19

Sorry @gtt but Brent is right about the difference between online and application development. Just because one deployment methodology works in one scenario does not mean it will work for another - and that’s leaving out any contractual or otherwise legal requirements for keeping something under wraps (though I can’t think there would be any here except for good PR.)

Also, you’re wrong about agile: “In any agile process a daily build is a must.” No, I completely disagree. I run a web service project using Scrum and we only deploy to live when we feel the live users would actually benefit. We only deploy to business testers when we feel there is a mutual benefit from that level of testing. To say that daily builds are required by _any_ agile process is to completely misunderstand the agile methodology.

Further, auto-build, unit test and deploy is not a daily build - it is nothing more than Continuous Integration and is nothing more than a tool to get a job done. Specifically, the job would be rapid proving and regression testing of code. (Btw, CoronaLab’s Daily Builds are almost certainly not done on batch script as they do not appear every day and sometimes appear more than once a day. Of course, there will be plenty of automation, but it is not an automation which chooses to make the daily build published.)

None of my above points address what I consider to be your biggest misunderstanding, however: Daily Builds by CoronaLabs (or any other developer) are not part of CI, Agile or any other process. They are a courtesy and, in many ways, good PR for their customers. Daily Builds allow us to make use of the most recent developments and fixes which - and this is really important - CoronaLabs consider “done”, however reliable or not they may be.

You’ll notice the use of “done” in quotes as an Agile term being of two definitions. The latter, I suspect, being that a Public Build is made available and meaning that the feature is “done-done.” Neither of these terms actually apply to the features in the Daily Builds simply because WE are NOT part of CoronaLabs’ development team and as such are not (or rather, would not - considering Brent as already stated the lack of an agile process in-house) be part of the development cycle, hence the courtesy/PR.

Also, you’re original question was about whether or not Gfx2.0 is coming or not and it looks like it is, so I’m happy.

Sorry if I seem rather argumentative, but I do feel as though I’m responding in kind. It’s also very late here and I think I have food poisoning.

#20

Hope your food poisoning passes soon @horacebury.

I would suggest that if you guys want to discuss the agile methodology, its pros and cons, that you start a new thread in the Off topic forum.   The main thrust of this thread is about the availability of Graphics 2.0.

Thanks

Rob