Basically my character will stay in middle of screen and my world will move down. Then I have controls to rotate the world but the world will always be moving down no matter the angle I rotate
Like the game
Spinner prologue
Basically my character will stay in middle of screen and my world will move down. Then I have controls to rotate the world but the world will always be moving down no matter the angle I rotate
Like the game
Spinner prologue
@corona5196; The most common causes of these problems are misplaced
files and misspelled filenames. Your code expects cavemap1.json to be in
the root directory of your app. You should also make sure you aren’t
missing any capitalization.I’ve run out of time for now, but I will be on later today to help as well.
Thanks Dyson. well as far as I can see everything is fine. In my project folder I have…
build.settings
cavemap1.json
cavetiles1.png
config.lua
main.lua
mte.lua
Those all look fine to me and my code has the right caps etc. What the heck?
If anyone can offer any insight that would be great. Here is a link to a zipped version of my project if anyone can look and see if it works for them? NOTE: zip file doesn;t include the MTE.LUA file so you would need to dump that in there.
That would be pretty straightforward to code, jstrahan, as long as you don’t use the Physics API. I’ll see what I can do about getting Physics working correctly with world rotation.
doesn;t include the MTE.LUA file so you would need to dump that in there
I appreciate the forethought 
I apologize for the inconvenience here, but MTE is very picky about the width of tileset images. They must exactly fit the number of tiles in the row. If you crop your image from 512x512 to 510x510 and update the imageheight and imagewidth values in cavemap1.json from 512 to 510, it will work. Just remember to load the new image.
Okay my brain is becoming a bit numb right now.
I have my source tileset in gimp which is 480x480 in size. Each tile is 32x32. I web slice those to a folder and then run a renamer over them so they will have the correct order in texturepacker.
I run texturepacker and set geometry width and height to 512, layout algorithm to basic, sort by name, and order ascending. This makes mu tiles appear in texturepacker the same as they do in gimp. I disable auto alias and trim. I set border padding and shape padding to 0, and set extrude to 1.
I then publish the tileset as cavetiles1.lua and cavetiles1.png
I apologize for the inconvenience here, but MTE is very picky about the width of tileset images. They must exactly fit the number of tiles in the row. If you crop your image from 512x512 to 510x510 and update the imageheight and imagewidth values in cavemap1.json from 512 to 510, it will work. Just remember to load the new image.
So what am I supposed to change and how am I supposed to change it? Please forgive me but I am new to corona etc.
Okay I totally get it now, I think. can you confirm…
I make my tileset and I subtract 2 pixels from it’s width and height. then in my json file modify the tileset width and height to match.
If this is correct then is it always the case that you need to modify files to suit the engine? Or does this only happen in some circumstances?
In TexturePacker you can change the Size Constraints in the Geometry section from “POT (Power of 2)” to “Any size.” This will always yield a useable image.
Alternatively, add 2 to the size of your tiles, which are 32x32. This gives you 34x34, the size of the tile images after extrusion. Count the number of tiles in one row of the source tileset. There are 15 tiles in each row of your source tileset. Multiply 34 by 15 to get the exact ideal width of your new tileset. The result is 510.
After running your tiles through the renamer, add them to TexturePacker, set Size Constraints to “Any size” and Fixed Size W: to 510. Set the rest of the options as usual. This will yield a tileset image with the correct width, and also keep all the tiles in the same order and place as they are on the source tileset.
Many thanks dyson! So it seems that I don;t need to resize the tiles in gimp to 34x34 or anything. Just changing tilepacker to “Any size” and setting both width and height of output file to 510 makes it work
MTE v0.872 - http://gum.co/staO
The Million Tile Engine’s horizon is ever-expanding as more and more features fall into place! Version 0.872 marks the end of the heavy lifting for Physics integration and brings a slew of new improvements, features, and functionality to the engine. With the bulk of the physics work out of the way I’ll be setting my sights on the next major feature: isometric support.
The most visually obvious addition in 0.872 is support for the remaining Tiled Objects; polygons, polylines, ellipses, and box/squares. All these objects can be rendered as vector objects by setting any combination of lineColor, fillColor, and lineWidth properties in the Tiled editor. You can define their physics properties as you would with the gid/tile objects of 0.844, but the new engine goes one step further: by setting an object’s shape property to “auto” you can have the correct physics shape generated for you at runtime. This includes multi-body shapes for convex polygons; draw any non-intersecting polygon in Tiled and MTE will find a combination of bodies to fill that space and make it collidable!
Tiled Objects are drawn en masse with the new function drawObjects(). If you gave the object a name in Tiled, the new display object will also have that name, and you will be able to call up a reference to that specific display object as needed. Additionally developers can draw a single object using drawObject(), or redraw an object with modified properties by calling redrawObject().
I touched on a few of the other new features in the forum. When you load a map, that map is now saved in memory by default. The next time you call loadMap(), that map will load from memory in a fraction of the time, rather than having to be parsed from it’s file all over again. New ‘unload’ arguments for cleanup() and loadMap() will override this feature and erase the map, perfect for conserving memory. The brand new functions preloadMap(), getLoadedMaps(), and unloadMap() allow for greater control over what map is available and when.
New lookup functions make life amongst large numbers of sprites and tiles a lot easier! The function getSprites() takes many parameters and returns a convenient list of all sprites which match those parameters. getTilesWithProperty() does exactly what it says, returning every active tile with the matching property.
More intriguing are the new listener functions. addPropertyListener() monitors the engine’s internal clockwork for spawning tiles into the active culling region. If a tile generates which has the specified property, the engine dispatches an event to your listener. The function addObjectDrawListener() works in much the same way, however it monitors the Tiled Object draw functions mentioned above and dispatches an event on a matching name rather than a property.
There is much new to see! I recommend looking into the Platformer - Angled PHYSICS sample project. It includes a new map demonstrating the new Tiled Object physics and draw support, toggle-able by uncommenting lines in main.lua. The new LineOfSight sample demonstrates the possibilities of Physics Raycasting for obstacle detect and the sample’s namesake; line of sight. Definitely take a few moments to peruse the new API and Reserved Tiled Properties documentation as well.
A great deal has changed within the pre-existing MTE functions to improve stability and performance, and to enable MTE’s old movement functions to manipulate physics objects. If I’ve learned anything, it is that bugs love change! I’ll be keeping an eye on the forum for any bug reports.
Enjoy!
Yay! Thanks Dyson for your hard work. Did you mean to say MTE 0v872 on the first line? Just wanted to be sure!
I can’t wait for Isometric support and what you’ve done with physics is truly amazing.
Thanks again!
Did you mean to say MTE 0v872 on the first line?
Yes I did! Thanks for pointing that out. It’s fixed now.
hah - just wanted to make sure!
Thanks again for the hard work and dedication to the project - it is looking awesome!
Brill! I think addPropertyListener() is going to be just what I need to spawn monsters in my cave game
This is great! Thank you very much for your continued dedication and amazing work.
Playing with vector Tiled Objects:
Next on my todo list is adding physics support to all of them.
Hi,
I’m quite new to Corona and Lua (and coding) but managed to get a 100x100 map working using Tiled which drops into other maps when encountering objects. I’ve used your code example on RotateConstrainStoryBoard to build it using scenes. So far I have three scenes setup where one is the main 100x100 map and the other two are small instances of a few tiles each at present. And this works great back and forth between scenes.
Today I decided to enlarge the map to 100x100 tiles. This still works as expected but now the time to return to the main map from a instance is pretty slow (several seconds). I realise this is due to the map size but given the capability of MTE to use large maps I was wondering whether you have any suggestions.
The main issue is that once I leave scene1 and then return it needs to run mte.loadMap to acquire the data such as tile properties (from Tiled). mte.loadMap resides in willEnterScene. In my naivety I’ve tried moving it to the start of the code but this fails in the same way as the data isn’t there after returning from scene 2 or 3. I guess I could attempt to load the map into the mydata.lua store where M resides for global data to cross between scenes but this is beyond me right now and I’m not sure it avoids doing mte.loadMap anyway.
Ideally I’d like my map to be able to handle larger than 1000x1000 as you’ve demonstrated in one of your videos but I can’t see this being feasible. I have considered breaking the map into smaller chunks as new scenes but one of the things I’ve setup is the zoom and scroll function to move around the map at will and that would then become unworkable I think.
So how do I load a large map and keep it so a loadMap isn’t needed or how do i assist loadMap to reload the map quickly?
Many thanks for such an awesome tool
On second thoughts perhaps I’m being overambitious with expecting a million tiles to load quickly. I’ve tried it at 500x500 and it’s just about ok I think. My tiles are at 42x42 at the moment which I now realise is wasting memory as it’s not the 2 factor and I should go for 32x32 or 64x64.
However, I’d still appreciate you thoughts on this.
ah, I see you’d thought of this issue previously.
At the moment I handle map removal by not handling map removal. Loading a map clears out all of MTE’s map arrays and refills them with the new information. Now that you mention it I should probably allow users to handle this themselves if, for example, they want to hold the world map in memory while going into a town to reduce loading times between the two. That shouldn’t be too difficult to implement.
Thanks for reminding me about this, Coldwilson. As I mentioned back then, this sort of thing should be simple to implement. I’ll see if I can work a solution into the coming update, which is a couple weeks out. Probably add an optional flag to mte.refresh() to store the map arrays out of the way until the same map is loaded again.