Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Tile based theory  (Read 4233 times)

0 Members and 1 Guest are viewing this topic.

Fouf

  • Newbie
  • *
  • Posts: 23
    • View Profile
Tile based theory
« on: June 09, 2011, 05:47:56 pm »
I'm going to start working on a tile based game, but I would like to run some questions by to get some input on how to do this correctly and efficiently.

I assume I would use.. a vector of tiles? where tile would be a struct

Code: [Select]
enum tileType
{
   grass,
   water
};

struct tile
{
    sf::Sprite tileSprite;
    tileType type;
};

vector<tile> tiles;

An image manager would make sure only one copy of an image was loaded and a reference was passed to each tileSprite.
And I would loop through a text file / string and grab each character and make it into a tile with a nested for loop.
I would later loop through it to draw.

Does any of this seem to be incorrect, or a simple/superior way of doing it?
- Fouf

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Tile based theory
« Reply #1 on: June 09, 2011, 05:56:10 pm »
Having one sprite per tile have some pro's and some con's. It will though take up pretty much memory if you have large maps. Though will probably be easier to do.

Anyway tile based maps are pretty easy, that's why most people do it.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Fouf

  • Newbie
  • *
  • Posts: 23
    • View Profile
Tile based theory
« Reply #2 on: June 09, 2011, 05:59:44 pm »
Can one sprite be redrawn many times? I can not try at the moment as I am not on my desktop computer.
Code: [Select]

sf::Sprite test;
test.SetImage...
screen.Draw(test);
test.SetPosition(x, y);
screen.Draw(test);


I'm assuming this works..
- Fouf

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Tile based theory
« Reply #3 on: June 09, 2011, 06:03:51 pm »
Quote from: "Fouf"
Can one sprite be redrawn many times? I can not try at the moment as I am not on my desktop computer.
Code: [Select]

sf::Sprite test;
test.SetImage...
screen.Draw(test);
test.SetPosition(x, y);
screen.Draw(test);


I'm assuming this works..


Yep that would work perfectly.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

heishe

  • Full Member
  • ***
  • Posts: 121
    • View Profile
Tile based theory
« Reply #4 on: June 09, 2011, 07:36:07 pm »
You should consider the tradeoffs though - if you have large maps and want to use only one sprite per type to render everything, you're going to need to set all of its necessary data for ever time when you render the Sprite. This can cost a lot of performance, especially when you need to set more than just position (for example rotation, scale, subrect, etc.).

So you'll have to think about what you want: Maximum runtime performance or minimum memory requirement. Sprites will cause a overhead in memory, but it really isn't that much. One Sprite in memory will maybe be something like 400-500 or so bytes big, so 1000 tiles would just create an overhead of about 50kB, which is absolutely nothing in todays terms.

On the other hand, a couple of function calls almost won't cost any performance on today's CPUs either, especially with the kinds of optimizations which compilers are able to perform today. But I'd still take more memory over less performance.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Tile based theory
« Reply #5 on: June 09, 2011, 09:01:29 pm »
Both solutions work perfectly. It's just a matter of taste, really. Just use the solution that looks more natural to you.

In my opinion, creating one sprite per entity to draw is more natural, since a sprite stores all its rendering/transformation states. sf::Sprite is not a drawing tool, it's a 2D entity.
Laurent Gomila - SFML developer

krisando

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: Tile based theory
« Reply #6 on: June 10, 2011, 08:36:36 am »
Why don't you just have an array of your tile data structure, the game grid could consist of say, uint_8, pertaining to the id of the tile at that position.

Resources are loaded once into memory and may occur many times. I'm using tile spanning, chopping up a large texture into many smaller tiles (40x40) and drawing in view the tiles spanning in order.

Also maintaining all your data in a single location allows easier management, you could say, change a sprite assigned to a tile on demand, each tile would be affected.

Jove

  • Full Member
  • ***
  • Posts: 114
    • View Profile
    • http://www.jestofevekites.com/
Tile based theory
« Reply #7 on: June 14, 2011, 10:03:39 pm »
In my game I've been using the 'one sprite' method to draw all objects from a large array of properties.

After reading this thread originally, I thought about all the 'Setting' of properties every frame for this one render-sprite. Seemed to me like it was eating up a bit more CPU than necessary.

Well the last couple of days I've been changing my project over to using purley Sprites for all game objects as a test.

There is indeed a performance gain, at least at my end. It's not as much as I hoped for, but definitely better, more consistent and I haven't noticed much of a hit in memory use.

Worth the effort to change it now, me thinks!  :D
{much better code}

Haikarainen

  • Guest
Tile based theory
« Reply #8 on: June 15, 2011, 11:22:25 pm »
In my projects i tend to have an ResourceManager, wich manages both images(sf::Image*, a name) and tiles(consists of wich image, a rect and a name), and then the map contains maptiles(a tile, position).

In the drawing sequence i just have
sf::Sprite Drawer;
Drawer.SetImage(ImageFromTileFromCurrentMapTile);
Drawer.SetSubRect(RectFromTileFromCurrentMapTile);
Drawer.SetPosition(PositionFromCurrentMapTile);
Wnd.Draw(Drawer);

 

anything