Hyperion Entertainment Message Boards

Yeah, I can see it may not be quite as simple.

I tend to think in single-screen terms because I almost never use more than one (big) screen myself.

But each screen is created with a certain screenmode of a certain monitor definition, right? So in theory, if we could make "something" detact that the (physical) monitor has changed its native resolution (swapped x and y, specifically), we'd "only" need that "something" to go through open screens with a mode from that monitor and switch its screenmode to the corresponding one.

If you change the screenmode using the Screenmode prefs editor, IPrefs (?) takes care of closing the screen and reopening it in the new resolution, including all its windows (if possible). I guess it should do the same in this case.

I know, I am probably seeing things through hazy, rose-coloured glasses .

Best regards,

Niels

Thanks, guys.
Now, here's more stuff.

When a screen is closed, caused by a resolution change (which is in fact the swap of w and h), it would certainly trigger a screennotify msg to the affected applications, isn't it? Just like a re-open of the Workbench screen would push.
So the app's windows should iconify or hide or triggered re-made (forced) to response to the screen's resolution change.
Otherwise the pivot transformation is halted until reset.

This is not an answer to the required backend from the driver side, sure.

I don't pretend to be an Intuition or a Graphics expert, but as far as I can see, you can't change the width x height values of a screen. In order to change the aspect ratio of a display, you would have to close the screen and reopen it in the new width x height.

Of course, you don't have to do that to rotate a display. Each and every application with an open window can be iconified, then un-iconified with new width x height values (as you suggested). The only difference from what you said is that it has to be at the window level, not the screen level (if my reading of the docs is correct).

Of course, we still need a trigger to start this process...

Well, of course the screen would have to be closed and re-opened with the new (swapped) dimensions. That was what I actually meant above when I wrote "switch its screenmode to the corresponding one". Sorry for not being more precise.

I believe that is also what WB does when a new screenmode is selected, right?

Best regards,

Niels

Yes, i might have been unclear with my pronunciation.

A change in resolution will need a screen to close and re-opened; and in this case, the reason to do this is also to swap x and y axis.

And there is a mechanism to notify any open apps on that screen, iirc, called screennotify?

So what is needed is a mechanism in the gfx driver to recognize signals from the connected display that indeed something has changed regarding the aspect ratio or resolution.

HunoPPC's Final Burn Alpha http://hunoppc.amiga-projects.net/conte ... ws-32-bits already supports rotated monitors. However application independent support would be fine, automatic recognition is not necessary. My Zalman M220W is waiting