Thanks for confirming that Caleb 
I just started playing around with Dusk, and tried to build a map from tiled with an isometric orientation. Does dusk not support this? As I can not seem to get it to work…
First… I’m sorry. This same thing has been asked and aswered again and again, but I’m still stuck with this 
I’m using Tiled and Dusk. I can add physics to objects, but not for layers (tried tiled layers and object layers). Here is a screenshot what I’ve tried. Please, check to layer properties. “tiles” layer shoud be the collision/platform layer. I’ve set physics.setDrawMode(“debug”) and as you can see, the layer has no physics at all. I tried to declare bodytype using tiles-prefix and without it.
Thanks in advance!
[sharedmedia=core:attachments:3480]
Unfortunately, Dusk does not support isometric maps right now. Sorry :(.
@Aatos Media:
Sorry about that; fixed.
- Caleb
Hi Caleb,
I’m loading a map from tiled using your engine. All runs fine, what I don’t know is how to reload the map to start the player from the start position. I do a map.destroy() and recreate the map, but physics is not recreated. Do you know what could be happening?
Why does starting the player over require you to completely destroy the map and rebuild it? Couldn’t you just do this:
player.x, player.y = map.layer["tiles"].tilesToPixels(startPointX, startPointY) map.snapCamera() -- No camera movement back
If you can’t, what do you mean by “physics is not recreated”?
- Caleb
What options there is to detect if character is on tile (ground)?
Add a number property to your player to store the number of floor surfaces the player is currently touching. Each time you hit the floor, add one to the number, and when you stop hitting that floor element, subtract from it. You can then know if the player is grounded by checking if that number is over 0. (It has to be a number because if you use a Boolean and move horizontally from one floor to another, it registers as not grounded.)
As for the actual colliding itself…
With Box2D Physics
-
Add a separate body element to each floor tile via tile properties (physics2:), make it a sensor, and check the body element on collision - for this, best to offset the body by 1-2 px vertically so you can be sure of a collision
-
Add a separate body element to the player and check the body element of that
-
Check for if the tile is beneath the player on collision
Without Box2D Physics
-
Varies from system to system. It’s not very hard to do, though.
-
Caleb
Thanks Caleb!
Could you please give a basic example how this “ground thing” is done with custom physics.
If you’re not using Box2D, you won’t even need a ground counter, because you check for if the player’s grounded each frame. I went with the “Sonic approach” as detailed in the Sonic physics guide, so each frame, I cast a line (two, actually) down from the player and see if it collides with any tiles which have a top solid property. Here’s a pseudo-Lua example of how I handled it:
function player.onEachFrame() local leftTile, rightTile -- Store the left and right tiles we're colliding with -- Check for left side collision do local tiles = getTilesOverlappedByLine(player.leftSide, player.y, player.leftSide, player.bottomSide + 2) for i = 1, #tiles do if tiles[i].solid.top and player.bottomSide \<= tiles[i].topSide then leftTile = tiles[i] break end end end -- Check for right side collision do local tiles = getTilesOverlappedByLine(player.rightSide, player.y, player.rightSide, player.bottomSide + 2) for i = 1, #tiles do if tiles[i].solid.top and player.bottomSide \<= tiles[i].topSide then rightTile = tiles[i] break end end end -- Find the highest tile local collisionTile = leftTile or rightTile if leftTile and rightTile then if rightTile.y \< leftTile.y then collisionTile = rightTile end end -- Are we even colliding with a tile? if collisionTile then player.y = collisionTile.topSide - player.width \* 0.5 -- Position player on top of tile player.yVel = 0 -- Turn off player's Y-movement player.isGrounded = true -- Player is grounded else player.isGrounded = false end end
Of course, this example only does ground collision. To do the rest of collision, it’s not so hard to expand this in each direction the player’s going. Once you get that working, and you check for ‘solid.top’, ‘solid.left’, ‘solid.right’, and ‘solid.bottom’ on a tile, you can then just add a property ‘solid’ equal to ‘!tags! left, top, right, bottom’ in Tiled, and you’ll be able to solidify your tiles really easily. (Not sure if it’s documented, but Dusk’s ‘!tags!’ prefix creates a table with each comma-separated-value equal to ‘true’.)
The point is, with home-made physics, you have access to the player’s collision state every frame (in fact, you have to have access to it to make gravity work correctly), so you won’t need to keep a counter. You can just query the current state.
- Caleb
I don’t know if this is related to dusk… but when moving a character (Retro style pixel look) over the screen by adding x=x+1 and y=y+1 and make the camera following the character things look very good, sharp and the movement is steady.
BUT when the character is moved with x=x+0.5 and y=y+0.5 or other point values for example the camera movement begins to move in small steps (stair effect) which can be irritating on the eye. The character sprite then also is not sharp anymore but blurry which is looking wrong.
Any ideas on how this can be optimized, fixed?
Any help welcome!
I was waiting for something like that to happen. That’s a consequence of camera rounding. When I added camera rounding, that made Dusk’s camera system able to move at minimum in single-pixel increments. It was the fractional pixels that were the main problem with tile flickering, but now when you need fractional pixels, you don’t get them :P.
Fractional pixels cause a lot of problems if you don’t have access over rendering. IMO, you should stick with full pixel movement. Your character is looking blurry because of fractional pixels. The tile lines were occurring (majorly) because of fractional pixels. If you need smaller movement increments, you can scale your stage down and your graphics up (retro/pixel graphics are easy to scale) so that what was previously a 0.5px movement can be a 1px movement.
Of course, you could also modify Dusk to stop rounding camera positions, but that would bring flickering tile lines back. Every action has an equal and opposite reaction :P.
- Caleb
Thx for your fast feedback Caleb!
Because I’m working with bigger tiles the flickering lines shouldn’t be a problem. So I think stopping the rounding camera positions should be the best option here.
Can you please give some tips on how to do the modifications to stop the camera rounding please?
Daniela
UPDATE: I totally forgot the change was so easy… … I found the line to change and turned off the rounding. The line was:
dusk.setPreference("experimental:roundCameraPosition", true)That’s correct for versions prior to the one on GitHub, but if you get the most recent one and can’t figure it out, that’s because I made camera rounding always happen. All you need to do in that case is find lines 95-96 of Dusk/dusk_core/run/camera.lua and take out the math_round() call.
- Caleb
Ah… okay. Thx for the info!
–======================================
–Open World / Multiplayer / Zombie survival game
–======================================
local YouAreHuman = true
If YouAreHuman == true then
print(“I will tell others of your game”)
end
Hey guys. I want to show you guys this for support and so that people can see one of the several ways Dusk can be used. It’s the open world/multiplayer/zombie survival game I’ve created. If you like it please feel free to share it with others so I can make it come true.
Hey Caleb!
Are you giving all of this support in your own spare time? Respect man!
One more thing: I noticed a small latency in tiles and objects when the camera is moving… means not each object is moved with the same speed. For example: when the ground is moving, objects set on top (or even in the same layer) are sometimes a little bit faster or slower when everything is moving. I mean NOT constantly and I guess it is the “old” rounding problem which is the cause. I now wonder how this is happening and what I can do to move everything with the same speed. For example: When a tree is put on a grass tiled ground and the world is moving (camera) the tree sometimes is moved a little bit faster or slower. I guess it’s because the rounding is turned off now… but aren’t the groups (with all tiles and objects) are moved as a whole? Shouldn’t this be smooth then? Is there a way to fix objects with the map 100%, so they move even and steady. Maybe some changes to the camera?
Thx for all ideas and help!
UPDATE: How exactly is the map.setTrackingLevel working? I had a value of 0.05… maybe this is somehow the reason!? Working with a value of 1 “fixes” the problem, but then the camera is stopping without delay. But having some delayed camera stop feels better. Is there a way to have both… no flickering object-map with some camera easing?
Sounds weird. The cause wouldn’t be rounding, because the camera just moves each group. And you say you have all your objects in the same layer (or layers with the same parallax ratio)? If you’re moving your ground directly and you’re trusting to Dusk’s camera system to move everything else, you should make sure you don’t have a tracking level set (use map.setTrackingLevel(1)). If that doesn’t help, can you record a screencast of what you’re seeing?
- Caleb
Thx for the fast feedback. Here is what I have figured out so far and what I’m using right now:
I have a map with grass (layer tiles) and an object layer with the character and trees.
I have a TrackingLevel of 0.05.
The character is moved by adding 1px to it’s x and (or) y value or diagonal 0.75px.
I have turned off the rounding.
When the character is moving there is a small “flicker” between objects and ground and even between different objects and the character. The flicker also is there when the character is stopped and the camera is still moving (because of its small Tracking value… with a TrackingValue of 1 the flicker disappears). The flicker first stops when the camera stopped moving 100%
I tested all the settings and when turning on the rounding the flicker seems to disappear (but not 100% - tested in Simulator only). But then there is the blurry character sprite when the character is moved less then 1px … like for example only 0.75px.
So this is how I use it right now: I check if the character is moving then turning off the rounding. When the character is stopping I turn on the rounding, so the last camera movement is smooth. This way everything looks okay. There still is a difference between objects and the rest of the map while the character is moving but it’s better than a blurry character and because everything is moving it’s not so much of a problem.