Since we're getting closer to christmas hack and there are many requests for platformers I was thinking about some way how to do platformer without tilemap. The good way is to use polygons, because then you can make terrain as you wish and it will be quite simple to check collisions and make moving - also I know at least one game which uses polygons for this type - SOLDAT. So I was thinking further. The main idea is that map will contain non-convex polygons - theese will represent not passable terrain. Each will be described by number of vertexes and of course the texture - and this is a tricky bit.
One way how to handle this is to have entire level as one bitmap described by polygons. So polygons are there only for collision detection. But because I want to spare disk space I prefer the other way. You'll have all textures in datafile, each will be say 64x64 px. in size. Then in the program you want to fill the polygon with this texture. And now comes the question: what is the best way how to do it?

I've only come up with idea that while loadingg the level I generate a bitmap for each polygon. Then draw this polygon using primitives onto this bitmap filled with texture. Then I'll use floodfill to make parts which I don't want to see transparent (using magic pink). But personally I don't like this way because it will dumb memory with bitmaps and I think there should be some more honorable way.

The thing is that I don't want to use OpenGl. I'm a bit "oldschool" in this, so I want to do something like that using 2d functions to map a texture onto a polygon.

OpenGL calls aren't as portable as the Allegro software drawing functions. And for once, would people just lay off of a guy when he want to use Allegro's own drawing primitives instead of OpenGL? Jeez! Allegro's stuff is already there, easy to use, and it works.

There's no doubt that OpenGl is powerful (and I know that I can do even tilemap with it), I want to learn it but as Paul said - Allegro is here and ready to use. The second reason is: how would you make it few years ago when OpenGl didn't existed? And even OpenGl must do it somehow inside some MapTetxtureToPolygon function.
EDIT: There must be way how to do it only with Allegro or Window GDI.

OpenGL is perfectly suited to what you are are trying to do, while Allegro is ill-suited. If you want something that is uglier, slower and just generally nastier, then go with plain Allegro ...and you're welcome to call it 'old school' if that make you feel better.

It's called texture mapping and it's what OpenGl excels at.

Flad: from morning I was asking myself: "If I ask, how long will it take till someone mention OpenLayer?" - don't take it personal, I don't have anything against it (I'm just too lazy to use it ). Yeah I must say that I saw those screenies - really nice. But anyway, can we now forget about OpenGl, DirectX, any other platforms and Allegro addons and make a discussion about ways how to make it in plain Allegro? Or some theory about that? Note: OpenLayer must achieve it somehow too.

EDIT: That way I posted above was the first thing that came up to my mind. Make a screen sized temp bitmap -> throw there texture -> draw polygon (using line and magic pink) -> floodfill the are outside the poly with magic pink -> clip the result to size of polygon -> save it to memory.

Right, Firefox 1.5 has once again thrown away one of my posts and I'm exceedingly angry about it. So I'm going to be very short.

For the Allegro Demo Game, I used a full polygon level. Polygon drawing was achieved with the "polygon" function and a drawing_mode of DRAW_MODE_COPY_PATTERN, with the "texture" passed as a pattern and an offset equal to the amount by which the level is scrolled. This is almost certainly the fastest way to produce a 2d polygon based level with software Allegro.

That's not true.
Ok seems like good idea to use allegro polygon functions
Now I'm just curious how that texturing works.

I suppose that when I try to do it myself like I did with vectors (now I found that vector namespace in STD is not vector related ) it will be pretty slow, not because I'm dumb but because putpixel would slow it. Note that my vector class is fast.

Thanks for the code. I think that I'd be able to write my own code for polygon filling.

TH, that's quite what I expected, thanks for the clear example. By the way:

y3 ^= y2; y2 ^= y3; y3 ^= y2;
// Is usually slower than using a temp variable:
int temp = y3;
y3 = y2;
y2 = temp;

because the compiler will optimize out the temporary variable.

I tried something like that late last year that I picked up again sometime this spring (flad may remember). I dropped it because of memory issues with the pathfinding.

It rendered the polygons by using a mask. First, I filled a buffer with the texture. Then, I filled a mask-buffer with an arbitrary place-holder color. Then, I used allegro's polygon drawing routines to draw my polygon onto the mask using the whatever magic invisible color (pink/black/whateva'). Then, I drew the mask over the texture buffer. This left the polygon, surrounded by the place holder color. Fill all the placeholder color in with the magic invisible color and wa-la! A rendered polygon. I thought it was clever at least .

If you're interested, check it out! Complete with editor and everything.
~clickity~
and a readme
~docClickity~
(i'm particularly proud of the scripting engine )

If you have any questions I'd be happy to answer them.

Just a note, theres a small memory leak from the pathfinder.

oh, and credit goes to jim sinha for the view-shrowding. turn it on and off with F1

edit: and yea, this is an abandoned project, I know the code is kinda hard to follow. And I know its not totally optimized, or the best way to do this.
edit2: and i may get a delayed start on the xmas hack, was up pretty late working on this post

Someone else may say different, but I wouldn't worry too much about the size of the bitmaps.

The only thing I would recommend is that when designing your levels, keep the bitmaps smaller than the size of the screen. When you play my example, you'll notice it kinda drags. Thats because it uses huge bitmaps, even though much of the bitmap isn't on the screen. My example doesn't draw bitmaps that are completely off the screen, but if theres a massive bitmap and even only a pixel of it is to be drawn, it'll attempt to draw the whole thing. And if you're worried about size you could store your level in pieces, instead of one big chunk, then load only the part that is immediately needed. I'm not sure as to the specifics of speed and blitting large/small bitmaps though, maybe someone else can fill in the details.

You can also just render all of your polygons, and store the rendered image. Then, just blit the polygon. Unless its dynamic (like rotating, or the texture scrolls), then you have to render it ever tick. You may be able to store all possible forms of a polygon. Out of experiences from my attempt at this I'd recommend keeping the shape of your polygons static, as it makes pathfinding and collision detection..umm..tricky when they're changing.

And thank you, thats the first kind word I've had from a regular:D