I am using the "standard" Allegro main loop code.

I set the timer to fire at 60 times per second:

m_timer.reset(al_create_timer(1.0 / 60.0));

Then, the main loop:

In my Game object is the render function, that gets called when the timer fires:

On Windows, no matter how fast I configure the timer, it refuses to fire beyond 25 frames per second. Or, am I missing something obvious?

On Linux, it works fine. Even in debug mode: 60 FPS, even for the render.

I am attaching a screenshot of it running in Linux. And I will add a screenshot from my Windows box after I reboot.

By the way, I am using Allegro 5.2.6

Edit1:
Attached screenshot from Windows.
Notice how the render FPS is only 25 / 26.
It doesn't matter what mode I compile it in, debug or release.

Edit2:
Attached another screenshot, showing that it stays the same, even when I set the timer to 6000 frames per second

Thanks for the tip!

I turned vsync off, and it still locks the trigger at 25.

Now I will figure out how to run fullscreen, and see if it's the same issue.

I figured it out!

It turns out that al_draw_scaled_bitmap is doggone slow.

I replaced it with al_draw_bitmap but that is not something I am happy with.

I am writing an old school raycaster, and my display buffer is 320 * 200.

My application takes a scaling factor which is what the window gets created with: width and height multiplied by the scale.
I am using a scale of four at the moment.

Is there any other way to scale that to fit the screen?

Here is the code that I left out from the original post:

I attached proof that it works, but it is obviously not acceptable for my application

Funny that al_draw_scaled_bitmap is working fine on Linux, what gives?

EDIT:

As it turns out, when I use al_set_new_bitmap_flags(ALLEGRO_VIDEO_BITMAP | ALLEGRO_NO_PRESERVE_TEXTURE); it works!

I was using ALLEGRO_MEMORY_BITMAP because I read that it was way faster when you are making use of direct pixel access, but apparently it isn't.

I am happy now! It works splendidly - move along
Also, 40 FPS in debug mode is rather nice as well, considering that my code is laden with STL and I am using Visual Studio ;p

Visual Studio is incredibly slow in debug mode when using the STL.
Even when setting _NO_DEBUG_HEAP to 1.
GCC is much faster

Edit:
What am I doing?

Well . . .
I am plotting pixels. Each frame I update the display_buffer, like this:

The "Pixelator" keeps a lot of pixels in buffers, and I use it to build the scene. I can copy, plot, draw, swap buffers, ... I am using it to write a raycaster. I got good results in SDL, SFML was too slow, and Raylib was nice, but could not provide what I need.
I landed on Allegro in the end, and I ported to code over in less than two days, and I think I have finally found a framework I can be happy with.
Funny thing, Allegro (with Djgpp) was what I started out with, back in the day.

My machine is not terrible, but certainly not top of the line: AMD Ryzen 3 1200 Quad-Core Processor 3.10 GHz, with 8 gigs of RAM, and sporting a GeForce GTX 1050 TI with (I think) 4 gb video RAM.

I will probably using Allegro threads to speed up the raycasting, maybe.
I will post about my project soon, when I have ported everything over and it runs properly.

Edit:
I am now on my Linux box. GCC runs this at 60 frames per second in debug mode.
So, blame it on VC for being overly burdensome with debug code.
I am not really worried. For now anyway

No, definitely not Code::Blocks, it doesn't cut it. I tried it, and it didn't impress me. I don't intend to bash it, because it is open source, and all. And choice is a good thing!
MinGW-W64 is great, but I prefer to use GCC on Linux, or - put another way - why GNU for Windows when you can GNU the real deal?

However, perhaps I will try and hook up Clang with Visual Studio. Thanks for encouragement

Edit:
I switched to LLVM (clang-cl) in Visual Studio, but - alas! - the Allegro Nuget packages are only configured for v141 and v142. A pity. I will have to look into that RealSoonNow, won't I?

Edit_Again:
I tried MinW-64, and is GCC 8 really the latest version? I can't use it because it doesn't fully support C++17. Unfortunately. Oh, I see that Msys has it.

The debugging environment in Visual Studio is still unmatched

Visual Studio 2013 - 2015 was bad. But I am happy with Visual Studio 2019.
With Nuget, using Allegro is as easy to get up and running as it is on Linux with CMake.

The dated WxWidgets interface of Code::Blocks is not something that will win me over. I generally prefer the native option on my platforms. So Visual Studio on Windows, or Visual Studio Code with CMake.
When I want to use GCC, I will do that on my Linux box.
KDevelop once in a while, but mostly VSCode. That editor is snappy

Edit:
That said, if I could afford to, I would switch to CLion. That is the best IDE for C and C++ programming, in my very humble opinion

I very much prefer to work in a console in Linux

Also, I have to admit that I have yet to dive into the mysteries of GDB. I am aware that it can be quite effective, provided you know what you're doing (which I don't).
I usually get by with VSCode which actually has a decent GUI interface to GDB.

If you have the money, CLion. I am sure they've got a trial that you can install. I found the Clang integration to be sublime!

I am switching between KDevelop and VSCode (not an IDE), but used to be quite happy with QtCreator.
I tried it recently, after having been away from C and C++ programming for a long while, and they changed their CMake support to the point of me wondering if they don't intend to support CMake like they did. I don't care for their native project format, so I guess I am also shopping for a decent IDE.

But, if you haven't tried KDevelop and QtCreator, please do.

Edit:
If Visual Studio solution and project files are an abomination, then Code::Blocks files are too. They are practically identical: simple XML files

Yes, they were awful once upon a time, but that was long ago.
Take a look -> https://github.com/jacmoe/pxlwolf

The whole solution consists of PixelWolf.sln, PixelWolf.vcxproj, and PixelWolf.vcxproj.filters.

That said, it is very atypical of me to commit any project files to a repository because I usually use CMake and treat those as generated build files. But not with Allegro as I use Nuget with it.

On linux I use gvim, with a custom .gvimrc for better readability.

I'm also having a script called gtab that open things inside a tab, and support multiple gvim instances. It will be uploaded to a git before the end of the day, because I like to share my shit. (Done: https://github.com/GullCode/gtabforgvim )

I have CodeBlocks installed but I'm not starting it a lot, and QTCreator / AndroidStudio because I need them for some projects that were already done with them.