IS:WindowSnapper - PIP on Speed

[zanthor]

So I've been playing with IS:WindowSnapper tonight and it's pretty damn amazing, I'll be converting my entire system over to IS before Lich King releases.

The swap between windows in shattrah from 400x250 to 1680x1050 instantly... the slowest it swapped was 28ms, the average I was getting was 5ms, fastest was 2ms...

No grainy graphics, no client lag, no hitch, hickup, burp, etc.

The scripts I wrote up are far from ready for prime time, but I'll be working on getting my setup polished out and within a month or so expect to see what I've taken from Lax (tons of help!) and worked into my config... Right now I can box between 2 and 8, and I'll be working on a bit of fancy math to make that scale outwards.

System Spec's:
AMD Phenom 9600 (Quad core, 2.3ghz w/TLB Erratta disabled)
4GB Ram
8800GT video card
WoW running from a SATA 3.0 500GB drive, symlinked folder.

[zanthor]

For those interested, the scripts I am using:

wow.iss - used to launch wows with the command "run wow #" where # is the number of wows you want...

function main(int clients)
{
	variable int Count
	for (Count:Set[0] ; ${Count}<${clients} ; Count:Inc)
	{
		open "World of Warcraft" "World of Warcraft Default Profile" "run multi ${clients}"
		/* Wait 2 seconds (wait takes tenths of seconds) */
		wait 20
	}
}

multi.iss - Used to setup each client to it's own region, similar to KeyClones PIP except you leave gaps in the layout, I'll be seeing what I can do to change this, however I'm actually liking the 100% relative positioning as my keybinds on my x-keys can match it.

function main(int clients)
{
	while ${Sessions} < ${clients} - 1
		waitframe
	variable int nSession
	nSession:Set["${Session.Right[-2]}"]
	
	variable int nXsize
	variable int nYsize
	variable int nXpos
	variable int nYpos
	variable int nVertSplit

	if ${Sessions} > 3 
	{
		nVertSplit:Set["4"]
	}
	else
	{
		nVertSplit:Set["${Sessions}+1"]
	}
	nXsize:Set["10*(${Math.Calc["1024/${nVertSplit}*1.6/10"].Int})"]
	nYsize:Set["${nXsize}/1.6"]

	if ${nSession} <= 4
	{
		nXpos:Set["0-${nXsize}"]
		nYpos:Set["(${nSession}-1)*${nYsize}"]
	}
	else
	{
		nXpos:Set["0-${nXsize}*2"]
		nYpos:Set["(${nSession}-5)*${nYsize}"]
	}

	run windowsnapper -pos ${nXpos},${nYpos} -size ${nXsize}x${nYsize}
	windowpos -viewable 0,0
	windowsize -viewable 1680x1050

	/* Setup Hotkeys up to 10 clients*/
	if ${nSession} <= 10
		globalbind is${nSession}_key "Ctrl+F${nSession}" "windowvisibility foreground;relay all press Ctrl+F${nSession}"
	
	/* Setup processor affinity  up to 10 clients's*/
	if ${nSession} < 4
	{
		proc ${nSession} only ${Math.Calc["${nSession}+1"]} on
	}
	else if ${nSession} == 4 or ${nSession} == 9
	{
		proc 1 only 4 on
	}
	else if ${nSession} == 5 or ${nSession} == 10
	{
		proc 1 on 2 on 3 on 4 on
	}
	else if ${nSession} < 10
	{
		proc ${Math.Calc["${nSession}-5"]} only ${Math.Calc["${nSession}-4"]} on
	}
}

The only other file used is the windowsnapper.iss from Lavishsoft.

http://www.lavishsoft.com/joomla/ind...d=43&Itemid=91

[Suribusi]

Nicely done, you pick up on LS very quickly. If you or anyone else has questions about IS/LS/LGUI, etc feel free to ask/post. I'm a 4 year veteran.

-S

[phara]

Do you have experience with opening windows using different graphics adapters as primary (not monitor, graphics card).

I've been looking for a fix for the dual view performance problem, and I recall on another thread Lax posted that IS can specify the adapter when launching a window (so directx loads the resources on the adapter the window is being displayed with).

A workaround is to manually change your primary display in windows, run wow, change primary, run other wow. I'm curious how IS does it. I was doing some poking around to see how I could extend something like maximizer to do this without manual steps, and the only thing I arrived at was using windows GDI functions to modify the display properties (ChangeDisplaySettingsEx) to set the primary display before launching each wow.exe.

[Lax]

Inner Space is able to do it because it is a layer between the game and Windows (and DirectX). The game selects the display adapter with DirectX API, and Inner Space can change that selection. If keyclone and maximizer are not build this way, they cannot do the same thing, they would have to do a workaround instead.

[keyclone]

the reason keyclone is not done that way is to avoid breaching the line.

there are many things you can do, once you are in game memory... which some people are aware of (this is where wowglider gets its mojo)

others have no idea, but to discuss it would be to beat a dead horse... again

and last i checked, IS was bannable via warden.

personally, i'd like to keep my accounts.

[zanthor]

and last i checked, IS was bannable via warden.

I'd be very curious where you got this data, I can't find anywhere stating it's bannable as long as you follow the rules laid out (1 action = 1 action)

[keyclone]

InnerSpace is the foundation on which the other apps were based.

the ban wave was back in the spring (here's a blog on it http://onwarden.blogspot.com/2008/05...e-wow-242.html )

the 'one keypress => one action per game window' rule of thumb takes for granted that you are not mucking with game memory. what would keep someone from reading passwords or changing various client side data? this is exactly what glider did and why blizzard went after it

[eqjoe]

I have been using IS without any extra extensions for months with no problems. IS does not cross the line by invading the WoW client memory space. From what I understand, IS works using only Windows DX APIs.

-j

[Lax]

Hi Rob, welcome to the discussion. We have been discussing this in other threads on dual-boxing.com as of late, you are welcome to bring yourself up to speed by reading them.

In short, Inner Space is not nearly the same thing as Glider. To say that "Inner Space is in-game and therefore bannable like Glider" would be the same as saying "WinEQ 2 is in-game and therefore bannable like Glider", and then to show how wrong that notion is, last year they un-banned WinEQ 2 users and gave them 2 days on their WoW subscription for the trouble. That is much like the Cedega bans -- which is also in-process - for which they gave the users 20 days back on their WoW subscription. So, to say that because it is in-process means it is not allowed is incorrect. Also, Glider is entirely out of process and does read the *game* memory, and Inner Space is in-process and does not read the *game* memory (interaction with Windows or DirectX is not part of the *game* logic).

What WILL get you banned is using additional software loaded into Inner Space, such as ISXWarden or ISXWoW. If you do not use ISXWarden or ISXWoW, you are not in immediate danger of being banned. If you do, you would get banned within 20 minutes (so I'm told by people who have tried).

We would all like to keep our accounts. Please keep the FUD out of it, and we can remain civil and coexist peacefully on these forums.