I'd like to draw a custom polygon and fill it in. I'm using al_draw_prim like so:

for(int i = 0; i < 4; i++) {
    //some stuff to define realX and realY - it makes a square
    backgroundColor_ = al_map_rgb(255,0,0);
    v[i] = { .x = realX, .y = realY, .z = 0, .color = backgroundColor_ };
}
al_draw_prim(v, NULL, NULL, 0, 4, ALLEGRO_PRIM_LINE_LOOP);

This draws an outline of a square, but I'd like it colored in. Any thoughts?

Since: 5.1.0

Thanks, but I'm on the latest stable build (5.0.10)

No, I'm drawing all sorts of polygons. I suppose I COULD do triangles, but that would be a lot of annoying.

Can I do something like load a 1x1px bitmap of the desired color and stretch it over the whole prim?

Ok, we'll see what happens. Thanks.

In that case, be very careful if you continue to use al_draw_prim() at any step of the way. It's very expensive in terms of CPU overhead to call and calling it more than just a few times per frame of your gameplay could kill your framerate. On the flip side, you can prep everything you intend to draw into one massive array and just draw that with a single al_draw_prim() call.

You say this all the time, but I've never seen any profiling to back it up.

I remember doing some tests as well, and the setup overhead of the al_draw_prim code is rather high, and most of it is spent in the opengl driver itself validating GL state. It's a known GL problem, one which we can try and mitigate by reducing the amount of state that the primitives addon touches, but it'll probably still be a problem.

The current way to reduce overhead in GL is to change as little state, and do as few individual draw calls as possible. Usually that's done by batching as much data into a single buffer object as you can and dispatching some gl*Array/gl*List calls.

I have to admit that its been a long time since I last did my test, the primitive performance may have improved.. but I was drawing a lot of circles. It was kinda slow

But here's a couple tests on my laptop:

Original code:

moose@balsa:~/projects$ ./prim-test 100000
Primitives: 0.480269
Allegro: 0.550363
Ratio:0.872640
moose@balsa:~/projects$ ./prim-test 1000000
Primitives: 4.643804
Allegro: 7.965119
Ratio:0.583018

Heald drawing:

moose@balsa:~/projects$ ./prim-test 100000
Primitives: 0.480745
Allegro: 0.028070
Ratio:17.126648
moose@balsa:~/projects$ ./prim-test 1000000
Primitives: 4.584236
Allegro: 0.255358
Ratio:17.952193

Not exactly no appreciable difference. I'd try it on my nvidia gpu, but the nvidia drivers are currently broken on linux with this gpu.

No, but then I didn't look all that closely at the code. I assumed the higher the number the slower it was. And with held drawing, the primitives number is clearly bigger.

I'm guessing you're complaining that with held drawing it isn't an "apples to apples" comparison. It doesn't need to be though. Setting up al_draw_prim to batch all of the calls would be rather annoying

I'm not trying to put you down or anything. You seem to be touchy on this subject. When people try using the primitives functions, they do a small test and draw X number of shapes. Then they see that they can only draw say a few thousand and go "wtf?". That is the "slow" we're talking about.

And just because something is "the fastest available" doesn't mean it isn't slow

And, as I mentioned earlier, it isn't allegro's or the primitive addon's fault. It's a GL thing.

A bunch of individual bitmap draws is pretty darn inefficient too. We do say it is slow it's said over and over again, if you do call it a lot, make sure to use an atlas and held drawing, or even batch stuff up in buffer objects to use gl*Array's.

I still think you're taking this personally. It is not a slight against you, or allegro. It's just how this kind of usage is. Lots of individual drawing calls is slow. period.

You guys are awesome. On an unrelated note, any word on when 5.1 stable will come out? (Cause you know.. still want to fill in my primitives).

Just so you know, just because 5.1 is called unstable doesn't mean it is unusable. 5.1.8 is perfectly usable, and if you want filled primitives I don't see any reason not to use it.