Status update - What to expect, when you are expecting OpenGL ES 2.

Scouser

@zoolax: Sometimes it's the simple things that put people off & I agree about your advice/solution point.

I have offered both in my time on these boards, none of which have been implemented yet (but I feel they will in due course).

Just to remind @atilim & @ar2rsawseen that a couple of these ideas can be found here and here. These 2 points only affect Android but both have quite a few posts asking how to solve / fix the problems.

ar2rsawseen

And here is our first Status report:
http://blog.giderosmobile.com/post/53369300556/status-report-19-june-2013

Any feedback welcomed, so we can improve next report, etc

gianmichele

I think it's great! Can't wait to try the new version and test the improvements.

moopf

@ar2rsawseen I thought the plugins you'd done would be bundled with this release but there's no mention of that on the status report?

ar2rsawseen

@moopf yes they won't be bundled with this release for couple of reasons:
1) not including them speeds up the release time
2) in some plugins, like notification, there were some bugs reported that are now being checked and fixed
3) including all the plugins meant for Android, like Flurry, Facebook would make the exported project huge, on the other hand not including them would be basically the same as now, you would need to add them manually.

So until we come up with some more sophisticated approach on this, they will be just plugins as now.

keszegh

maybe for official (stable) plugins included in the gideros install there could be an option to include them in our project one-by-one using ~ require(gideros.facebook) or something like that in some way, thus it won't bloat up the apk unnecessarily, as it would include only the plugins we need. yet it would be in the basic gideros package, so users do not need to download them one by one.
already the few plugins that are in base gideros now, e.g. googlebilling, they are making the apk bigger unnecessarily in case one does not use them.

petec

I agree with @keszegh about not bloating the apk. When I used to use Corona I found every update made my apk considerably larger even though I was using the same code and assets. Being able to install official plugins easily as an option rather than having them there all the time would suit me.

hgvyas123

So until we come up with some more sophisticated approach on this, they will be just plugins as now.

plz add them in installation folder under examples as most of people doesn't aware about where to get those plugins

ar2rsawseen

@keszegh and @petec that is exactly what I meant by "come up with some more sophisticated approach". It is now even more complicated to do, when exporting is separated from Studio, but not impossible and would be applied to both new and old plugins.

petec

@ar2rsawseen Excellent!

ar2rsawseen

@hgvyas123 most probably we will find other united place where to put all the plugins, stay tuned

vitalitymobile

@ar2rsawseen It will be great! I imagine that in future, we will config plugin in gideros project properties :P

ar2rsawseen

Hello guys,
quick update, sorry for the delay of the release.
@atilim is working hard and basically last thing left is Render to texture.
Desktop and IOS versions already implemented, now need to work out some quirks on Android side (OpenGL context gets deleted and needs to be properly restored, which in case of Render to Texture is a little bit tricky).
Once that done, we are all set and ready to go

paul_k_clark

@ar2rsawseen thanks for the update

zoolax

@ar2rsawseen thanks for keeping us informed,and all the hard work.

unlying

3) including all the plugins meant for Android, like Flurry, Facebook would make the exported project huge, on the other hand not including them would be basically the same as now, you would need to add them manually.

To be true i'm a little bit tired with all that plugin stuff. It is so exhausting to implement 4-5 plugins to project. Why not include it using require? If project has require "charboost" - chartboost plugin, "googleplay" - playservices. It is look like not really hard solution that will fit for everybody.

ar2rsawseen

Actually that is a very hard solution (if not impossible), because it can't be determined at export. Exporting does not run the project.

Currently what we think is more like checkboxes in the export window in Gideros Studio, where you check which plugins to include in exported project, still it's not so easy and needs quite sophisticated project merging, but we have a plan and will work on it.

Also with googleplay and even chartboost it could get tricky because if in chartboost case you need to include chartboost.jar (which we could do theoretically) in googleplayservices case it needs to reference external project in the same directory, where you export your project and import in eclipse, which is impossible for us to determine, unless we completely control your computer

So in most cases, you would still have to include 3rd party libs by yourself

unlying

I'm ok with 3rd party libs. I'm only speaking about files that helps it works with gideros.
If you do checkboxes than add textboxes for identificators(appid and same), please. To integrate it with values that we need.

paul_k_clark

@ar2rsawseen rather than have checkboxes in the export could they be project properties. That way if you include several plugins you don't need to remember to include them every time you export.

ar2rsawseen

@paul_k_clark well basically they would be saved in .gproj file and used by external exporter, so any IDE or program can provide it's own way of handling them

ar2rsawseen

Hello just wanted to note, that me and @atilim are playing ping pong (with the new release)
Testing it, finding bugs and fixing.
And actually we've been doing kind of great, finding even some hardware specific bugs, that could be quite hard to figure out later.
With latest test version, only one bug was found, but a pretty bad ass one (with textures), so when that fixed, if next version will pass all tests you will see a new release.

P.S. played a lot with Render to Texture, very simple api, very easy to use, yet so powerful and flexible.
Only one problem, does not run on my 6 year old laptop (gpu does not support some specific OpenGL features), so just a heads up, that you won't be able to use it on some oldie. But it actually works on my old Android LG P500 Optimus and works on Ipod 2gen, so old phones support it

moopf

Only one problem, does not run on my 6 year old laptop (gpu does not support some specific OpenGL features), so just a heads up, that you won't be able to use it on some oldie. But it actually works on my old Android LG P500 Optimus and works on Ipod 2gen, so old phones support it

You'll find that the original iPhone also supports it (not that that matters any more). My Arthur & Charles app uses render to texture a lot and I tested that quite happily on my original iPhone just because I could

zoolax

@ar2rsawseen
I feel as it is my birthday.
I can hardly wait for my new toy.
Thanks to all the Gideros team for all the hard work and keeping us informed. <:-P <:-P <:-P <:-P

phongtt

@ar2rsawseen: I think the new release will come out in 8 hours 8-X

code_monkey

=D>

atilim

Well good news is that we could not find any more bugs, but since it will be (hopefully) the last version of OpenGL ES 1.1 and (due to support for older devices) some member will like to stick with it for some longer period of time.
Thats is why we also decided to test it with compatibility for iOS 7, basically which we are doing today, it should probably not take more than a day, so hopefully release will be (depending on how the testing goes) today or tomorrow.

ar2rsawseen

A little sneak peek:
http://docs.giderosmobile.com/reference/gideros/RenderTarget#RenderTarget

OZApps

A little sneak peek:
http://docs.giderosmobile.com/reference/gideros/RenderTarget#RenderTarget

With RenderTarget having just the three methods, new, clear and draw; would it cater for everyones use? can we have what was called BitBlt and StretchBlt ?? Do we have to draw to a shape before it can be rendered to the texture using draw?

ar2rsawseen

RenderTarget is a texture and you can use it as any texture:

local texture = RenderTarget.new(480, 320) local region1 = TextureRegion.new(texture, 0, 0, 100, 100) local bitmap1 = Bitmap.new(region1)

after that you only need to clear and draw on enter frame to update bitmap1

stage:addEventListener(Event.ENTER_FRAME, function() texture:clear(0xffffff, 0) texture:draw(someSpriteToRender) --and contents of bitmap1 gets updated autoamtically end)

StretchBlt would probably be possible to achieve by modifying texture container (in this case bitmap1) to scale it to fit specific width

zoolax

I understand how to use render to texture in 3d game play,for example rendering a scene to a surveillance monitor.
How do you use it in a 2d game?Any 2d game example that you can mention?
I tried google it and nothing came up as a good example?
Thanks