I'm working on a little project using C++ and Allegro 5, my question is

Is there a way to draw antialiased primitives to a bitmap using Allegro 5? I mean I'm using this function

to draw a cicle and a triangle (testing purposes) over a target bitmap as shown, on the project display options I have

to enable antialiasing, the problem is that all primitives rendered on the gameBuffer have jaggies but the primitives rendered off the gameBuffer are perfectly smooth, how can I solve that? Or It's there a way to do what I'm doing and get smooth primitives?

Yes, it can be done using al_set_new_bitmap_samples before creating your bitmap. Unfortunately it is not currently implemented for Direct3D, so you'll need to force OpenGL via the ALLEGRO_OPENGL flag in al_set_new_display_flags. As this feature is experimental, you'll need to define ALLEGRO_UNSTABLE before including Allegro's headers.

I'm trying to implement this but it seems that it's not working or at least that's what I feel, I have this:

Obviously I have more code in between but nothing that matters to this issue
I can share my entire code, I don't have any than the main and the function to draw to the bitmap

al_set_new_display_flags(ALLEGRO_OPENGL); al_set_new_display_flags(ALLEGRO_WINDOWED); al_set_new_display_flags(ALLEGRO_RESIZABLE);

Only the last call to al_set_new_display_flags is having any effect. You're overwriting the value you just set. Combine the flags using a bitwise OR.

al_set_new_display_flags(ALLEGRO_OPENGL | ALLEGRO_WINDOWED | ALLEGRO_RESIZABLE);

I'm working on testing this on my machine at the moment.

Anti-aliased primitives drawn to non backbuffer bitmaps appear to be working for me :

Upper left corner is backbuffer drawing, clockwise from top right is 8, 4, and 2 multi-sampled bitmaps.
{"name":"611193","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/0\/80d807e5b7c2fa6c47362aa89008f0d6.png","w":1202,"h":941,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/0\/80d807e5b7c2fa6c47362aa89008f0d6"}

I didn't know that display flags must be combined, It worked well but it's so slow compared to rendering directly to the backbuffer.

is there a way to do the same thing without the heaviness? if there's no better way I think I'll stick to a simple fixed-size window with the resizable flag

with "is there a way to do the same thing without the heaviness?" I mean, having a buffer where I can render everything then render the buffer to the middle of the display, this way I can resize the buffer without affecting the buffer aspect ratio?

[edit]
I've been testing everything and it seems that OpenGl is slowing the rendering and input for some reason, my OpenGl version is 3.3 but my graphic card is NVS 3100M with 512Mb

This is actually my favorite Allegro feature. To me, it makes Allegro complete. Allegro can do anything.

The key here is that now I can render to offscreen surfaces with the same quality as the display bitmap, and use that to generate cool effects. An immediate example that comes to mind is a screen transition that composites between different states in the game, like menu and gameplay.

Here's a full feature list of your card:

http://feedback.wildfiregames.com/report/opengl/device/NVS%203100M

It should be fast enough to do some stuff. Make sure your drivers are current. But it has a whopping 16 CUDA cores. (read: very few) Is this Windows or Linux?

Run glxgears if you're on Linux, or some other 3D apps. Can you run anything fast?

Also, use _REQUIRE not _SUGGEST because you want to be SURE that the settings you're testing are turned on. Allegro intentionally will fail to create the display if the required setting fails, so you know whether it's using it or not.

I know, I was hoping to use this feature, it really makes allegro a full graphics library for multimedia stuff but I'm not able to use it, or at least that's the issue now.

my drivers are up to date (Windows 10), I tried forcing OpenGl without the antialiasing and it keeps running slow for some reason.

I ran GFXBench GL and the results were between 20 - 40 fps on the tests done, I have to add that I normally use 3D packages to do some stuff (3d modelling/animation/texturing/rendering) with no problems but It seems that OpenGl with Allegro 5 doesn't work for me for a reason.

Have you tried running the ex_multisample.c and ex_multisample_target.c
example programs?

It is generally true that OpenGL is a little slower than DirectX on Windows, but not to the extent that it's unusably slower. Aside from the drivers (which I take are fine), I'm not sure what could be wrong.

Nope, I ran the example given by Edgar Reynaldo and ran slow too
I'll try to tun these examples to see if it changes something

It's not the rendering that is slow (or at least that's what I think), in the program I made, I was drawing a circle over the mouse positions but the rendering was delayed by 2 - 4 secs, so, whenever I moved the mouse the rendering was at the same speed of my mouse but delayed some secs, even closing the window was delayed by the same fraction of time.

Anyway I changed my project's main architecture to be just a scalable window but if I can get this to work I'll switch it again in the future, I'll try the examples above

Oh, I know what it is. Your event queue is getting clogged up and laggy by timer events. You can fix it by dropping sequential timer events with al_drop_next_event.

See these lines from the AllegroFlare Framework class as an example.

If my example ran slow too, then there is something else wrong, because my example processes all events as soon as they occur.

There must be something wrong:( with my computer then, just enabling ALLEGRO_OPENGL flag delays the redrawing, I'll try "al_drop_next_event" as suggested to see if it changes something.

You can also try updating your graphics drivers to the latest version and see if that fixes it. It can often be the problem.

I guess It's my GPU or something that doesn't handle OpenGl

Which is why updating your graphics drivers might fix it.

That does sound like a really horrible result...

From here:

https://gfxbench.com/result.jsp

There are Intel integrated graphics cards in that list that get >25 FPS. That's around a GTX 460 mobile.

Is your "NVS 3100M" a Quattro? Because that same benchmark shows a Quattro 3100M at 62 FPS. So if that's the case, it's possible your card may be throttling itself from overheating or something.

I don't know. Seems like you need to do some further testing on your system to see if Allegro is actually running slow, or it's just running as fast as can be expected.

A quick benchmark to test is in GPU-Z. It's like the popular CPU-Z program, and it basically tells you a lot of stats about your card as well as whether the clock frequency is dropping. It includes a quick benchmark setting. If say, your card is benching slower than my lowly old chromebook with integrated graphics, then something is definitely wrong.

https://www.techpowerup.com/gpuz/

There ARE rare driver issues with cards that nVidia / et al have fixed in the past where certain programs will run too slow because the card doesn't recognize an app properly so it doesn't leave "low power" state and ramp up to full clock speed. But I thought they had fixed all those issues. (And also, the opposite, where games like Starcraft 2 would actually destroy videocards because the drivers were incorrectly having them run hotter than supposed to back in 2010. Lulz.)

You said you were using Windows 10, but are you using the MOST RECENT drivers FROM NVIDIA, or just stock Windows 10 drivers?

Guys I hadn't tried this until now, as I said before, my drawing was fine (I mean, no lag or low framerate) with ALLEGRO_OPENGL enabled but the input was delayed a bit, It seems that this is the solution to it, I won't be able to test if it works fine with al_set_new_bitmap_samples() but enabling OpenGl with the code mentioned above my program runs fine, I'll try to test with my initial project to see if this is the real answer to all this issue and save this post for future refferences.

BTW my drivers weren't up to date but this didn't change anything in my program, I tried with both drivers (old and new) and the result is the same without al_drop_next_event and the code in the link.

this is the only thing my program has changed and the ALLEGRO_OPENGL flag obviously.

[edit]
Ok guys I've just tested with my initial project settings and everything is working just as expected, I really appreciate your help, you are such a beautiful community to work with <3

You shouldn't need to drop any events. Usually, you just start and stop your timer when you don't want it to run.

Show your old and new event loops, if you would, I'm curious now.

Well, your first example ran slow too for some reason even though I know you did handle the events with no errors, here is my code for the main loop

the only thing it changed in the whole code it's the "nextEvent" stuff shown in my previous reply.

The thing is, my example drops extra timer events automatically. It only draws once, even if there are multiple timer events. It just counts them all as one.

Edgar and you all guys, I've been lying to you and I feel so dumb now but it's good to have my dumbness here this way people can learn from my mistakes (I don't think there's someone out there that can make more or the same amount of mistakes than me but ok), your example (Edgar Reynaldo) never ran slow, it took a while to execute but runtime was never slow neither had had the input delay, although I thought it was running slow due to the time it took to show something on screen (5 secs maybe?) my code, the one that had the input delay (event queue clogged by the timer events as Mark Oates mentioned) took the same amount of time to show my drawings on screen, therefore, I thought your example had the same issue but I was in a huge mistake, I knew my example had an input delay because the circle I was drawing on the mouse positions had a delay but I never tried the same with your example until now and guess what? yup, you example runs smooth with no delays nor lag and the circle drawn to the mouse positions moves as fast as I move the mouse cursor so... I actually don't need the "al_drop_next_event()" procedure I just have to have an event loop to iterate while the event queue has something inside, this way I won't have events left on the queue making every iteration bigger and bigger to iterate through.

As I said before, you are such a beautiful community to work with and I really appreciate your help and patience with me and my dumbness.

So then, I'm not sure what delay you're experiencing. Startup? It doesn't display anything for a few seconds? Can you give an example program that does this? With debugging symbols for gdb?

It may be a little slow to resize the window, due to recreating the bitmaps on each resize, but drawing normally should be pretty quick. The texture changes don't help.

Nothing to worry it just takes a while to start (my pc is slow with OpenGl flag), the input delay I'm talking about it was in my previous code that clogged the event queue, the resizing it's fine, with no delays or slowness just the startup takes some seconds to start, I'll try to create two examples, one with my old game loop and another with the new one.