Properties you’re adding to tiles aren’t working? Can you file a test case, please, in the GitHub issue tracker? It’s working for me (*sigh*… the most frustrating kind of error).
- Caleb
Yes, I have added physics:enabled property to a certain layer, and physics are working.
But when I added bodyType property to some tiles on that layer, it doesn’t work. I set the body type to static, but it didn’t work. Seems like they still have some sort of “default” body type, or whatever Corona uses when you don’t specify the body type.
Just gimme a minute to sign up to GitHub and take some screenshots to post.
Should I just copy the .lua file of my map and paste it there?
Yes, please - better would be if you have DropBox (or another file sharing system), you can just post the link there.
- Caleb
Issue posted. I have also added the dropbox link to the whole map file.
Let me know if you need anything else.
Can I ask how can you make the camera stick to the player?
In that maze example game, it looks like the player is actually moving (by using setLinearVelocity), and the camera just follows.
There are 2 lines of code that look like they have something to do with the camera:
map.setCameraFocus(player)
map.setTrackingLevel(0.1)
I’m not completely sure what they do.
I have tried to make the camera follow the character in my game, using setCameraFocus and setTrackingLevel.
Seems like the character was only placed in the center of the screen, but the camera won’t follow.
Is there something else that you must do to make the camera stick to player?
Ok, here goes.
map.setCameraFocus() sets the object that the camera will move to follow. You can use this to make the camera follow your player, move the camera to something that just happened (“Look! The door disintegrated!”), whatever.
map.setTrackingLevel() sets the “fluidity” of the camera. That’s the measure of how “smooth” the camera’s tracking is. Try playing around with it in the sample and seeing the result. Higher values (those approaching 1.0) make the camera more rigid and tight, while lower values (approaching 0.0) make the camera slower and more “buttery”.
What you’re looking for is map.updateView(). That tells Dusk to position the camera according to the focus’s position, cull off unneeded tiles, draw new ones - really, the best way to put it is the name of the function: update view. This should be called once every frame (in your game loop). If you look at the Bob sample, you’ll find the updateView() call in the enterFrame listener.
- C
The camera now follows the player, but something wierd has happened- tile bodies have moved. They are not where the tiles are displayed.
The character doesn’t stop where the tiles are. As if physic bodies of the tiles were “offset” from them.
I wonder what’s the problem…
Are you using custom physics shapes? What do you see with physics.setDrawMode(“hybrid”) or physics.setDrawMode(“debug”)?
- C
Hmmm…looks like the physic bodies of tiles move along with the camera.
As the character moves left or right, he’s getting closer to the edge of the screen (the character is not always at the center of the screen, not sure why that is happening either).
The character stops at the point, where physic bodies of tiles are positioned at the screen.
Ahh… Make sure you’re inserting the player into your map.
[lua]
map.layer[“some layer”]:insert(player)
[/lua]
- C
Ok, yeah works great now. Thanks.
Sorry for so many questions. I was checking the Dusk engine docs- index.html and those api, but they don’t seem offer much info for now.
Oh, one more thing…I couldn’t help but to notice that maps have those little gaps between tiles. I saw that in that Bob maze game, as well as in my game.
Why exactly is that happening?
I guess it’s just because Dusk is still in beta, and it’s gonna get handled later.
It’s not a problem to me for now. I have other stuff to add to my game before it’s finished.
But it may be a problem if that would be happening when my game is done.
Sorry about the docs - I’ve got a lot on my plate (a complete rewrite of CBEffects, upkeep for Dusk while it’s in the early phase, plus a few personal projects) 
You can alleviate the tile gaps some by using this:
[lua]
display.setDefault(“minTextureFilter”, “nearest”)
display.setDefault(“magTextureFilter”, “nearest”)
[/lua]
To completely get rid of it, I’d say the only way would be to extrude your tileset sides and have each tile slightly overlap the others.
- C
I’ll try that.
Ok, I couldn’t get the tiles to overlap each other, because of the grid in Tiled.
Here’s the image of how I’ve solved the gaps-between-tiles problem.
It may look like a cheap trick, and it may take some time to finish if you have a lot of tiles, but it gets rid of the gaps completely.
Nice thinking
Side note: You can get tiles to overlap by making the tilewidth of the map 32 (or your normal width), and load your tileset as having 34 width (with an extruded image). Then, you paint with the bigger tiles and it should work.
- C
How does this compare to the Million Tile Engine?
How is the speed compared to the Million Tile Engine?
I’m not sure, as I don’t own MTE.
I’d probably say MTE is faster than Dusk, simply because MTE was written for speed. That said, I’ve done to Dusk close to all I know to optimize things. Dusk, like MTE, has an automatic tile culling algorithm that runs quite fast (though I don’t know the compared speeds).
It would be nice, now that you ask this, for someone who owns MTE to try both of them and let me know about the performance differences. Dusk and MTE might come out about the same right now (now that I think of it), but that’s just speculation from what I know of MTE, so I could easily be wrong.
- C