Extending Gideros

gorkem

+1 for GiderosCodingEasy

paulocarrasco

+1 also for GiderosCodingEasy :-)

bowerandy

Ok Updated repo,
It now rotates almost around Anchor points

I always used to say that there are only three numbers in computing: Zero, One and Infinity. Now I'll have to consider changing that to: Zero, One, Infinity and Almost.

@-)

Mells

@bowerandy I'm a beginner, "Almost" has always been the best that I can get

ar2rsawseen

I always used to say that there are only three numbers in computing: Zero, One and Infinity. Now I'll have to consider changing that to: Zero, One, Infinity and Almost.

@-)

) sorry but it's all related to the limited time I have now. But I appreciate you all comment, helping, testing and providing fixes. I'll continue once I'll have more time and get an answer from @atilim about one box2d issue. Till now feel free to join in, fork, modify, commit, test and any other tasks listed in the first post

bowerandy

@ar2rsawseen, I think there is a problem with Shape:clear(). Just try:

local canvas=Shape.new() canvas:clear()

with the GiderosCodingEasy library loaded. I get:

init.lua:30: bad argument #1 to '?' (Shape expected, got nil)

Not sure I can figure out why.

I must say I think this chaining stuff is a bit tricky and have to ask if it's really worth it. Why don't we ask @atilim to make these methods return self in the next version- I'm sure it wouldn't take him that long to do? ]

best regards

ar2rsawseen

@bowerandy fixed shape clearing.

Well actually one of the purpose of this library could be, that if many of us would agree that one of the features is so good and many of us will use it, it could be kind of a way to set direction for @giderosteam and hint them to implement it natively.

bowerandy

@ar2rsawseen, thanks for the fix. I don't know why I couldn't spot that.

The problem with this sort of library code is that it will get to appear absolutely everywhere, in everything. So, if it is fluid and subject to change, that's a lot of places that will have to be updated in future if something changes. This might be a barrier to adoption.

There is stuff in this library which, IMO, is totally essential and I'm really grateful that someone (i.e. you) could be bothered to put it together. Things like, easy physics, arcs, anchor points etc. Theres other stuff, which (as you know) I don't like much. Things like chaining, position and colour naming can tend to obsfucate the code. It would be useful if this library was crowd-sourced so you don't have to maintain it but currently there is quite a lot of tricky stuff in there that might frighten others off. Witness the fact that I couldn't spot that clear() fix even after spending an hour looking at it!

I don't know what to do about this; I haven't really got a solution, I'm just voicing a concern. Maybe it's not a problem and just me. And I know you're busy right now so don't worry about this until you've got more time, if at all.

best regards

ar2rsawseen

Could proper comments and documentation fix it?

I also thought about an option to list dependencies of methods for each other, if someone would want to remove part of "in their opinion" unnecessary code.

I'm willing to do it because I would be very happy if it was crowd-sourced and would want to motivate others by doing that.

So there two ways, one way optimization for smaller code, like I'm trying to do now, but it means that a lot of methods will depend on other's etc and it can get very complicated.

On the other hand you can create implementation for each thing in separate method, which would make project more maintainable, but probably with less performance, as there will be a virtual function for every thing implemented that could pile up in a huge overhead.

Deciding on which feature is important and which also probably be a pain, because as usually there are so many opinions on what is important

bowerandy

@ar2rsawseen, my daughter is watching "Cloudy with a chance of meatballs"; what an awful film, so I've a got a moment to chime in with a few more ideas. Use or disregard, as you see fit, when you see fit.

Ok, let's take colour names ("BLUE", "PERU") and position names ("center", bottom"). I don't generally like ideas where one type of object is used to represent another completely different concept. In my experience these things tend to causes problems down the line and lead to "type checking code" which is generally a "Bad Thing". Could we use function names to return the correct object types instead? For example:

function bottom() return application:getContentHeight() end   -- then we can created readable code using no more characters than "bottom" myObject:setY(bottom())   -- the code is useable everywhere, without nasty type checking MyOwnBox.new(left(), top(), right(), bottom())   -- it's also possible to use in comparisons and other places if y>bottom() then end

Similarly with colours:

function color(name) return Colors[name] end   -- Okay this is a bit more typing but still readable application:setBackgroundColor(color("PERU"))

Just another 2p

best regards

ar2rsawseen

Hmm, well yes, same way as @asakharov mentioned, we could also use constants.

As:

application:setBackgroundColor(Colors.PERU)

And experienced Gideros developers as you and me could live with that. But there is also another point of helping new developers to easily get their hands dirty.

And maybe I'm exaggerating (I usually am, so if it the case please tell me ), but I'm afraid that this kind of method/constant approach would simply end as an unintuitive framework API implementation in somebodies review about Gideros.

But I completely agree with you @bowerandy and I was concerned about the points you are raising, myself.

Would really wish if more Gideros developers would express their opinions so would could go with democracy.

bowerandy

Could proper comments and documentation fix it?

I also thought about an option to list dependencies of methods for each other, if someone would want to remove part of "in their opinion" unnecessary code.

That's one way. Another might be to split the init into two pieces/files.

1) The first would contain extensions to the system Theses are things that are added but don't change the underlying methods and classes. These would be "take it or leave it", and would include additions to physics, shapes, splines etc. Because, these are additions, they don't need to be added by @teamgideros in future, they can continue to be required where necessary. Because this isn't "tricky" stuff it may not need to go into init.lua at all - just add "gideroseasy.lua" to a project.

2) The second would involve changes to the core Gideros classes. This file would include tricky meta-fixes to the existing system that involve overriding existing methods. We could hope that @teamgideros would eventually absorb such fixes into the core system. This would include things like chaining, string colour and position names etc. This stuff would need to go in, or be called from, init.lua.

Interestingly, the actual addMethodOverride() function (I forget the exact name now) would go in 1) but any use of it would go in 2).

Back to colours and positions. Yes, I don't know what the right mix of readability, ease of use and correctness is. My approach pollutes the global namespace, the string approach isn't general enough (because "top" isn't really an integer throughout the system). This would need to be voted on by the community, as you say.

Thinking about it, my top(), bottom() idea might as well be replaced by global constants, TOP, BOTTOM, set up at init time; the global namespace pollution would be the same.

best regards

bowerandy

@ar2rsawseen, I've made a modification to add "isSensor" as part of the config for fixtures. I've attached the patch (diff) file below.

I also noticed that "restitution" is spelt incorrectly in a number of places (resitution). I wasn't sure if this was to maintain compatibility with something else or whether it's just a typo.

best regards

ar2rsawseen

Wow thanks @bowerandy, I'm really glad that someone else is also involved in this
I've added your fix and restitution was a typo which was copied all over the code, thanks for spotting that

I think that whole physics code can get shorter by creating helping generic function to create body, etc.

Additionally what else would need abstraction for physics, at least what I plan to work on someday, would be for creating joints (at least for couple popular of them as weld and revolute) and also an abstraction for collision filtering. Any other ideas/suggestions?

bowerandy

Hi @ar2rsawseen, I don't know much about physics (at least the box2d type) but I was just using your library in some demo code, where it was very helpful. So I'm afraid I'm not really the one to offer ideas for improvements in that area just yet.

I did notice, though, that there's no way to get back to a fixture from the sprite/body. Are there situations where one might want to do that?

best regards

ar2rsawseen

Hmm, maybe only when you want to destroy the fixture to recreate the body with different shapes or properties, but keeping all the current trajectory and velocity of body as here:

http://appcodingeasy.com/Gideros-Mobile/Gideros--Creating-and-breaking-complex-shape

So yes it is a good point and it is possible to save reference to texture and return it if needed. Thank you!

paul_k_clark

@ar2rsawseen I prefer the constant approach for colors. Constants (Color.YELLOW) keeps all of the color functionality in the one area and being constants they don't really warrant a method call.

paul_k_clark

@ar2rsawseen how about a method to add to the back in sprite. Something like below (which is untested, no Gideros at work )

function Sprite:addChildAtBack(child) local parent = self:getParent() if parent then parent:addChildAt(child, 0) end return self end

atilim

@paul_k_clark, but the addChildAt should be

parent:addChildAt(child, 1) -- not 0 but 1

more info here: http://giderosmobile.com/forum/discussion/1638/important-addchildat-function-is-changed-at-2012.08.2

paul_k_clark

@Atilim sorry I work in the Java world where all arrays start at 0 Thanks for the correction.

paul_k_clark

@Atilim, @ars2rsawseen Actually in that case the Sprite:sendToBack function should be 1 for addChildAt instead of 0 (just noticed)

ar2rsawseen

Thank you @paul_k_clark I simply copied the code from the forum, which was written before this issue was discovered, I'll update it as soon as I can

ar2rsawseen

Updated repo
Added fix @paul_k_clark stated
Added method @paul_k_clark provided
Added some helping functions with calculating Vectors

ar2rsawseen

@bowerandy I've checked the almost around center rotation of text, and it seems that baseline fix have something to do with it, because for example shapes or sprites rotate normally around center, just not TextField.

I will try to look further into it.

BTW discovered interesting effect, that this anchorpoint method allows also negative anchor points, well actually any value anchorpoints even out of object bounds. For now I don't think it's bad, but the opposite, its a bonus

Scouser

I thought it might be useful to add something like

Application.__exit = Application.exit   function Application:exit() if os == "Android" then self:__exit() end end

here as the API documentation says

Although this function is available to all platforms, it should be used on Android only.

ar2rsawseen

Nice one @Scouser will add it, thanks

moopf

Hi @ar2rsawseen, giving this library a go (looks good). Just one thing I'm finding at the moment, you're providing a version of GTween that should resolve anchor point issues, when used in conjunction with the setAnchorPoint additions (in my instance, for a sprite). It doesn't seem to be working when you try to scale and actually just doing setScale shows the same thing - it's scaling from the standard 0,0 anchor point. Any ideas?

ar2rsawseen

@moopf oh you are right, I should have updated anchor offsets also on scaling, let me check that.

and by the way, GTween is only provided for testing, it should not be dependent on version of GTWeen you use

ar2rsawseen

updated repo with fix for scaling

moopf

@ar2rsawseen didn't realise it was the same version of GTween, hadn't checked it in detail, just read the description for the file on Github.