This might not be what you mean but can’t you flip display objects by giving them a negative scale value?
Yeah, dyson122, I believe negative scale flipping is specifically mentioned in the object:scale API doc. :) Take a look.
Thanks guys! Just goes to show I don’t know everything 
Tile rotation AND flipping is coming in the next update, which should land by the end of next week. I have to be honest, setting up camera constraints proved far more troublesome than I thought it would, but at this point I have the algorithm down and it’s just a matter of implementing it where it needs to be, followed by some days of testing the movement functions for new errors.
Excellent news. Looks like MTE will be out of beta in a jiffy! Good work.
Last week was a slow one for a variety of reasons, but I’m back on track and back to work now. At the moment I’m working on a way to constrain the camera within a specified area in the map. Their are two primary uses for this functionality; preventing the very edge of non-wrapping maps from coming into view (more or less defining a map margin into which the camera won’t go); and creating “areas” on a map in which the camera stays until the area is removed or redefined (for example, focusing on individual rooms in a building, and snapping from room to room when going through doors). You’ll be able to define the camera constraints for individual layers or all layers together, and define whether the layers can move independently of each other to obey the constraints or force them to stay lined up (obey the most constraining constraint).
A prerequisite to this addition is modifying the engine so that all the layers can move independently, effectively having their own cameras. All the movement functions will have this functionality added to them, but they will remain fully compatible with current function calls. Basically every movement function will have a “layer” argument tacked onto the end of their arguments.
These are relatively small changes and additions I’m getting out of the way before starting work on Isometric map support.
Hey Guys,
I’m just starting out. I changed the D-pad graphic, but as you can see in this screenshot, the dropshadow is not semi transparent. It looks normal until I put it in the Corona Simulator. I noticed your Dpad has a transparent outer area - what am i missing? Thanks Guys
Is your new D-pad a jpeg or png? JPEGs don’t support transparency.
It’s a PNG and works normally everywhere else.
That is really strange indeed. Normally I would ask whether it is a PNG with an alpha channel and etc, but if it did not have an alpha channel then the entire square background would be white, not just the area immediately surrounding the shadow.
Can you post the dropshadow image file for us to look at?
Weird indeed. Here’s the file. Exported from fireworks.
Okay, this is actually a hilarious coincidence! The white background is not part of the image, it is coming from the rects DpadUp, DpadDown, DpadLeft, and DpadRight created after loading the Dpad image. In CastleDemo the Dpad image is merely a nonfunctional cover and the white rects are the control inputs.
You can add the following code after creating the rects to hide them while maintaining touch control:
DpadUp.isVisible = false DpadDown.isVisible = false DpadLeft.isVisible = false DpadRight.isVisible = false DpadUp.isHitTestable = true DpadDown.isHitTestable = true DpadLeft.isHitTestable = true DpadRight.isHitTestable = true
So the SETUP D-PAD section should like something like this:
--SETUP D-PAD ------------------------------------------------------------ local controlGroup = display.newGroup() local DpadBack = display.newImageRect(controlGroup, "dpad.png", 200, 200) DpadBack.x = 120 DpadBack.y = display.viewableContentHeight - 120 local DpadUp = display.newRect(controlGroup, DpadBack.x - 37, DpadBack.y - 100, 75, 75) local DpadDown = display.newRect(controlGroup, DpadBack.x - 37, DpadBack.y + 25, 75, 75) local DpadLeft = display.newRect(controlGroup, DpadBack.x - 100, DpadBack.y - 37, 75, 75) local DpadRight = display.newRect(controlGroup, DpadBack.x + 25, DpadBack.y - 37, 75, 75) DpadUp.isVisible = false DpadDown.isVisible = false DpadLeft.isVisible = false DpadRight.isVisible = false DpadUp.isHitTestable = true DpadDown.isHitTestable = true DpadLeft.isHitTestable = true DpadRight.isHitTestable = true DpadBack:toFront()You are awesome sir! thank you!
Anyone know why you would get these black lines on your tiled map when you put it in the game? When I look at my map in Tiled - it doesn’t have the line artifacts, but when I load it in game it does. Weird!
MTE is an amazing Engine thank you for your hard work on it!
Can’t say for sure but those artifacts look to be because:
-
You’re using Corona’s default filtering method
-
You’re not using the workaround for proper tiles while using default filtering
The workaround is tedious (to say the least), so I would generally suggest just getting your project’s filtering to nearest neighbor. It ensures that everything (all of your assets and graphics) are pixel-crisp.
-- Enter this somewhere near the beginning of main.lua display.setDefault( "magTextureFilter", "nearest" ) display.setDefault( "minTextureFilter", "nearest" )
The only downside to this approach is that easing methods apart from the default are going to have gaps, because there is no “inbetween” tiles anymore.
Creating extruded tilesets can be a tedious process, but it is still the safest way to move forwards in that it allows the most flexibility while maintaining proper functioning of the easing methods.
I may be able to provide an option for automatically slightly oversizing tiles to eliminate both the need for extrusion and the irregular appearance of the easing functions with nearest-neighboring filters. I’ll have to look into the code and see if it breaks anything difficult to fix or severely adversely effects the appearance of a map. That’ll be something for when the camera constraints are finished.
Richard9 your solution solved it, thank you very much for that code snippet. I wasn’t aware of Corona’s filtering methods.
Work on the new features is done and I’ve moved on to testing all the changes.
Flips and rotation in Tiled go a long way to simplifying map creation and reducing tileset sizes. For example, why have four tiles for four corners when you can just rotate one single corner tile as needed? Camera constraints are working quite well too. With a single line of code you can lock the camera to an area on the map and move the camera into it with transition easing functionality. You can specify what boundaries the camera should obey; left, top, right, and bottom in any combination.
Progress is on track for a Friday release.
Still looking at a release tomorrow.
This update will include a spiffy new sample project demonstrating rotated tiles, screen constraints, and storyboard integration. The sample is composed of three seperate maps, each of which is broken up into rooms by screen constraints and connected to each other by stair tiles (triggered by Tiled objects).
All three maps were made with just 5 tiles. MTE layer lighting is used to subtly change the color of each map.
This looks amazing. I read all 4 pages of this thread and I was ready to buy around the middle of 2nd page… It keeps getting better and better. Now if only I could get gumroad accept my PayPal… Am I the only one fussy about giving my credit card to yet another storefront??? Any options to buy with PayPal? Thanks
Looking good. I think this is really going to help us out a lot.