It's a PNG and works normally everywhere else.
Jump to content
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?
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()
Can't say for sure but those artifacts look to be because:
1. You're using Corona's default filtering method
2. 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.
I've added flipped and rotated tiles to the list of features I would like to add. I'm talking about tiles which have been flipped or rotated from within Tiled itself and stored that way in the tile map. It'll be some time before I get around to working on these.
Work continues on map constraints. Implementing them has proven more difficult than I thought, so the update will probably land sometime next week instead of this one. It seems two weeks always become three for me. In the future I'll probably stick with a minimum of three weeks between updates.
We just bought MTE for use in one of our games. It looked excellent and much more efficient than writing our own. Unfortunately we've discovered it doesn't support flipping or rotation of tiles which means we need to duplicated rotated or flipped tiles in the tile set itself.
We've been told it's coming but it may be several weeks away. Just wanted to let people know in case it affects them as we couldn't find reference to it being included/excluded until it was too late.
Seems great other than that :-).
Dyson, please let us know when you have more info. Thanks!
I looked into it. I'm happy to say that tile rotation will be included in the next update. This was made possible by the excellent BinDecHex lua library by Time Kelly of Dialectronics. You can see it here: http://www.dialectronics.com/Lua/
Future releases of MTE will include BinDecHex, unmodified, as a seperate lua file alongside MTE. I believe this is legal to do, but if I'm wrong someone please let me know so we can work the problem out.
Tile rotation must be enabled before the map loads. This is done by calling mte.enableTileRotation(true). The performance impact is limited to map loading and will depend on how heavily you use rotated tiles. The in-game performance, so to speak, should be unaffected by the presence of rotated tiles, however the memory load will be increased by some degree again depending on how heavily you use rotated tiles.
Tile flips are impossible. The Corona SDK graphics API does not support image flips, only rotation. Corona Labs' Graphics 2.0 release will probably fix this in the coming months, but it is out of my control.
Tile rotation AND flipping is coming in the next update! Thanks nick_sherman and richard9 (below) for clueing me in!
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.
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
MTE v0.820 - http://gum.co/staO
Another three weeks, another new update! MTE 0.8 focused on platforming and sidescrolling mechanics. MTE 0.820 returns to it's RPG roots, bringing a number of useful new features:
Camera Constraints: define areas within which the camera and view must remain. Subdivide maps into distinct areas, break up rooms inside of a building, or just lock the camera to the map. This new feature will add new flexibility to RPG projects.
Tile Flip and Rotation: the Tiled map editor allows you to flip and rotate tiles before placing them in the map, and MTE now supports this functionality! It is no longer necessary to duplicate the same tile image facing four different directions in your tilesets. Just use one and rotate as needed!
A New Sample Project: RotateConstrainStoryboard. The sample lives up to its namesake by demonstrating tile rotation, camera constraints, and storyboard integration all in the same project. Tile rotation allowed for the use of an incredibly tiny tileset: just 2 x 3 tiles, only 5 of which were used! I've set up camera constraints to create the impression of distinct rooms inside of a building. The camera locks to one room at a time before moving to the next when the player hits a Tiled Object trigger. Storyboard integration takes the hassle out of switching from one map to another and another.
With this update out of the way I'll be moving on to one of the two huge new features coming to the Million Tile Engine: Isometric maps. I expect this feature to take between one and two months to implement, at which point MTE will reach version 0.9 and I'll move on to the final major update in the pipeline: physics integration.
Community Forum Software by IP.Board