If you are referring to something like that, the code needed to achieve it with my engine is trivial, to say the least. I imagine it would be one of the samples I’d release, since yes, I can see it being quite a popular feature.
One thing I need to cater for is how other people code - I may have ideas about what is the best way of doing things, but that doesn’t mean I’m going to ignore people who do things differently, so fear not! [import]uid: 46639 topic_id: 36175 reply_id: 144224[/import]
I do understand the enterFrame drawing (unless you’re doing something completely different I’m guessing you’re using “the tiles are already drawn, just update the sprite frames at runtime” method.) That way you only have minimal (~1 tile) movement. I also think it’s fair to want to keep scrolling functions out of yourengine.lua.
But *providing* those functions is still critical for use. You can include them via a secondary lua file, if needed. But I know from working on one of these engines that managing position is an incredible headache and that means I’d need to see some provided scrolling functions up front, among other things.
a) Independent scroll (ie: scrollTo(tileX, tileY, time) – so the map can be moved
b) Focus (update position based on character position) – so the map can move according to the player
c) warp (set to tileX, tileY) – jump to and fro based on real position
d) converter suite (screen X to world X to tileX, for example) – since .x and .y are not reliable
e) fetch suite (if I have tile X, how do I know anything about it?) – beats running converters every frame
f) sprite management (how do I bind a sprite to the map?)
I guess those are the basics. I need to somehow load a map, bind a character to it, and then move around. It sounds like your solution can do some/all of these things, maybe? But if I have to build the enterFrame myself then it gets a whole lot murkier.
Panc: I think you’d have to use some kind of custom variable tracker along with the enterFrame function rakoonic posted. event.x/y wouldn’t work in this case since they’re just reporting screen position. Maybe something like world.x + event.x? (Like I said, this kind of math gives me a headache…)
[import]uid: 41884 topic_id: 36175 reply_id: 144225[/import]
@Richard, agreed, and my terrible math is what broke most of my larger maps. If push came to shove, I figured I would just do it old-school FF1 style and have a pause function that shows a less-detailed, smaller map to scroll around. I would hope people would read that as “retro” and not “too stupid to put in a proper scrolling function”! [import]uid: 135394 topic_id: 36175 reply_id: 144226[/import]
Aaaah ok.
Sure, I did think another layer on top of the core code would be likely, certainly for the most common features, but it was always my intention to keep it seperate. People are always going to need different things, and I certainly don’t want to go down the Lime route, and I certainly don’t want to have to offer a whole load of code that is techincally ‘supported’.
Helper routines mean I don’t have to do this - I can provide them as-is without needing to properly support or bug-hunt/fix them (although naturally I’d be willing to help with this).
Anyway, cheers for the comments, keep them coming. [import]uid: 46639 topic_id: 36175 reply_id: 144231[/import]
I am opening up the code to a few testers - they need the following:
Count me in! [import]uid: 135394 topic_id: 36175 reply_id: 144332[/import]
Panc - prod me on IRC with your dropbox email next time you see me there, I am Rakoonic there as well. [import]uid: 46639 topic_id: 36175 reply_id: 144334[/import]
I don’t see the problem. Competition is good. To be honest we’ve needed competent culling tile engine solutions for Corona for quite some time, and while both engines clearly have the same goals, each seem to have different advantages and weaknesses. Performance may be the same but there are a lot of things to vary in terms of documentation, extra functions, and special case stuff like world-wrap, sprite handling, etc.
The key to success is really going to be which solutions are supported the most going forward in terms of updates and features. (Lime wasn’t fast, but it did have a fairly wide function set, complete support for all Tiled formats, and pretty good online documentation.) Stuff like world wrap, safe sprite handling, safe load/reload/teleport, that sort of thing…
[import]uid: 41884 topic_id: 36175 reply_id: 143674[/import]
Lime was a victim of its own success though.
It tried to do too much, a jack of all trades, and ended up pleasing very few people.
The aim of my code is simplicity and speed - so really it shouldn’t need too much support, and functionality is limited by the fact it is purely meant to load and draw. Realistically it only needs a few more things and it should be there - for its stated aims, it does everything needed now, but obviously if I can help with something simple, I will.
As for formats, I did read somewhere that JSON and LUA exports don’t preserve all the data from Tiled. With LUA this is definitely true, and frankly I doubt I’ll continue developing that importer - it is there for now because it is the quickest way to load (external tile sets? Forget it!). The JSON exporter I’ve found to be very complete - so far there isn’t anything missing, although I’ll admit I probably don’t push Tiled too far (I do use object layers and lines / shapes etc though - all this data comes in fine from the import process).
Documentation? Yeah umm… that’s another reason why it is good to keep it small, less of the boring stuff for me to do 
But, here’s the simplest example code to get a map drawn and displayed:local tileMapClass = require( "libs.tiles\_map" ) -- Load the library
levelTileMap = tileMapClass.new{ file = levelFile } -- Create the tile map
levelTileMap:TL\_DrawAll( 0, 0 ) -- Draw it at 0, 0Obviously there are more options to it, and the defaults aren’t going to always be useful, but, at the end of the day, it isn’t brain surgery.
One of the more useful features I’ve found in mine is working in Tiled units - so you are not working in pixels, but fractions of tiles. [0.5, 0.5] would be half a tile in horizontally and vertically. I’ve been playing around with different tile sizes and this makes it really easy to swap around, especially for collision code (although that *won’t* be included).
One thing I want to get in is the pixel-movement. I *think* it should be possible, but haven’t tried it yet. Despite what I said above about using Tiled units, displaying the levels in pixel units should make it easier for people to do scrolling with minimal visual glitches. Sadly the only way right now to remove all these glitches is to work without a zoom mode. I do this, but I know most people don’t, so I want to try to factor that in, because it can range from a tiny distraction to massively hideous
I know many people want a complete solution, but that would lead down the path towards Lime again, something I explicitly don’t want. What I hope to offer is code that will help people do what they want without the perceived limitations of Lime and/or Corona. At the end of the day it benefits me if more people take Corona seriously in the industry. [import]uid: 46639 topic_id: 36175 reply_id: 143683[/import]
I like the name Grout.
You know, the stuff that holds tiles together and makes them more than a bunch of pieces?
It’s kind of a weird name, I know, but I think it’s kind of cool.
Jay
[import]uid: 9440 topic_id: 36175 reply_id: 143693[/import]
I’m very interested in something that would import from tiled and do it well. I am using Lime at the moment but if your code could deliver alot of the same but in some way better or faster I’d have no problem paying for it. But in order for me to buy something like this I would have liked to see some documentaion of what i does, examples, tutorial code etc. That in combination with the price ofc in the end its all about how much time it would save me and how much I would have to do to get any non supported feature that I need. [import]uid: 17969 topic_id: 36175 reply_id: 143705[/import]
Pretty nice
May I ask how you’re handling physics, as you said in “What it Can’t Do” that you didn’t include physics?
C [import]uid: 147322 topic_id: 36175 reply_id: 143711[/import]
I do actually like the name Grout - bad puns appeal to me
@borgb - it is essentially rendering code, nothing more. It does have some functions to get at the data, and includes backing up (IE so you can change the level while playing it, then reset the data immediately later on), as well as painting into it. Also, you can get at all the values you put in Tile (map level, layer level, tilesets etc) although I may work on that to make it slightly easier.
It naturally only supports 1 active tileset (by default the first in the tileset list, but you can put flags in as well to select another) as that is a (more than) reasonable limitation of image sheets, and speed = good.
@Caleb B - I don’t use the physics engine. I *loathe* physics engines, and they just aren’t needed 9 times out of 10. Black boxes annoy me. OK, I’ve got that off my chest 
Basically I’ve coded my own collision routines. Which won’t be included in the source (but am considering making a simple box VS box routine available for the simplest type of collisions).
Besides, culled views don’t work very nicely with physics (which work best when you set up the whole world beforehand - this is what Lime does but the trade off is vastly slower rendering). [import]uid: 46639 topic_id: 36175 reply_id: 143744[/import]
Great looking tile engine! when would it be available? i have longed for an efficient tile engine since Lime to continue my Pokemon style game which had to be stopped. [import]uid: 114118 topic_id: 36175 reply_id: 144088[/import]
@ rakoonic: Hehe, funny. I really loathe physics too! I’ve been programming my own tile-based engine and physics in Corona for a while now and I’m really curious to see what you’ve cooked up. I’ve just been hammering out my own tile-based engine with level editor last week - it was actually just about done in 3 full-time days so it turns out it’s not that much work. I’ll try to record a video of my engine and editor running and share it here!
Cheers,
Thomas [import]uid: 70134 topic_id: 36175 reply_id: 144119[/import]
I echo borgb’s sentiments. I bought lime, found performance was murdered, and didn’t touch it after messing with it for a couple weeks. I’ve rolled my own kind of option that works somewhat, but like everyone else here, we’re trying to wring every last iota of juice from the Corona performance stone. I’d pay for something that did it well. [import]uid: 135394 topic_id: 36175 reply_id: 144136[/import]
One of the things I’m curious about is what features of Lime did people actually use?
Physics really is out of the possibilities, I have no interest in supporting it and it isn’t really compatible with what I am trying to do.
But apart from that, what sort of things?
I don’t aim to supply lots of helper functions because most are really easy to do through own code (eg, scroll to X, Y… this should not be part of a rendering engine), and I don’t want to end up supporting code that I personally never use.
But, if there are notable patterns, I’d consider simple things, for sure. [import]uid: 46639 topic_id: 36175 reply_id: 144205[/import]
I of course don’t want to speak for everyone, but I feel, like you originally did, that I need a solution renders the map fast, and gets rid of garbage just as quickly. I thought most of the other stuff in Lime (set objects to sensors, tileset management, parallax) were just bells and whistles compared to what I wanted it to do: render tiles well. If you have that down, I’ll buy two! [import]uid: 135394 topic_id: 36175 reply_id: 144208[/import]
Scrolling is I guess something I can’t disagree more about. Almost any tile engine is going to be using interpretive addressing, which means that the act of scrolling around the map (or focused on a character) is a huge pain in the ass and almost impossible to do unless you understand the engine drawing the tiles.
Not supporting focus or scrolling are deal breakers for the games I work on. [import]uid: 41884 topic_id: 36175 reply_id: 144213[/import]
@Richard, good call. I wasn’t really thinking about scrolling options, only because I thought rendering well would include scrolling, but one should never assume. Scrolling would be huge. [import]uid: 135394 topic_id: 36175 reply_id: 144217[/import]