Hi,
Is there any way that the background can be created using tiles like in a RPG.
cheers,
Jayant C Varma [import]uid: 3826 topic_id: 3043 reply_id: 303043[/import]
Hi Jayant,
Currently, there is no “built-in” way to construct levels using tile-maps, but it’s a frequently requested feature (by myself, among others), so I think Ansca has placed it fairly high on their priority list. It’s very possible that they’ll implement a third-party tilemap editor like TMX (Tiled, http://www.mapeditor.org/)… this seems to be a widely supported tool in other development platforms, so it seems logical that Ansca would provide support for it.
Until then, I’m considering building my own basic, bare-bones “tile editor” which just puts together tiles using a graph layout and coordinate numbers or something. I haven’t thought about the details yet; I’m hoping that Corona gets tilemap support soon, not 6 months from now.
Brent
[import]uid: 9747 topic_id: 3043 reply_id: 8891[/import]
Thanks for that.
so for the moment, I can let’s say paint individual tiles on the screen, how do I scroll them all? Repaint all the tiles? [import]uid: 3826 topic_id: 3043 reply_id: 8905[/import]
Like any multi-part background, the tiles will be added to a display group: display.NewGroup(). Then the entire group can be scrolled, moved, or manipulated as a group. There are some great tutorials around here about using display groups as larger backgrounds, so just poke around… tiles would function on the same principle.
Best of luck!
Brent
[import]uid: 9747 topic_id: 3043 reply_id: 8906[/import]
Repaint all the tiles?
If you go that route, the easiest optimization to make is to only repaint those tiles that have actually changed. For example, expanses of ground, water, etc., might scroll, but the tile in a specific position might not have actually changed (the tile in position 34,109 used to be TILE_GROUND and now after scroll it’s still TILE_GROUND – no need to repaint).
Also, only repaint the tiles that are actually on the screen. That might seem kind of obvious, but not necessarily if you haven’t done tiling before. 
Jay
[import]uid: 9440 topic_id: 3043 reply_id: 8952[/import]
Hi Jay,
thanks for the reply. I have by then read up on groups, so I have a slightly modified question.
If I create a new group, this is an arbitrary and huge placeholder. so for arguments sake,
The display is 320x480, this group is 1280x1920 with each tile about 32 pixels.
- Will creating this huge group with 40x60 tiles not be expensive in terms of memory?
- Can I simply scroll this group by modifying the x and y co-ordinates?
cheers,
Jayant C Varma [import]uid: 3826 topic_id: 3043 reply_id: 8953[/import]
I was working on one but I think Ansca are as well so we decided I was wasting my time duplicating efforts. Its something to wait for I suppose.
Isometric or not its dead simple though to display the group. The hard work is the arrays / tables containing the data for all the tile positioning.
You need to draw the squares from top left to top right going 1 row at a time. This is more for isometric tiles but it works well for all.
The display objects, once off screen no longer bother opengl so you can tile all you want. There will be an overhead eventually but im doing so really complex things and Corona is keeping up no problems.
You would want to put every tile in a master / world group so you can move / rotate the group all at once rather than iterating through a table updating each tiles position.
The bottleneck would probably be texture memory but the sprite system will take care of a lot of that now. [import]uid: 5354 topic_id: 3043 reply_id: 8958[/import]
Hi Jayant,
Just to add to this topic… consider that your tile group wouldn’t necessarily need to consist entirely of 32x32 pixel tiles. If you had some larger repeating regions, like a stone floor or desert sand, and those tiles were intended to reside beneath other tiles in the z-index, you could make those perhaps 256x256 pixels and thus “fill” your world much faster and with fewer images. Classic games like “Ultima 7” did this: while the smallest tile was probably around 16x16 pixels, there were also much larger world chunks implemented to paint the ground of the world.
I believe that the ground would be painted first, then the tiles above it… but they would all be added to the same DisplayGroup for movement/grouping purposes. Images added later in Lua code get placed on top of those added before, even when they’re part of the same DisplayGroup (I’m almost positive of this). The order in which you declare DisplayGroups determines their global z-index sorting, but I think each group also has its own internal z-index ordering. There’s a detailed post about this here:
https://developer.anscamobile.com/forum/2010/10/09/initializing-groups-layers
Anyway, consider this… tiles don’t need to be consistent size in Corona, you’d just need to write 2 script routines: one that would paint the “ground” tiles (larger) and then another that paints the “object” tiles (trees, buildings, whatever) over top the ground tiiles.
Brent
[import]uid: 9747 topic_id: 3043 reply_id: 8963[/import]
there’s a good example for Game Edition here (but it’s only vertical tilescrolling in this example)… there are 13 rows of which 12 are visible… essentially once one row has scrolled off you repaint all the tiles (actually you change their .currentFrame) and then move the group back to it’s original position [import]uid: 6645 topic_id: 3043 reply_id: 9792[/import]