I'm trying to draw a non-rotated bitmap as a trapezoid, where the top and bottom have different sizes.

I currently do this by drawing it line by line, scaling each row using linear interpolation, but it's a bit slow with larger bitmaps.

Is there some way I can do it more efficiently using allegro 5.0.10? Thanks

You could simply "tilt" it as a 3D quad, A4 would probably do it fast enough.

How exactly would I do that? I'm not using OpenGL.

I'm trying to find a ten year old example hidden somewhere in this terabyte drive, please stand by.

[EDIT]

Found it (and had to tweak it a bit), it's in the paperclip along with an image file.

I just tried it and it works nicely, but I'm using 5.0.10, not 4. Is there a way I can use the triangle3D function in 5?

al_draw_prim lets you draw whatever shape you want by providing verticies and a texture. So you could map your texture onto 4 verticies where the 2 top ones go inward on the x axis to form a trapezoid.

https://www.allegro.cc/manual/5/al_draw_prim

Holy carp! I read the original post as saying "Is there some way I can do it more efficiently other than using allegro 5.0.10?"

You can't get trapezoids like that using 2D coordinates only. al_draw_prim will work, but 5.0.10 does not have a good mechanism for the necessary perspective transformation... although maybe sticking a perspective transformation into al_use_transform will work.

Come to think of it, he didn't specify what the trapezoid dimensions should be. Just rotating a quad would involve trigonometry to get the outside edge sizes at least.

I programmed my own 3d coordinates that get converted to 2d coords to get the 4 points.

If the function lets me draw a shape in 3d I can reprogram it taking advantage of that, if it's 2D I can still draw it using my points and a trick to keep proper perspective but it won't be as efficient.

I'm trying al_draw_prim, but I'm having a bit of trouble getting it to render anything

I can't get it to work either.

I tried for a bit, and I can't get it to work with 5.0.10 in pure Allegro. Works like a charm in 5.1 though. I'd either upgrade, or hack it up using OpenGL.

Please post the code, I'm using 5.1.7. I just stuck the example in the docs in, and tried altering the z if there was a viewing frustum I didn't know about and couldn't get it to work.

Yeah, that worked, I didn't have the transforms and stuff. Thanks!

Works beautifully for me as well. The thing is I'm using features in 5.0.10 that aren't available in 5.1.7.

Is it possible to take the primitives addon from 5.1.7 and use it with 5.0.10?

I'm not sure what you mean by this... what features would those be? Is 5.1.7 behind 5.0.10 somehow? EDIT: Oh I guess it's possible, 5.1.7 is from May and 5.0.10 is from June...

It's not the primitives addon that's at "fault", it's the core. The function that you need (al_set_projection_transform) is part of the core.

Whoops, I thought some of the blend modes weren't available in the 5.1 branch for some reason...

Anyway, is there a chance al_set_projection_transform and the rest will be added to the stable branch any time in the near future?

It's not impossible (quite a few of the 5.1 features were backported to 5.0) but it seems unlikely... but who knows. It's really up to Peter Wang who does the backporting.

Does al_draw_prim do nothing in 5.0.10? Could it be possible that it requires some type of transformation to make it visible on screen?

As I said before, this has nothing to do with the primitives addon and everything to do with Allegro's core. Maybe it's possible to hack something up using the transformation utilities available in 5.0.10... but I wouldn't bet on it.

In other words, if you used your own 4x4 matrices, and used them to mathematically transform the vertices, it'd work?

5.0.10 has an unchangeable orthographic transform for the projection matrix labeled P, and a user customizable transformation T. The vertices are transformed by a product of P and T. The goal is to create a perspective projection matrix J by modifying T. So, it's just a matter of solving this matrix equation, J = T P for T. I don't feel like writing up a 4x4 matrix inversion necessary to do that... the reason why we add features to 5.1 at all is to make this stuff easier... finding workabouts for this in 5.0 kind of defeats the point, eh?

I'd like to know how and why stuff works from first principles, rather than rules of thumb. It was almost a rhetorical question.

[EDIT]

It makes no difference if you come up with an algorithm to solve the answer to life, the universe, and everything if nobody knows about it, e.g. isn't covered in the documentation. I tried the example in the docs with copy and paste, and it didn't work.

There are no rules of thumb in my post, just simple linear algebra.

Which example is that? al_draw_prim one works just fine.

The example I'm talking about is on the al_draw_prim page.

//For example to draw a textured triangle you could use:

ALLEGRO_VERTEX v[] = {
    {.x = 128, .y = 0, .z = 0, .u = 128, .v = 0},
    {.x = 0, .y = 256, .z = 0, .u = 0, .v = 256},
    {.x = 256, .y = 256, .z = 0, .u = 256, .v = 256}};
al_draw_prim(v, NULL, texture, 0, 3, ALLEGRO_PRIM_TRIANGLE_LIST);

it doesn't say anything about any dependencies on transformations etc.

[EDIT]

No doubt these shortcomings will be hammered out in time, it's just that the developers already know so much about how to use A5 that they forget to mention lots of things in the docs etc. I'll stick to OpenGL, since there's so many gigabytes of info available already, not counting the other advantages.

There is no special dependence of that code on transformations beyond what is common to all drawing code. You'd get no farther in OpenGL if you didn't set the proper GL_PROJECTION matrix either.

Anyway, I already posted the solution... so I'm not sure what the argument is anymore.

But there are thousands of examples to show you the way, from those ancient NeHe tutorials to the OpenGL docs at opengl.org. You guys are creating something new from scratch as far as I can see.

I don't think you'd have an easy time finding the solution for OpenGL either. It's just a very specific task - nothing that should be in the documentation. But once you know that the problem can be solved with a perspective transformation and know the transformation you want to use, both OpenGL and Allegro should have enough documentation to implement it.