It looks like you're new here. If you want to get involved, click one of these buttons!
TileLayer2 = Core.class(Sprite) function TileLayer2:init(name, width, height, texturePack, tilewidth, tileheight, tileMap, physics ) self.layers = {} self.id = name local layer1 = Sprite.new() local layer2 = Sprite.new() self.layers = {layer1, layer2} self.currLayer = layer1 loadTileMap(name, self.layers, texturePack, tileMap, width, height, physics) layer1:setPosition(0, -layer1:getHeight() + screenH) layer2:setPosition(0, screenH) self:addChild(layer1) self:addChild(layer2) end local function loadTileMap(name, layers, texturePack, tileMap, width, height, physics) local blank_tile = Texture.new(getImgBase() .. "blank_tile.png") for y = 0,height - 1 do for x = 0,width - 1 do local gid = tileMap[tonumber(y+1)][tonumber(x+1)] for i = 1,#layers do local tile = {} if gid == 0 then tile = Bitmap.new(blank_tile) else tile = Bitmap.new(texturePack:getTextureRegion("t" .. gid)) local conf = {type="kinematic", width=10, height=10} if physics then if physics.isSensor then conf.isSensor = physics.isSensor end if physics.type then conf.type = physics.type end physics.parent:createRectangle(tile, conf) --tile.body.id = name .. "-t" .. gid end end tile:setAnchorPoint(0.5,0.5) tile:setPosition((x+0.5) * tile:getWidth(), (y+0.5) * tile:getHeight()) layers[i]:addChild(tile) end end end end |
Comments
Also, there is no hierarchy of physics bodies: bodies do not have children (except that they can have multiple fixtures, but these must be fixed relative to each other)
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
In reality it all happens like this:
http://appcodingeasy.com/Gideros-Mobile/Gideros-Box2D-basics
But since you are using Box2DEasy, they should have been updated. I think there reason here might be that box2d body positions are absolute, while Sprite child positions are relative to the layer.
The fix would be, in the same code, where you applied your fix from previous post, to use sprites global coordinates, like this:
As I'm now my ears deep in something else, I can't really try it, but will experiment more with GCE and B2DE when will have more time
Cheers
Have you had some time to look into this? You were right about the cause, but I'm at a loss as to how to fix it, all the stuff I've tried keep messing things up.
I'm also trying to avoid breaking functionality within the GiderosCodingEasy library due to naive modifications
Still I will try to find some time to check it out. And if you want, you can help by preparing a small Gideros project that demonstrates the flaw and attaching to this thread.
This is the simplest demo I could come up with. At it's bare essence, I manually create a Tile Map using a two directional array and lots of individual sprites, all contained in a parent sprite (the TiledLayer class). Some of the layers need to be able to interact with the player and NPCs, so I added physics properties to them.
At initialization, I update the layer position at line 53, TiledLayer2.lua and this works normally. However, the attached physics bodies are not updated relative to their parent sprite.
You can try to comment the line to see the tiles properly aligned to their respective parents.
Hope this helps to lead to a resolution.
You see Box2DEasy is defined to take bodies position, and change sprites position to match bodies. Since bodies position is always in global coordinate, but sprites can have offsets, because of layers and local coordinates, there can be problems. But actually those problems would be quite easy to fix.
On the other hand what you have is something completely different. You move layers, thus sprites move, changing their global coordinates, while local stays the same. And then what you need is to take sprites global coordinates, and match bodies coordinates to them. Which is completely reverse process and would probably break any underlying physics simulations.
Now what you want to achieve is probably not impossible, but needs another approach.
So can you elaborate a little more, what do you use physics for, so I could try suggest a better approach? Like is it needed only for collisions, or you will also be emulation physics and gravity, etc.
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
For example, it might be possible to implement additional option when creating body, with which it would be possible to specify weather sprite should follow body, or body should follow sprite.
But again that won't cover all the cases, and in some misuse might break the whole physics emulation, thus I wanted to see what exactly @bayop is up to
The reason why I implemented the tiled layer as seen in the attached sample is because we are attempting to port the app from a different platform (J2ME) and we are trying to re-use the existing assets and algorithms.
I guess my question would then be... How should can we implement an endless scroller (with updating background positions) and also include physics? I know it's possible I guess I just may not be using the best approach.
Here's a short clip of the game in play
I agree with your comment on Box2DEasy being an easy system, I am a Gideros newbie albeit with some game development experience. I have read through a tutorial on the C++ library, and some of the samples using Gideros' vanilla box2d implementation and there were a few things I felt were missing which I felt B2DE would help fix such as anchorPoints on sprites, verbose code for setting up physics bodies etc.
Right now there's no guarantee that switching to the plain unmodified version will solve this issue, but I'm open to suggestions.
I reverted to the vanilla box2d implementation and the issues persist (I suspected it would). I believe there must be a straight forward way around this cos I've applied this approach with Corona and it worked.
I will try a little experiment tomorrow and try to provide you with a possible solution
the background scrolls at the rate of the speed your bus is going at,
the other vehicles scroll at their own speed
the collisions are simply a function to check two overlapping rectangles
even if you want to implement friction in your code, to simulate gradual slowing or speeding up, try multiplying or dividing the speed by 0.9 (adjust accordingly)
This is just advice, I am sure you love and want to use Physics; knock yourself out but if you want something simple and that works avoid all the fancy stuff.
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
I understand what you mean about us not absolutely needing physics for this game. However, during the time I was developing the J2ME implementation, a lot of time was wasted trying to get the vehicle collisions to work right i.e. rebound properly after a collision, not having two items perpetually stuck together; that kind of stuff. I really felt that moving to a box2d implementation would save us some time in implementation, but I guess that I might have been wrong.
@ar2rsawseen
I do appreciate all you help and will look forward to a possible work around. You are partially right about the game though, I was planning to use velocities (and forces), but yes there will be no need for gravity in the game.
I must say though that I am overwhelmed by the responsiveness of the community and very impressed by what Gideros has to offer. Hopefully, I'll be getting the hang of it sooner riather than later...
In Gideros, remember, there is a separation between sprites and physics bodies allowing you to do the trick just described. Corona does not allow this making scrolling physics games "difficult".
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
That's what I'm doing for the car sprites; their positions are based on the position of the player car.
The problem is that my tiled map implementation (composed of many sprites, some of which have physics bodies attached ) has to be updated as the game screen scrolls so that the player never runs out of background, so I have to call setPosition() on my TiledLayer to reposition it just as it is about to be exhausted. I'm not calling body:setPosition() for car placements.
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
What he tries to tell you, that you should not move the tilemap layer yourself, but rather let box2d body move it.
It might be tricky to add new layers, but it should work.
I'll try to implement something similar now