Hi all! I have been working on a engine for the past few months, and It has finally come to point where level loading is required.
I was chatting with Falco awhile ago about what would be the best way to load a tilemap.
The way I am currently doing is that I have a fixed 2D array of tiles(100x100), and it loads a number into the ID of the tile, something like this:
Which can be very hard to type; since I am the only one working on this project, I haven't made a Level Editor yet.
So my question is, is there any other way to load a map?
I was hoping it to be something like the last example in the above post.
Any ideas guys?
Perhaps on how to remove a \n when parsing a binary file?
EDIT: I just learned about fscanf()! Funny because Falco mentioned it when we were chatting, perhaps this will solve my problem.
Re: Best Way to load a level
Posted: Sun Feb 17, 2013 4:27 am
by BugInTheSYS
0x0000000 wrote:Perhaps on how to remove a \n when parsing a binary file?
What do you mean by 'remove a \n?'
Do you want the newline character to delimit the tile rows? Or do you want to ignore it?
If all you want is to ignore it while parsing, then I suppose you work your way around by checking if the current character is a newline character, and if so, increment neither currentTileX nor currentTileY, but just literally ignore the newline character. (Hint: The std::ifstream class even has a member function for that.)
Edit: You would probably just forward the get pointer of the ifstream, which is even simpler.
Hope I could help.
Re: Best Way to load a level
Posted: Sun Feb 17, 2013 4:32 am
by 0x0000000
BugInTheSYS wrote:
0x0000000 wrote:Perhaps on how to remove a \n when parsing a binary file?
What do you mean by 'remove a \n?'
Do you want the newline character to delimit the tile rows? Or do you want to ignore it?
If all you want is to ignore it while parsing, then I suppose you work your way around by checking if the current character is a newline character, and if so, increment neither currentTileX nor currentTileY, but just literally ignore the newline character. (Hint: The std::ifstream class even has a member function for that.)
Anyways, thank you Falco and BugInTheSys
I couldn't have done it without you (great now I sound like Dora)
Re: [SOLVED] Best Way to load a level
Posted: Sun Feb 17, 2013 5:24 am
by BugInTheSYS
Open the img tag, and paste the image URL in between (img) and (/img) (with square brackets!)
Re: [SOLVED] Best Way to load a level
Posted: Sun Feb 17, 2013 5:28 am
by 0x0000000
BugInTheSYS wrote:Open the img tag, and paste the image URL in between (img) and (/img) (with square brackets!)
I see, but does that mean I can't upload pictures from my own computer?
Re: [SOLVED] Best Way to load a level
Posted: Sun Feb 17, 2013 5:35 am
by BugInTheSYS
You can use an intermediate image hosting service, like tinypic or any of these services.
Re: [SOLVED] Best Way to load a level
Posted: Sun Feb 17, 2013 5:48 am
by 0x0000000
BugInTheSYS wrote:You can use an intermediate image hosting service, like tinypic or any of these services.
Oh ok, but let me make a awesome map first
Re: [SOLVED] Best Way to load a level
Posted: Sun Feb 17, 2013 6:09 am
by 0x0000000
Uploaded the image! Look at my previous post
Re: [SOLVED] Best Way to load a level
Posted: Sun Feb 17, 2013 2:46 pm
by lalacomun
Now your goal is to handle multiple layers, like tiles, objects, collision etc...
Just a tip for your engine, i dont recomend having a "Collision layer" it uses more RAM and more HDD space, you may say that 1 mb of ram doesnt matter but when you are working with low resources hardware that meg of ram makes the difference i recommend you that each tile have a simple boolean value that sets if its colidable or not, this way you can have something like "colliders" like the ES engine that sets what part of the tile is colidable ex: upper half of tile, left half tile etc...atleast thats the way i handle collision in my engine
Re: [SOLVED] Best Way to load a level
Posted: Sun Feb 17, 2013 7:25 pm
by 0x0000000
lalacomun wrote:Now your goal is to handle multiple layers, like tiles, objects, collision etc...
Just a tip for your engine, i dont recomend having a "Collision layer" it uses more RAM and more HDD space, you may say that 1 mb of ram doesnt matter but when you are working with low resources hardware that meg of ram makes the difference i recommend you that each tile have a simple boolean value that sets if its colidable or not, this way you can have something like "colliders" like the ES engine that sets what part of the tile is colidable ex: upper half of tile, left half tile etc...atleast thats the way i handle collision in my engine
That sounds reasonable!
The only problem is that I have no f*cking clue how to do collision resolution
But thanks for the advice!
Do you maybe know any sites that teach collision resolution?
Re: [SOLVED] Best Way to load a level
Posted: Sun Feb 17, 2013 7:55 pm
by lalacomun
I can teach you do you have skype or something?? or china just block it??? if thats the case you can check out the LazyFoo tuts or here is a great tut about collision:
Re: [SOLVED] Best Way to load a level
Posted: Sun Feb 17, 2013 8:01 pm
by 0x0000000
I have Skype, add me: altan.haan
Re: [SOLVED] Best Way to load a level
Posted: Mon Feb 18, 2013 12:43 am
by DistortedLance
lalacomun wrote:Now your goal is to handle multiple layers, like tiles, objects, collision etc...
Just a tip for your engine, i dont recomend having a "Collision layer" it uses more RAM and more HDD space, you may say that 1 mb of ram doesnt matter but when you are working with low resources hardware that meg of ram makes the difference i recommend you that each tile have a simple boolean value that sets if its colidable or not, this way you can have something like "colliders" like the ES engine that sets what part of the tile is colidable ex: upper half of tile, left half tile etc...atleast thats the way i handle collision in my engine
There are, of course, disadvantages with this approach. It's not quite as flexible when it comes to having multiple tiles with the same graphic but with different collision bounds, so depending on the scenario, a separate collision layer could easily be reasonable. You could do various things like bit-masking the collision type in the "tile index" (if you already had spare bits available) rather than fixing the collision types when loading the tilesheet if you wanted specific collisions per-layer, or just read in an additional value per map-location if you wanted this additional flexibility. If you're using the bit-mask approach, there's no additional memory usage, while the per-location method is a relatively small number of kilobytes. It's probably better for him to decide what the realistic needs of the game would be, rather than simply choosing a method for a constraint that might not necessarily apply.