Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Smooth scrolling of top down tiled map
Started by vix_blue Oct 14 2019 01:11 AM

2 replies to this topic
[TOPIC CONTROLS]
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

vix_blue

[GLOBAL: userInfoPane.html]
vix_blue
  • Observer

  • 2 posts
  • Corona SDK

Hi
 
I am planning to develop a top down tiled map game (similar to Zelda A link to the past for the SNES). I want to handle the tiled map myself and not use a plugin e.g. PonyTiled. I wonder how I can achieve a smooth scrolling when the player moves around in the world. I guess that all tiled maps cant be loaded at the same time cause of memory limitations.
 
Shall only the the visible tiles and a few around them be loaded and when the player moves, the tiles which are no longer visible should be cleaned up by using display.remove ?


[TOPIC: post.html]
#2

davebollinger

[GLOBAL: userInfoPane.html]
davebollinger
  • Corona Geek

  • 1,373 posts
  • Corona SDK

this is a broad "culling" question applicable to many environments, a quick internet search ought to turn up lots of "strategies".  your choice of strategy might depend on how big your map really is, as Corona already internally handles "visual culling" so even if you have a lot of tiles offscreen, most won't be rendered anyway (they'd still be consuming memory however).

 

if your map is truly large enough to have memory issues (not graphics issues) then you'll need your own memory-culling system on top of Corona's graphics-culling.  for a zelda-style map, one strategy is to think in terms of the "sub-screens" (say 16x14 tiles, for instance), then cull based on a 3x3 area of sub-screens centered around player.  it's "cheaper" than per-tile culling if you can spare at least that much memory, though does require that you can "quickly" create/destroy a 1x3 (or 3x1) set of sub-screens on-demand at runtime rates.

 

for extreme memory-saving, consider that for per-tile culling you really only need (R+1)*(C+1) sprites ever (where C,R are the number of tile columns/rows in your viewport) - you can just move them around and "repurpose" them (ie, change their sprite frame) without ever destroying/recreating them.  this is essentially the opposite of the sub-screen strategy above - more work to maintain, but very memory-efficient.

 

keep in mind that by "memory-saving" we're not talking about texture memory - that's going to remain a fixed cost assuming that you have the whole tilesheet always loaded (which is probably recommended, for performance reasons - you wouldn't want to be loading/unloading textures while scrolling).


  • roaminggamer and sporkfin like this

[TOPIC: post.html]
#3

vix_blue

[GLOBAL: userInfoPane.html]
vix_blue
  • Observer

  • 2 posts
  • Corona SDK

this is a broad "culling" question applicable to many environments, a quick internet search ought to turn up lots of "strategies".  your choice of strategy might depend on how big your map really is, as Corona already internally handles "visual culling" so even if you have a lot of tiles offscreen, most won't be rendered anyway (they'd still be consuming memory however).

 

if your map is truly large enough to have memory issues (not graphics issues) then you'll need your own memory-culling system on top of Corona's graphics-culling.  for a zelda-style map, one strategy is to think in terms of the "sub-screens" (say 16x14 tiles, for instance), then cull based on a 3x3 area of sub-screens centered around player.  it's "cheaper" than per-tile culling if you can spare at least that much memory, though does require that you can "quickly" create/destroy a 1x3 (or 3x1) set of sub-screens on-demand at runtime rates.

 

for extreme memory-saving, consider that for per-tile culling you really only need (R+1)*(C+1) sprites ever (where C,R are the number of tile columns/rows in your viewport) - you can just move them around and "repurpose" them (ie, change their sprite frame) without ever destroying/recreating them.  this is essentially the opposite of the sub-screen strategy above - more work to maintain, but very memory-efficient.

 

keep in mind that by "memory-saving" we're not talking about texture memory - that's going to remain a fixed cost assuming that you have the whole tilesheet always loaded (which is probably recommended, for performance reasons - you wouldn't want to be loading/unloading textures while scrolling).

 

 

I think I will try to "cull based on a 3x3 area of sub-screens centered around player. " 

Thank you for your help.




[topic_controls]
[/topic_controls]