As far as I know, there are two basic platformer terrain styles: tiled and polygon. Tile based platformers usually feel very "square" and unnatural, so polygonal might be the way to go.

I liked the way Gunster felt. You could smoothly run over small hills and bumps, rather than get snagged on everything.
{"name":"591309","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/b\/8b8290be5fb358992c69bf2be9eb3d39.jpg","w":800,"h":600,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/b\/8b8290be5fb358992c69bf2be9eb3d39"}

More precisely, how do these terrains work? Using line segments with an overlaying bitmap would be efficient, but difficult to construct the maps. On the other hand, using masking sprites would be less efficient, but much easier to program and design maps.

As attached, you can see the problems with the segmented polygons for terrain. To have any decent collision, each chunk of land would need many segments...leading to difficult times making the maps, and "attaching" the polygon to the sprite within the map would be no easy task, either. Also, walking up inclines with masking tiles wouldn't be very effective or smooth. Actually, this could be difficult even with polygons. How would you find out which polygon you are standing on if there is the possibility for floating islands?

Any suggestions for overcoming these problems? Are there, perhaps, other terrain styles that could be used?

Well your screenshot could have been from a tile based game as well. In that case they would have to be a clever and work hard to get a natural feeling. I would use masked sprites, it got to be efficient enough right?

So...a vector of line segments, sort by height, and start at the bottom, working your way up towards the player, using the last "collision"?

Check the game "Soldat", especially it's map editor, which is using polygons.

Soldat only use tiled textures and some sceneries on top of the polygons (like grass) so it's not as good looking as your screen, but it's still very nice.

I've learned a lot just by using Soldat's editor.

{"name":"591311","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/b\/7b12a825e0f167a8670b0d543846d684.gif","w":672,"h":282,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/b\/7b12a825e0f167a8670b0d543846d684"}
That's supposed to be ground. It's ugly. And the Allegro polygon rendering functions seem too slow to be using excessively. I'll be looking at Soldat, particularly the map maker.

Epsi: yes, and it must a pain in the butt to make rectangular shape if you want.

Making a rectangle out of triangles isn't exactly one of mathematics hardest problems...

I suppose this can be done fairly easily by calculating world coordinates and using them in the offset for the texture. And, yes, the newest Soldat map maker does, in fact, do this automatically.

Let me try again.
{"name":"591313","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/f\/0f0a4c0b50df3b8b4076f95263785eed.gif","w":561,"h":134,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/f\/0f0a4c0b50df3b8b4076f95263785eed"}

Image 1 shows where very few segments were used. A lot of the area around the edges would, then, not cause a collision, and it would feel as though you are walking through the ground much of the time. Image 2 shows where many segments were used to more properly fill the collision area of the land.

Why would that be a problem anyway?

Sounds familiar to my experiences... I got there in the end so if you want the latest compiled Openlayer SVN lib for MSVC8 I can just send you it (I have no idea what IDE you use though so this may not even apply). When it comes to actual usage I found learning not too hard especially if your used to C++.

Matt.

It isn't when you have a lot of them either. Space partitioning will drastically reduce the need to do collision detection, to the point where you can probably comfortably have hundreds of these things with no great expenditure of cycles. For instance, a simple way might be to calculate a bounding box for each such chunk of land, and do a preliminary (and faster) test for that bounding box at first and skip the rest of the checks if that fails. And/or you can go with some other partitioning scheme such as quadtrees or grids.

I was considering splitting the map up into a grid, and each sector would be a list of polygons that are contained within or touch that part of the grid.

Onto movement now...Theres basically two ways I can do it. 1) When the character is on a polygon and moving across the top of it, use sin/cos to calculate the new position along the segment they are currently standing on and move to it, and 2)if the character is not colliding with a polygon, let gravity take effect. Otherwise, move the character left/right, and possibly up a few pixels to prevent them from walking through the ground when going up an incline. Which is the preferable method?