0
\$\begingroup\$

The idea is to work with tiles that together make up a larger image, or world so to speak.

but im confused as to what the methods used are to offset the tiles, and whether is a good idea to draw offscreen.

For example

var backgroundScroll = 0
update() {
 backgroundScroll++
}
render() {
graphics.draw( resource: BACKGROUND, screenX: -backgroundScroll, screenY: 0)
}

while there's no tiles seen here for the sake of simplicity, im simply emphasizing that we are drawing off screen.

As such the question is, how is this background offsetting accomplished, more specifically, without trying to render outside of the screen, as the framework may or may not know how to handle drawing to areas beyond that of the screen.

In essence the game's world will be comprised of an array of tiles

var cells[map_w][map_h]

and each cell is 32 px wide and 32px height

the idea is to scroll the map but cutting corner cells 1px per unit of speed, but altering the logic so that no negative numbers are entered into the draw function.

I could probably figure something out on my own but i really want to hear how other people are accomplishing this rather popular task

\$\endgroup\$
0
\$\begingroup\$

If you know where your camera is and the dimensions of your screen you can extrapolate a "cull bounds" in world space. Then, given a function that can check if two rectangles are intersecting, it's a matter of looping through every tile in the map and checking when the tile bounds and cull bounds intersect. Followed by adding the tile verts to a set of verts to be drawn. You can further reduce the verts drawn if the tile type (invisible/sky/etc) doesn't need to be drawn even though it's "in view."

This has an added advantage of making a world of thousands of tiles be one draw call.

EDIT:

i got confused in this aspect. It's not tremendously hard to set up a srcRect from a bitmap generated from all the tiles merged together.

Generating a bitmap the dimensions of the map multiplied by the tile dimensions will quickly cause problems due to GPU memory exhaustion or too-large texture dimensions as defined by the hardware. The above method will create a single mesh just big enough to be visible on screen.

Yet, i can't wrap my head around how to accomplish this while maintaining internal TileData structure. I mean theoretically if the tile is 32px wide then if the character had pressed the key long enough it would increment the x cell position accordingly. but im looking more into relating the x position of the character with the tile asociated with that x position. I haven't ventured deep , altough last time i did it i ran into problems offseting tiles

Are you trying to implement tile-based movement (think Rogue-likes) or free-movement with tile-based maps?

\$\endgroup\$
  • \$\begingroup\$ i got confused in this aspect. It's not tremendously hard to set up a srcRect from a bitmap generated from all the tiles merged together. Yet, i can't wrap my head around how to accomplish this while maintaining internal TileData structure. I mean theoretically if the tile is 32px wide then if the character had pressed the key long enough it would increment the x cell position accordingly. but im looking more into relating the x position of the character with the tile asociated with that x position. I haven't ventured deep , altough last time i did it i ran into problems offseting tiles. \$\endgroup\$ – Gabriel Reyes Nov 5 at 1:57
  • \$\begingroup\$ @GabrielReyes see edit \$\endgroup\$ – Casey Nov 5 at 5:11
  • \$\begingroup\$ A mixture of both, the main reason im using tiles is due to collision detection, and also to make the map more straightforward to generate. Ill likely end up having the game support both modes, but only end up using one. \$\endgroup\$ – Gabriel Reyes Nov 5 at 19:57
  • \$\begingroup\$ @GabrielReyes If you're going to only use one method, why bother implementing the other? The collision detection and response methods for free-movement involve raycasts and calculating the closest point whereas tile-movement involve just checking the type of the tile being moved to. Quite different. \$\endgroup\$ – Casey Nov 6 at 5:19
  • \$\begingroup\$ ill likely be using the tile method then \$\endgroup\$ – Gabriel Reyes Nov 6 at 5:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.