It looks like you're new here. If you want to get involved, click one of these buttons!
-- Demonstrating some basic helper functions to make Gideros behave like ... a certain other LUA based SDK! local myBall = displayImage.new("ball.png") -- we add a new image, without specifying a group or anything... --so by default, it's added to the stage. myBall:setPosition(75,50) -- so now you can use any of the default Sprite commands to manipulate your image local ballGroup = displayGroup.new() -- now we define a new display group to hold our sprites/textures. -- when you define a group, it is assumed that you WANT to immediately add it to the stage. So, by default, you need add no other parameters. ballGroup:addChild(myBall) -- adds your image to a group. Because the group is already displayed by default, our image is displayed. -- for good measure, I've also made 'addChild' interchangeable with 'insert'! So either will work... ballGroup:insert(myBall) -- adds your image to a group. -- now lets do it a slightly different way, that's more like how you tend to work in ... the other SDK: local obstacleGroup = displayGroup.new(false) -- we define a new display group (but this time add 'false' so that it is -- explicitly NOT added to the stage until we want to... this is just to demonstrate that I've added that option!) local myObstacle = displayImage.new("box.png", obstacleGroup) -- define our image, but, this time, tell it what its parent group is right in the command. stage:insert(obstacleGroup) -- since I've made insert for 'stage' ALSO interchangeable with 'addchild', we can now display the group at will, -- and our sprite will be displayed, since it's a member of this group myObstacle:setPosition(150,250) -- now lets do some physics! -- the necessary stuff: require "box2d" b2.setScale(10) myworld = b2.World.new(0, 9.8, true) -- set up a world... local debugDraw = b2.DebugDraw.new() -- set up debug, if you like... myworld:setDebugDraw(debugDraw) stage:addChild(debugDraw) -- 'physicsAddBody' syntax: -- physicsAddBody(physicsWorld, displayObject, {physicsParameters}) -- NOTE: because Gideros can handle multiple physics world, as well as passing in the object to add physics to, you need to pass in -- the world for which you wish to add it. This is the very first, and mandatory, parameter to pass in. -- the second mandatory parameter is the object you want to attach the body to, as set up using displayImage.new. -- The rest of the parameters, like ... the other SDK ... are the physics parameters themselves, as an array. This allows for parameters to be optional, -- and if not supplied, a 'sensible default' is substituted. -- you can do this... physicsAddBody(myworld, myBall, {type = "dynamic", density = 1.0, friction = 0.3, bounce = 0.9, radius = 40}) -- create a physical, dynamic circle for our ball. physicsAddBody(myworld, myObstacle, {type = "static", density = 1.0, friction = 0.3, bounce = 0.2}) -- create a static square for our box. note that I don't even supply a size. By default it uses the image width and height. -- or, of course, this, if its easier... --myParameters = {type = "static", density = 1.0, friction = 0.3, bounce = 0.2} --physicsAddBody(myworld, myObstacle, myParameters) -- 'physicsAddBody' parameters: -- These are all optional, and defaults are supplied if you don't explicitly define their values: -- type. One of "dynamic", "kinetic" or "static". If not supplied, is assumed to be dynamic. -- width. The default is the width of the texture of the object you're defining a physics body for, but can be overridden, in which case, the object is positioned centred over the sprite -- height. The default is the height of the texture of the object you're defining a physics body for, but can be overridden, in which case, the object is positioned centred over the sprite -- radius. If supplied, the physics shape will be defined as a circle, rather than a box. radius OVERRIDES, and therefore ignores, width and height. -- density. If not supplied, defaults to 1.0 -- friction. If not supplied, defaults to 0.0 -- bounce. ie, restitution, as far as Gideros is concerned. you can actually supply it as either... but don't supply both! ok. if you do, restitution trumps bounce. -- isSensor. true/false. If not supplied, assumed false. -- you can now use the normal physics functions to get or set parameters by referring to object.body or object.fixture --e.g. local sx, sy = myBall.body:getPosition() print ("sx,sy: " .. sx,sy) -- or print (myBall.fixture:isSensor()) -- or --myBall.fixture:setSensor(true) --so, putting it all together, you could do something like: local anotherBallGroup = displayGroup.new() for b = 1, 5 do local myBall = displayImage.new("ball.png", anotherBallGroup) myBall:setPosition(math.random(320),math.random(100)) end for p = 1, anotherBallGroup:getNumChildren() do physicsAddBody(myworld, anotherBallGroup:getChildAt(p), {type = "dynamic", density = 1.0, friction = 0.3, bounce = 0.9, radius = 40}) -- create a physical, dynamic circle for our ball. end -- et voila! 5 dynamic, physical bouncy balls! -- if you're not explicitly naming your objects, remember you can refer to them like: print(anotherBallGroup:getChildAt(4).fixture:isSensor()) -- also, if you want the debug draw on top of your objects, remember to make it the final call to the stage! stage:addChild(debugDraw) -- lastly, you need the enterframe event to update the physics. You need to call 'updatePhysicsObjects' with a parameter of the physics world to update. -- In order to pass in a parameter, the call itself needs to be a function, like so: stage:addEventListener(Event.ENTER_FRAME, function() updatePhysicsObjects(myworld); end) |
Comments
Likes: atilim, bravcm
The major commenting was for my benefit, not to teach you guys to suck eggs.
Cheers
Mike R
Likes: gorkem, MikeHart, atilim
http://www.sharksoupstudios.com
That deserves a twitter post.
So you're a life saver.
cheers,
?:)
Likes: atilim, mykyl66, MikeHart
Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
Cool Vizify Profile at https://www.vizify.com/oz-apps
Mike
http://www.sharksoupstudios.com
- Migration from KVM to VMware
- Migration from Solaris to Red Hat
- Migration from Exchange to Zimbra
- Migration from PC to Mac
In these examples, I cannot fully say "one is superior to another", as it's mostly related to perception management. I cannot also claim that this Lua based framework is better than that framework, but I can WHOLEHEARTEDLY say that we LOVE Gideros Studio :x
But I also got your point.
Gorkem
Mike
http://www.sharksoupstudios.com
How to get it? This was a sample/proof of concept to prove that a 1:1 port for many of the API's can be made, the same can be made but might be at a cost, after all it is time and effort put into creating and testing. So will inform of the costs soon as I figure out when I can get this completed.
cheers,
?:)
Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
Cool Vizify Profile at https://www.vizify.com/oz-apps
This library is purely to help do quick physics concepts within gideros studio.
Basically the beer framework markets itself based on create this game in 8 minutes and another in 30 minutes etc.
The real truth is you can concept a game in that amount of time. In Gideros its not quite so straight forward and these tools are to speed up physics based concepts within Gideros.
I will say it again. The beer framework is perfect for fast concepting of ideas but not so good at giving us the developers total control if and when you hit upon a solid concept.
Mike
Likes: gorkem
http://www.sharksoupstudios.com