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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - malachipclover

Pages: [1]
1
General / Re: Tile based map
« on: January 17, 2013, 12:27:29 pm »
OK, I will try the array method, but I need the map to be persistent, so I will have to use a file at some point, whether that be only on save/load a map or during runtime top ease the load on the RAM.

2
General / Tile based map
« on: January 17, 2013, 01:33:30 am »
I am working on a 2D tile based game in SFML, and I need some help with the map.  In previous versions, I have always used a 2D array, but only because they were very early prototypes.  I want to make it an infinite map generator, so I don't think an array would do.  I will probably generate the map in chunks, if that changes anything.  I suppose I could use an array the size of a chunk (I am thinking either 16 * 16, 32 * 32, or 64 * 64 tiles) and then just swap the data out with data for the next chunk out of the map file, but I'm worried that might take too many resources.  Also, if the chunks do not divide evenly onto the screen space given(very unlikely it will), this approach would leave black around the sides once the edge of a chunk was reached.  A possible solution would be to make the array, say for example, 2 * 2 chunks, so then if a player was moving down, the top 2 chunks would be overwritten by the bottom 2 in memory, and the previous space occupied by the bottom 2 could be loaded from disk for the chunks below that.  The problem is, this approach would further complicate things, and it still would not eliminate the slowness of replacing the old data in the array.  Both array approaches would also have the problem of further complicating getting/changing tile IDs at a given coordinate because that specific coordinate might not be in the current array, and even if it was, it would be in coordinates relative to the top left of the top left chunk being stored in the array, either requiring an extra function call, or typing out code to convert to global coordinates every time.
    Another approach would be a map, consisting of std::pairs made of an sf::Vector2i and either a number, enum value, or a custom tile class or struct.  I am unsure of the how well a map will perform speed-wise though.  I imagine it will be considerably slower, being that you have to iterate over the items rather than just give it a location.  I was also thinking about having a map that contains other maps.  So I would give an int rather than a vector, and that int would be the X coordinate.  I would then get another map that contains all the Y coordinates for that X coordinates.  There would be fewer iterations (hopefully) but there might be more overhead in returning (or however an map::iterator works) a map.
    Last thing, I need a good way to serialize/deserialize the map, and some other information (mainly entity positions).  I would prefer to not use any external libraries, but if that's what it takes I will use one.

3
Window / Re: Accessing RenderWindows
« on: November 21, 2012, 04:37:19 pm »
That might work too...  too bad I already started doing it with a renderer class

4
Window / Re: Accessing RenderWindows
« on: November 10, 2012, 03:39:46 pm »
Quote
The reason why it is done like this in tutorials is simplicity, not scalability. However I doubt that a lot of experienced people have everything in main(), when it comes to developing a bigger project.

Of course, I have a big project myself and I know handling it all in main is total madness, it totally goes against the purpose of OOP and other programming paradigms, but if you are still testing things and are nowhere near finishing your project it's better in my opinion to keep things simple until they truly do require some fancy solution.

It may make sense in some situations, but I know this project is going to expand rapidly, and so I would rather have things done right from the start than to do major refactoring work later on.  I think I will go with Nexus' idea of containing it within another class.  I like that and think it will do me well, plus it'll give me a reason to learn classes in C++, something I've been not looking forward to.  I don't know why though, because I started off with Java, and i immediately understood the concept of classes with very little explanation needed.  I guess it's just learning the syntax to them in C++ that I don't want to do.

5
Window / Accessing RenderWindows
« on: November 03, 2012, 05:42:52 pm »
I need some help with a good way to access my RenderWindow.  I would rather not put all my rendering code in main.cpp where it is declared, but I'm not seeing a way to access the window from anywhere else.  If I declare it in a header file, I get errors about multiple declarations.  I tried to make a helper function in the main file called void drawToWindow(const Drawable& d) but it complained about that too, so I shortened it to drawToWindow(Drawable d) but it still complained.  I'm stumped on this one.  I really do not want to have to put all my rendering code into the main file, but I don't think I have a choice at this point.  Any help is appreciated.

Pages: [1]
anything