Nooo :) When the player moves, the only coordinates that should need to be changed are... the player's!

Try looking at it in 'world coordinates', and not 'player coordinates'.

The world coordinates of an object are given relative to some well-defined location in the world (i.e., the top-left corner being (0, 0)).

The player coordinates of an object are given relative to the player.

For example, take an object that is just to the right of the player, but in the centre of a 400x400 map. It would have world coordinates (200, 200), but player coordinates (1, 0).

When all the coordinates of your objects/tiles/players/whatever are given in world coordinates, it becomes trivial to move your player - all you need to change are the player's coordinates in the world. After all, it is the player moving in the world, not the world moving around the player!

If you were using player coordinates exclusively, you would need to change the coordinates of every object (ironically, except the player: it always has player coordinates (0, 0)!)

When the time comes to render the world view to the screen, you need only render the range around the player: a rectangle centred on the player, with width and height being that of the screen. You can get that rectangle generated using something like the pseudocode I gave before.

When rendering, you keep track of both the world location of the tile being drawn, and the location it needs to appear on the screen, making sure to keep these two ideas seperate. It sounds like you're confusing the two currently, making more work for yourself than necessary.

Just to reinforce what's already been said, there is almost certainly no reason that you would need or want to move the world (or any part of it) in order to create the effect of the player moving. As has been suggested, move the player, not the world; then, when rendering, set up the rendering parameters (e.g. the position of the 'virtual' camera, etc.) so that the player appears at the center of the screen (or wherever you want the player to be).

Quote:Original post by mattd
Nooo :) When the player moves, the only coordinates that should need to be changed are... the player's!

Try looking at it in 'world coordinates', and not 'player coordinates'.

The world coordinates of an object are given relative to some well-defined location in the world (i.e., the top-left corner being (0, 0)).

The player coordinates of an object are given relative to the player.

For example, take an object that is just to the right of the player, but in the centre of a 400x400 map. It would have world coordinates (200, 200), but player coordinates (1, 0).

When all the coordinates of your objects/tiles/players/whatever are given in world coordinates, it becomes trivial to move your player - all you need to change are the player's coordinates in the world. After all, it is the player moving in the world, not the world moving around the player!

If you were using player coordinates exclusively, you would need to change the coordinates of every object (ironically, except the player: it always has player coordinates (0, 0)!)

When the time comes to render the world view to the screen, you need only render the range around the player: a rectangle centred on the player, with width and height being that of the screen. You can get that rectangle generated using something like the pseudocode I gave before.

When rendering, you keep track of both the world location of the tile being drawn, and the location it needs to appear on the screen, making sure to keep these two ideas seperate. It sounds like you're confusing the two currently, making more work for yourself than necessary.

Hum, ok. So I basically pick a point of focus (the center of the camera?) and render everything within a given rectangle of that. I would need some method for determining the coordinates of the rendered objects.

I don't see how "the only coordinates that should need to be changed are the player's". If I want the world to scroll. That is - I want a tree to appear to move to the left when the player moves to the right, it's on-screen coordinates have to change? How else do I know where to draw it on the screen?

The on-screen location of a given object is a function of its world location, and the player's location. Therefore when the player moves, so does the object on screen.

That sounds very reasonable, but.. even if it's a function of those values, AS3 might make this difficult.

Once I add a GridNode to the display list, AS3 is drawing it, period. In order to not have it drawn on screen I would have to make it not visible or remove it from the display list, either way that's a LOT of nodes I have to either say GridNode.visible = false or remove from the display list. Granted I don't know AS3 that well, but based on my understanding of it doesn't lend itself to simply not drawing something you don't want to draw. Now, I could adapt my earlier post and use a quad tree and make all the previous frames' visible nodes invisible for the next frame, but it still seems like a lot of nodes I'm having to modify every frame, and along with all of the other calculations being made every frame it kind of has me worried.

To clarify - Basically this would be the solution:

- Determine the screen location of the world object as a function of its world location and the player world location only for those objects in the quadtree that are on the screen.

- As a frame exit event, make those drawn objects from the previous frame invisible (since they may not be in the camera this frame, and since I'm not updating their screen coordinates if they aren't on the screen).

*I might just not have a very good understand of AS3 and I'm making this more complicated than it needs to be.

Ah, looks like I missed an important part - using Flash.

Is there no way you can create a 'canvas' like object and render tiles using your own algorithms in Flash?

It looks like the alternative IS moving all the other tile objects around the player, like you originally mentioned >_> (ref)

Note the way that tile objects are reused in the above tutorial - when a tile is scrolled entirely off-screen, its movie clip is (maybe) changed and it is moved straight to the opposite end to be reused, scrolling back in. This means you only need enough tiles in the renderable view to fill your screen, plus enough to handle the scrolling (i.e., an extra row and column's worth).

(Forgive any weird terminology, I don't develop Flash :])

Thanks a lot for all of the help. . were I doing it in any other language I'd do it exactly as you mentioned.

I think what I am going to do is disassociate my GridNodes with the display list. I was planning on having nodes be responsible for their own texture, any buildings on them, terrain on them, etc. So I added each node to the display list and then each node added things that were a part of it to the display list.

Rather than doing it like that I will not add nodes to the display list at all - they'll just be used for path finding and some collision checking. I'll move buildings and terrain independently and won't have to do any calculations per frame on every single node.

Reusing tiles like that is a very good idea. . being that the ground texture will be basically identical throughout the game, with buildings/trees/etc. occasionally thrown on top of it.

Again I appreciate all the help.