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]
Richard9, you’d just call the draw() function with the X and Y coordinates of the thing you are following. It really isn’t something that warrants helper functions.
Interpolating stuff might be considered trickier, but again, it is just easier for someone to write a little helper function once that is external to my code, it would really only be a few lines after all.
One thing that I should explain is it doesn’t use transitions or anything.
I work on the assumption that each game frame you call the draw routine once. Here’s an example of some code that achieves that:[code]--------------------------------------------------------------
– GAME FRAME ------------------------------------------------
local gameFrame = 0
function enterFrame()
gameFrame = gameFrame + 1
levelTileMap:TL_DrawAll( 0, 0, gameFrame )
end
– Add in the frame event
Runtime:addEventListener( “enterFrame”, enterFrame )[/code]where the 0, 0 in TL_DrawAll() are the X and Y coordinates you want to view.
‘gameFrame’ is there for the tile animation code - you can stop incrementing it so the animations pause, or even go negative or change how much you add to it for rewind or fast forward etc.
If you wanted to track a player, instead of the 0, 0 you’d just put in ‘obj.x, obj.y’ instead. [import]uid: 46639 topic_id: 36175 reply_id: 144219[/import]
Not sure I follow the scrolling arguement, unless you are indeed looking for a function along the lines of:
scrollTo( x, y, time)
Realistically, the engine has no concept of scrolling, it just draws where you want to see super quick. The ‘where’ can be literally any part of the map and could be completely different each frame if you wanted to induce epilepsy or something 
Basically the speed of drawing is not dependant on where it was showing the previous frame, as it redraws the entire view completely with every draw call. [import]uid: 46639 topic_id: 36175 reply_id: 144221[/import]
I don’t want to speak for Richard, but what I was thinking was just touch-draggable maps. A big map with Lime would absolutely crawl when scrolling around. Richard, is that what you meant? [import]uid: 135394 topic_id: 36175 reply_id: 144223[/import]
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:
- Pro or indie accounts.
- Forum handler.
- Dropbox.
- Lurking in the #corona IRC channel. [import]uid: 46639 topic_id: 36175 reply_id: 144331[/import]
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]
Any updates?
Has there been any movement on this. I’m stuck on my game at this point with no good way to make large levels.
Any updates?
Has there been any movement on this. I’m stuck on my game at this point with no good way to make large levels.