Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » Allegro Resolution Headache

This thread is locked; no one can reply to it. rss feed Print
Allegro Resolution Headache
Felix-The-Ghost
Member #9,729
April 2008
avatar

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 ;)

==========================
<--- The ghost with the most!
---------------------------
[Website] [Youtube]

Gassa
Member #5,298
December 2004
avatar

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

Bruce Pascoe
Member #15,931
April 2015
avatar

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.

SiegeLord
Member #7,827
October 2006
avatar

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.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Bruce Pascoe
Member #15,931
April 2015
avatar

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

SiegeLord
Member #7,827
October 2006
avatar

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).

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Chris Katko
Member #1,881
January 2002
avatar

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.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Bruce Pascoe
Member #15,931
April 2015
avatar

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...?

MiquelFire
Member #3,110
January 2003
avatar

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

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red | +Me
Windows 8 is a toned, stylish, polished professional athlete. But it’s wearing clown makeup, and that creates a serious image problem. ~PCWorld Article

Mark Oates
Member #1,146
March 2001
avatar

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.

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. :-/

SiegeLord
Member #7,827
October 2006
avatar

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 :P.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Mark Oates
Member #1,146
March 2001
avatar

SiegeLord said:

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 :P.

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.

Go to: