thanks for clarifying! I see you are using a virtual gamepad in the engine, do you also think about moving by touch? like a pathfinding to the point you clicked (or attack an enemy you clicked)?
The gamepad is not integral to the engine, but rather one of the things set up in the user code for the sample projects. Clicking a direction basically calculates the destination tile and calls a moveSpriteTo with the location of the tile as the destination. In this case I go with the gamepad because most of the examples have been about other functionality, like storyboard, or platforming movement, rather than about the input itself.
Touch movement would be pretty simple, depending on whether you wanted to do pathfinding or not. An mte.convert call in a touch listener would give you the map location of the touch. You could move the sprite directly to that location, or you could run the locations through your pathfinding code. From there things get tricky with the current MTE version because you’d have to set up code to iterate through the waypoints generated by your pathfinding code.
The plan, as it currently stands, is to modify moveSpriteTo so that it will accept a “path” parameter. From there it would move the sprite from start to finish, through the waypoints, automatically. And, as I said before, I’ll probably add Jumper or come up with another pathfinder function for MTE.
What I’ve been doing this week is working on suitable painter’s algorithms for isometric maps. You saw part of that in the previous video; the player sprite appeared in front of the stone pillars while walking in front of them and behind the stone pillars when walking behind them. That was not a trick of split tiles and layers; those pillars and wall pieces are single, tall tiles, they are not broken up messily into top and bottom pieces. I’ve fleshed it out and added a second optional algorithm useful when you have many different terrain levels you’d like to move between. Think of the worlds of such Dwarf Fortress clones as Towns, which are composed of isometric blocks. I’ll have a video of this ready tomorrow.
Hi dyson,
I’ve been trying out something that might sound a little crazy that appears to work on the phone but not in the simulator. I guess it’s therefore a simulator issue but I thought you might have a view on this and it might be of general interest to you anyway.
I wanted to test using an entire large picture rather than tiles repeated. I know I could load this as a single image using Lua and move it around but I wanted the benefit of tiles as well. I’ve also considered having it as an image background and tiling over it somehow (not sure on how I’d do that yet). So my first route is to use Tiled to split it down and your engine to take advantage of the performance in culling and all it’s great functionality.
The image loaded into Tiled was 5184 x 6400 pixels and split into 32 x 32 tiles. Hence 162 x 200 tiles and therefore around 32,000 tiles (crazy eh?). The image is jpg at about 1.7mb.
So I got it running in the simulator, I can see my buttons to move it around and an animated sprite character on the screen that moves fine. One button’s image has gone very strange (graphics overwritten) so I suspect an odd memory issue here (not my machine, that’s got 16gb with loads of spare free mem). The stats you setup in MTE only show about 2.7mb being used on the simulator, it also only shows 234 tiles on the stats.
The main issue is that there’s no tiles showing, it’s all black. It’s like it’s not actually showing the tiles at all hence the low memory being shown. However, running it on my phone it works perfectly. I could live with that but it’s hard to develop without the simulator showing what’s on screen.
Any ideas?
Thanks
Hey Dyson I’m intrigued by why you’re saying pathfinding is tricky in the current iteration of MTE - I managed to get AI bots walking in a patrol state, and searching for the player using raycasting (i.e a stealth game) then switching to a chase state pretty quickly and without much fuss. It was based on an A* algorithm from MobileTuts and a FSM implementation - essentially the AI bot class had a destinationReached method that checked whether the bot was at its target destination and if so to increment to the next location stored in a path array.
More then happy to share ideas if people need it as that project is currently on hold (sniff)…
Did some more testing using the exact same image on this and found that it’s due to some sort of limitations. When I reduced the number of tiles to 128x128 at 32x32 pixels per tile it worked, anything more than that it’s a black screen and odd looking images (like desktop menu’s) appearing on the buttons.
I could double the number of tiles to 256x256 if I reduced the tile sizes to 16x16. It’s not linked to the image disk size as I tried it at various levels of compression from 1.7mb to 11mb in size and all worked fine t 128x128.
The only constant constraint seems to be that the image can’t be more than 4096x4096 pixels when cut into tiles.
Hi SegaBoy,
If you have any examples or code snippets you could post that would help out with using A* and the features you mentioned I know I could use some real examples. I am new to pathfinding and mobile gaming in general so a lot of this is new to me. Just wanted to throw that out there as others may also be in the same position! 
Thanks and nice work!
Hopefully I’ll have some time over the weekend to prepare some code - I don’t want to supply everything as it’s a project I’m still going to work on in my own time. However I do see lots of people ask about these kinds of features, so more then happy to help - however be warned, I’m not the type of person that just gives code as I don’t believe that ever really helps people in the longterm
Also Dyson I may be going against the grain here however I don’t think it’s your responsibility to add features to MTE that developers can implement themselves. Sure make things more achievable, but adding pathfinding capabilities when it’s already possible seems a little redundant to me. I’d much rather you worked on features that are someway beyond our control.
On a different topic, I’ve noticed that when zoomed out, even on smallish maps 50x50 for instance) if you swipe the screen to drag the map over the image freezes momentarily and then jumps to the new location. If you take the same action when zoomed in it’s not noticeable. If you swipe slowly it’s fine, if you swipe at a reasonable level it’s a bit stuttery. It happens whether you lift your finger off or keep it touching. lifting off gives a worse result.
I’ve pinned it down to the moveCamera function and this behaviour existed in the previous version as well. I imagine the moveCamera function is doing an awful lot when zoomed out so it’s hardly surprising. My only fear is the complaints from users who don’t appreciate the complexity of the operation when moving large numbers of tiles (that just appear to be an image).
I don’t want to take away the ability to drag the image. If the performance hit has no easy solutions then it might be worth considering adding an optional easing function to moveCamera to slow it down a bit and mask the issue. Perhaps it could be eased by limiting the delta on the drag function in the code to prevent large scale movements in one go when zoomed out. That would still allow the slower drag.
Thanks.
That sounds awesome, SegaBoy! I’d love to see a video of that in action.
Also, good point about adding features Devs can add themselves.
Hi SegaBoy,
I appreciate it - I definitely wouldn’t want your entire project but I was just saying I am new to a lot of this so any snippets/examples of certain functions etc. are extremely helpful - especially when it comes to something not native to the engine.
I know a lot of these features may be somewhat easy to implement, but finding the easiest examples to learn from isn’t always easy!
Thanks and it sounds great!
Oh Dyson - that Isometric example looks amazing!
Maps 2 and 3 of the Isometric Sample Project are more or less finished. What remains to be done is the implementation of remaining features related to Isometric support. What it amounts to is a whole lot of little things, going through each function and checking for compatibility with the new maps, getting physics support to play nice with the isometric view… a few other things.
A notable new addition is that moveSpriteTo and moveCameraTo now have onComplete event listener parameters, useful for applying some effect to a sprite after it has finished moving. In the case of the sample project it is used to move the player sprite up or down a level in response to changes in terrain elevation.
You may have found a bug in the Simulator. In either case, you have to keep in mind that devices have a maximum texture size. I believe most modern computers have a limit of 4096x4096, while the older phones have a limit of 1024x1024 and newer devices 2048x2048. When you try to load an image, like a tileset, larger than these dimensions Corona SDK automatically scales it down to fit inside this maximum size. This will lead to degraded quality if the scale difference is large enough.
Even though your 5184x6000 pixel tileset loaded fine on your phone, I recommend sticking to 2048x2048.
MTE’s memory readout is most useful for gauging how much memory your maps use. It does not report on texture memory. You can use Corona’s system API to see the texture memory in use:
print(system.getInfo("textureMemoryUsed"))
Very large images can take enormous amounts of texture memory. Unfortunately I don’t think we have a function for reporting a device’s total texture memory.
As for the touch scroll performance issue, how far have you zoomed out/what blockScale and screen resolution are you using? I’ve noticed stuttering issues myself, and I’ll certainly look into it today. It’s possible the touch event is calling moveCamera more often than necessary.
The slight stutter with moderate motion is probably just the performance impact of moving large numbers of tiles very quickly. The momentary freeze at high speeds happens because the camera movement functions call a goto() if the effective velocity in a single frame exceeds blockScale * 4. This is normally unnoticeable until you increase the number of onscreen tiles, which both slows down the goto() operation and increases the effective speed of a swipe on the map.
A super easy fix is to simply clamp the velocity you’re sending to moveCamera to just under blockScale * 4 in any direction. In the pinch zoom touch scroll code I’ve posted before, the following code in the enterFrame event achieves just that:
if isDragging then local velX = (startX - currentX) / scaleFactor / mapObj.xScale local velY = (startY - currentY) / scaleFactor / mapObj.yScale if velX \> mte.blockScaleX \* 4 then velX = mte.blockScaleX \* 4 - 1 elseif velX \< mte.blockScaleX \* -4 then velX = mte.blockScaleX \* -4 + 1 end if velY \> mte.blockScaleY \* 4 then velY = mte.blockScaleY \* 4 - 1 elseif velY \< mte.blockScaleY \* -4 then velY = mte.blockScaleY \* -4 + 1 end print(velX, velY) mte.moveCamera(velX, velY) startX = currentX startY = currentY endOur robot really gets around!
Wow, iso looks really nice Dyson
Wow! - That’s absolutely amazing! I can’t wait for Isometric! 
Nice stuff!
Check out the new examples, videos, and documentation:
I have an Ouya, and have run MTE’s Sonic example and it runs great. Just FYI
ooooooo nice! This sounds great!