Although this happened a few days ago, I thought I'd share perhaps to prevent anyone else from going through the same thing.

I spent over an hour double checking my code and having the program report the dimensions of the monitor and the window created. Previously it would auto-detect and fit within this area, and also center the window on the screen.

What was happening was everything the window created was too large. The content would go off-screen, the window wouldn't even center itself correctly anymore, and the reported window size was inconsistent with the actual dimensions when I took a screenshot and measured. It was like every value pertaining to x/y coordinates was multiplied.

Turns out that's exactly what the problem was. I had set up a new monitor to output 1080p and had unwittingly checked Windows "Make text and other items larger or smaller" and it turns out that applies some kind of transformation matrix over everything -- the Allegro program didn't even realize it, but some other programs seemed to adjust to handle it better.

If I had to guess most gamers wouldn't use that feature, but it was still disappointing to have Windows bully Allegro like that. Or maybe Allegro was just sick of it and not taking anymore crap from Windows

I got hit by it already, too (forum post, bugreport). I do use the scaling (140-150 per cent) by default.

MS was forced to implement scaling like that due to too many programs not being DPI-aware and becoming unusable when the system is set to anything other than 96 dpi. So instead the window manager just runs the app at 96 dpi and scales it up to match the rest of the system (particularly important for 4K displays, where you pretty much have to up the DPI to make the system usable without squinting).

To fix this, you have to include a dpiAware flag in your manifest (I don't remember the exact details right now, Google is your friend). Once you do that your game should run at exactly the requested resolution.

Actually... I'm confused here. It seems that it works fine if the window created is small. Is the issue only when the window is huge?

I set my desktop scaling to 125%, and all the Allegro examples seem to function fine.

Did you try at 150%? I think 125% doesn't trigger the scaling behavior. At least that was the case in Vista/7.

With 150% and Aero enabled, I finally observed scaling. Nevertheless, the Allegro examples I tried still functioned fine, scaled or not (the 'not' achieved by adding a manifest).

I'm definitely interested in this issue moving forward. DPI-scaling is the future and we'll need to be aware of any complications with it when we go to distribute/sell our games.

Another issue that many libraries fail at is assuming RGB sub-pixel ordering for ClearType. I have a BGR TV and last year 1 in 5 programs assumed the wrong order and looked horrendous. Chrome, PDF readers, Steam, and more. Many of those are fixed now though, thank goodness.

I thought it was the operating system that handled ClearType rendering? So in that case you'd have to use the built-in ClearType tuner, individual apps have nothing to do with it I don't think...?

Only if the app uses the font engine of the OS does that happen.

Certainly. I've already run into complications with the retina display on my MacBook Pro. Mouse cursor placement positions are a little wack, resolutions are a bit complex with app bundles and all that.

I haven't sorted it all out yet.

I thought everything worked fine with retina displays on OSX... given how much time I spent on this issue on that platform, it should have the best support .

It's probably that I just don't know how to Do It Right™. The thing that I haven't really had time to investigate is that al_set_mouse_xy() seems to jump around.

I have a GUI knob and the expected behavior is that when you mousedown/drag on the widget, your mouse cursor will disappear (so you can see the values on the knobs) and the cursor will always remain at the center of the widget until you release the mouse. In Windows, the behavior was achieved by using al_set_mouse_xy() anytime a mouse axis event is fired, to reposition the mouse back onto the center of the widget.

Doesn't work in OSX (retina?) though; don't know why.