next »

[Yandros]

First of all please don't blame me if this topic has already been discussed - actually I searched the forum but did not find anything really specific to this topic...  
Position and size of XMPlay's windows is saved when closing them - great feature, no doubt.

Using a dual-screen configuration, the sad thing is: this only works on my primary monitor. So setting up XMPlay on the secondary monitor (where I prefer XMPlay to rest) is useless, as after restarting XMPlay it shows up on the primary monitor again...  

I am just curious if this is os-/driver-dependent or if it could be fixed within XMPlay?  

Is anybody else experiencing this behavior?
Does it work on someone's secondary monitor?

Thanks for your feedback!

Yandros

[Greebo]

Aye, it won't save the secondary monitor position on my setup.

[Dotpitch]

xmplay stores it's last position in the registry (HKCU\Software\Un4seen Developments\XMPlay2, WindowX and WindowY). if these values are on the primary monitor, then i think xmplay writes the wrong resolution (it count from the top left of the second screen instead of the first). can't try it myself, i've got only one monitor .

[Yandros]

xmplay stores it's last position in the registry (HKCU\Software\Un4seen Developments\XMPlay2, WindowX and WindowY). if these values are on the primary monitor, then i think xmplay writes the wrong resolution (it count from the top left of the second screen instead of the first). can't try it myself, i've got only one monitor .

Hi Dotpitch!

Thx for the registry hint.

Just played around a bit and discovered the following X,Y-values were stored when closing xmplay while located in the topleft corner of each screen:

	PRIMARY	SECONDARY
WindowX	| 0x00000000 (0)	| 0xfffffc00 (4294966272)	|
WindowY	| 0x00000000 (0)	| 0x00000000 (0)	|

Probably should show my monitor arrangement...  

+-+ +-+
|S| |P|
+-+ +-+


Launching xmplay with the SECONDARY values stored in registry, it just settles itself at 0,0 - i.e. topleft corner of primary screen.  

Compared to another app also storing X,Y in the registry, the values seem to be correct, because the other app restores correctly where it was before, regardless on which screen...

Appears to be a problem of xmplay not handling those values correctly... what do u think?

[Dotpitch]

well, it stores the the values right, but it reads them wrong...small mistake . looks like xmplay is trying to place itself at [0,4294966272], but it can't find that (it's off the first screen, so the value "must" be corrupt, or something) and opens at standard 0,0.
btw, i don't think it's weird it does that, cause 4294966272 is a pixel that would be (at least, on my screen) 1342 km away...i'd expect something like [0,1025] with two 1024x768 screens, but i don't know how your windows reacts on a secondary screen. xmplay doesn't like it, that's for sure

[Torkell]

I've noticed that XMPlay dislikes multiple monitors, tho it affects people who have the secondary with negative co-ordinates more...

You can either use EnumDisplayMonitors and GetMonitorInfo, or GetSystemMetrics with SM_C?VIRTUALSCREEN. Bear in mind that these APIs and parameters have only been around since 98 and 2k, but you can use a stub header (multimon.h) that does sensible things on 95 etc.

[Torkell]

&hFFFFFC00 = -1024

Not everything uses unsigned ints, folks

[Dotpitch]

  didn't know that Boggy! but why doesn't xmplay realise that?

[Yandros]

&hFFFFFC00 = -1024

Not everything uses unsigned ints, folks

Regarding my monitor arrangement (both screens running at 1024x768) this value seems to make sense... (thx for that hint BoggyB )

Given the upper left corner of the primary screen is position 0,0 the upper left corner of my secondary screen located left of primary (see above) would logically be -1024,0.

So maybe xmplay just does not expect negative coords or treats them incorrectly...  

Will try to swap screens and see if it works the other way round...

[Ian @ un4seen]

When XMPlay is loaded, it checks that the stored window position is within bounds of the display. So that if the user has changed the resolution since the last time XMPlay was loaded (for example), XMPlay won't be off the screen.

I've never tried XMPlay on a multi-monitor setup, so it doesn't take that into account in it's boundary checks... guess I'll have to give it a go some time

[Torkell]

When XMPlay is loaded, it checks that the stored window position is within bounds of the display. So that if the user has changed the resolution since the last time XMPlay was loaded (for example), XMPlay won't be off the screen.

I've never tried XMPlay on a multi-monitor setup, so it doesn't take that into account in it's boundary checks... guess I'll have to give it a go some time

I'd suggest using GetSystemMetrics, as that way if it's running on 95/NT you just feed it different parameters. That'd work for screen resolution changes, but it wouldn't handle irregular shapes (two screens at different resolutions would have some dead space). To cope with that, you'd need EnumDisplayMonitors and GetMonitorInfo.

I'll happily test any multimonitor versions, as I've got a dual-display setup.

[Torkell]

didn't know that Boggy! but why doesn't xmplay realise that?

'cause it's -1024

[Yandros]

When XMPlay is loaded, it checks that the stored window position is within bounds of the display. So that if the user has changed the resolution since the last time XMPlay was loaded (for example), XMPlay won't be off the screen.

I've never tried XMPlay on a multi-monitor setup, so it doesn't take that into account in it's boundary checks... guess I'll have to give it a go some time

Thanks for clarifying that one.

I'd suggest using GetSystemMetrics, as that way if it's running on 95/NT you just feed it different parameters. That'd work for screen resolution changes, but it wouldn't handle irregular shapes (two screens at different resolutions would have some dead space). To cope with that, you'd need EnumDisplayMonitors and GetMonitorInfo.

I'll happily test any multimonitor versions, as I've got a dual-display setup.

I would also willingly assist in testing new boundary checks - just let me know...  

Note:
Switching from "normal" to "shade" mode or vice versa also moves XMPlay back to the primary screen.
Guess this is related to the same boundary checks...

[Rah'Dick]

* Rah'Dick is willing to assist, too, since he will soon have a three-screen setup (2x Monitor, 1x TV)

[Torkell]

* Rah'Dick is willing to assist, too, since he will soon have a three-screen setup (2x Monitor, 1x TV)

*drools*

All you need to do now is to hack UT so it'll run on all three at once. Surround vision gaming!