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?

You could have masked sprites for it, but instead of one for each polygon, you could make a 'spriteset' (comes from tileset) of sprites that can be placed randomly within the polygons and many would overlap the collision lines.

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?

Just like tiles. You'll need to make list of references to the lines and find out which one is below you by getting the value of the 'y' which will most likely involve interpolating between x1y1 and x2y2.

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"?

Not necessarily sorted by height since you'd want it to be robust in case there are long vertical falls.

What I was thinking of doing was having 'tiles' of lists of references to lines/polygons that touch these 'proxy tiles' which should allow you to find the polygons nearest to your players to cut down the number you need to render and collide with.
Read here.

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.

Polygons are not too hard for platformars. I used a ghetto Polygon ground system in the last speed hack. For the most part they are not even Polygons, they are just collision boxes that have slanted lines. You have to do a bit more math but I think some one who took high school geometry could figure it out. No sin(), cos(), or sqrt() needed.

{"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.

If you choose the polygon way I would recommend using OpenLayer instead of pure allegro. It will be faster and easier to do.

btw Soldat use only Triangles to create its map, with lightning+color on each vertices.

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

I think you are right. I was considering OpenLayer, but have not learned the first thing about it yet. A lot of people seem to get confused or misunderstand how to do many things with OpenLayer (There are a lot of "Why doesn't this work!?[OpenLayer]" threads), so I was hesitant. On the other hand, I do like it's capabilities and will need the hardware acceleration.

I don't mean to de-rail my own thread...but...OpenLayer contains many collision detection functions. Do any of these fill the "walking up an incline" need, or would I still implement that myself?

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

Well but matchin them together so you can't see the difference in the texture can be. But I should take a closer look at the latest Soldat map maker.

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.

I don't understand why you say this.

The "will be incorporated into the distribution one day" new Allegro demo game (completed almost 2 years ago) draws using the ordinary polygon routines (not the textured/3d/whatever ones) and purposely sets and shifts a texture so that it moves with the ground. That's not so bad.

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.

Oh, I was being a thickie. The new Allegro demo game only uses "segments" in that the entire level is built of polygons, full stop. Look:

{"name":"DemoGame.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/c\/5c2001210e622cbcc3223606fc1a4894.png","w":720,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/c\/5c2001210e622cbcc3223606fc1a4894"}

Why would that be a problem anyway?

It isn't...until you have many polygons with high vertex counts. I plan on partitioning the maps to minimize collision detection, though.

So after having played with OpenLayer, I feel like stabbing myself in the eyes. The lack of textured polygon drawing was quite irritating. First it was supported, now it isn't...so I was forced to try using the code Flad previously posted that works in a cookie-cutter fashion. No go (some of the functionality used was not in the version I had). So onto SVN...Well, it didn't want to detect freetype, but after putting up a mild fight it finally gave in only to give me plenty of errors. I couldn't be bothered to fix all the source files, as who knows what problem would haunt me next.

Flad, don't take what I just said the wrong way. I think OL is great. I just really wish it would support even basic texture mapping to shapes without much fuss.

But, the original plan was to have the graphics(tiles and bitmap chunks of land) separate from the collision polygons anyways. I think it would produce a much softer, non-square feel, and give more control. So, map editing would be done similar to the previous image I posted of a land chunk with it's separate collision poly. Does this sound like a viable solution?

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.

I'll gladly take it, but I do use Dev-CPP. Who knows, maybe somebody else would want it as well.

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.

If all else fails, you can divide your whole scene into a tile grid, and split all polygon outlines into pieces that fit into a single tile. If your character is not larger than one tile, you never need to check more than 4 tiles, and it is very unlikely that there are more than maybe 5 line segments inside a given tile (typically no more than 2 even). IIRC, Sonic The Hedgehog does something like this.

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?

I'd go with #2, but don't automatically increment the y values. Instead go left/right, if they are going down, gravity should pull them down, but if they collide with an inclined polygon, do a collision check... If the character is within the polygon, push him up to the top so he isn't anymore.

I have struggled with this sloped platform problem for a long time. I firmly believe that nobody will be able to provide you with the solution unless they know exactly what method needs to be used and how to implement it.

here is my feeble attempt:
http://code.markmusicproduction.com/sloped/p1.htm

this also might help:
http://www.harveycartel.org/metanet/tutorials/tutorialA.html

Part 6 is missing and refer to part 5

Anyway, OpenLayer handles the collision between Line and Polygon for you, so you don't have to worry about that, and you can focus on the actual implementation of your idea.

Yeah, I still haven't finished it... cause I haven't figured out how to do it!
That tutorial above is as far as I have gotten.

Unfortunately Openlayer doesn't calculate any reactions to a collisions.

Latest OpenLayer SVN compiled for MSVC8

It's just the release build for now, I messed up the debug one and haven't got around to doing it again properly...

Matt.

Are you suggesting that rather than moving the player to the new coordinates that it might be better off to use OpenLayer's line method to make sure the player doesn't collide? Of course, you would still need check the player against other polygons in the area with the full collision rect that represents that player.

Yes, that makes sense. Wouldn't a rough check of if a slope is too steep to climb be something along the lines of checking a point up and to the left/right that is 45° from the player? Or, I suppose, you should move the player to the left/right whatever amount, then move them up a max of speed pixels checking for collision. If they still collide after that, then it must be too steep or a wall.

Oh, and thanks for the OpenLayer SVN, Matt Weir.

Yeah, for that, you could supply a current_position and a current_movement_vector for the map to use.

You should also consider sliding effects (because it'll be a part of your algorithm) - including allowing the player to run up a slope even slightly when he is running fast.

[edit]
I'm actually thinking that you should explicitly flag slopes as 'steady' or 'sliding'...

Just check for a collision with the Collision class from OpenLayer between the player movement segment and the ground polygon. If one occurs, get the colliding segments of the ground polygon (again integrated into OL) and the point of collision.

To adjust the speed of the player against the slope, it's actually quite easy. I don't remember the exact method I've used but you need to take in account the angle of the ground segment.

You can do something like:

newSpeed = actualSpeed - (actualSpeed * factor between -1 and 1)

Where the factor depends from the ground angle angle between -90 and 90
--> factor [ -1 to 1 ]

e.g. coming from the bottom left

slope with this shape "/" is 45 deg (loose speed)
slope with this shape "_" is 0 deg (horiz, no change)
slope with this shape "\" is -45 deg (gain speed)
slope with this shape "|" is 90 (speed = 0)

So, you are suggesting the 2nd method I mentioned before in combination with this? That is, not the sin/cos based movement.

You'll need sin/cos somewhere. Whether it's calculated when the movement vector changes direction, or when you are updating the picture (using an integer, angle).