Return to Answer

more edits

I think I grasp the idea of displaying only relevant tiles from the array (a subset) and that's fine. I would display those in a parent display object and move that object to simulate panning left, right, up, down, and then when the bottom row (for instance) pans out of view, recalculate which tiles to display, and simultaneously adjust the parent display object. Does that sound like that would "fit" within the architecture you are advocating?

Yes. This should all be internal behaviour. To actually pan around, all you do is modify the camera position. Based on that change, the relevant DisplayObjects should be added/removed and the container should be moved accordingly.

This functionality should executed before your code runs, likely even before the program is compiled.

As your code merely deals with deciding what's displayed and what's not, this shouldn't be of interest at all. Maybe there's a property .type in the Tile class that holds a value to represent its type. Maybe this value has to be recalculated because the map changes. But the code you posted is not the place to do that.

This functionality should be executed before your code runs, likely even before the program is compiled.

As your code merely deals with deciding what's displayed and what's not, this shouldn't be of interest at all. Maybe there's a property .type in the Tile class that holds a value to represent its type. Maybe this value has to be recalculated because the map changes. But the code you posted is not the place to do that.

The purpose of pushing and popping tiles endlessly in and out of onScreenArray was so that I can loop through that small array for pertinent functions instead of the potentially huge array of total tiles.

Then onScreen might be redundant. Similarly to copying a subset of the entire Map, you can execute functions on a subset of the map, without storing all Tile objects that belong to this subset in another data structure.

edit

complexArray is the array of index numbers that tell us where from the tile map bitmap to draw the bitmap data (i.e., 1 is ground... But what type of ground is dependent on what is surrounding it, so the complex array may turn a 1 (ground) into a 13, which is a cliff edge)

This functionality should executed before your code runs, likely even before the program is compiled.

Don't just leave a hint on every Tile object how to find some clue in some other data structure how to render it. Figure that out as soon as possible.

• If the map is fixed and never changes during execution, the status of each tile should be calculated prior to compilation. Create some kind of map editor or parser or whatever program to calculate the exact type of each Tile. Run this program before you hit compile.
• If the map changes at runtime, you'd have to include that logic into your program. Execute it when the map changes and only then.

The problem with your existing code is that it distributes data of Tile objects across several data structures. That's bad. You have to fiddle around with all those arrays just to look up some number that might have a fixed value that was know even before the program existed. There's no need to look it up across several arrays every time you try to render a tile.

As your code merely deals with deciding what's displayed and what's not, this shouldn't be of interest at all. Maybe there's a property .type in the Tile class that holds a value to represent its type. Maybe this value has to be recalculated because the map changes. But the code you posted is not the place to do that.