Questions on My First Tile Map

[justcolorado]

I am having fun plugging away at my first game using SFML, when I get it a little further along, I will post it up here, and on sourceforge.   I am working on the tile map now.  

I have 2 questions, I will probably have more later, but these  should get me through the map.


1. Is using a normal Multi-Dimensional array of sprites OK?
    Something like this

Code: [Select]


sf::Sprite tileArray [11] [9];


    In the examples I saw here everybody was using Vectors
    am I better off using a Vector, if so why?


2. I am using 96 x 96 tiles some go the full 96 pixels
    but many of them have smaller images inside and some
    empty background space.  I haven't started on my collision
    detection yet, but I am a little worried this can cause a problem
    down the road. Specifically:
    Is there any thing other than specifying the exact boundaries
    of each image inside the 96x96 tile that I could use to tell if there
    is an actual collision with the pixels of the image, and not just a    
    collision of empty background space?

Thanks,

[justcolorado]

If this helps any, here is the tileSheet I am using, and the maze I want to build with it:

(The plant/grass tile has been updated since I made my last mockup of the map)

Tile Set:




Maze:

[Tex Killer]

In the examples I saw here everybody was using Vectors
am I better off using a Vector, if so why?

It is common to use vectors on the list of tiles, but not on the map. The map usually is a multidimension vector, like you said, but it is usually of numbers, that represent positions on the list of tiles, so that the same number could be on multiple positions of the map. That way you would only have one sprite object for each different tile.

As of the second question, it is not advisable to use image alpha for collision, as it would be heavy for the processor. Usually you define manually where is the collision for each different kind of tile you have, then you use this information whenever you want to check for collisions.