Open Side Menu Go to the Top
Register
StackAndTile StackAndTile

12-19-2009 , 08:26 AM
You shouldn't have any problems with StackAndTile then 175 is good for PrintWindow function.
StackAndTile Quote
12-19-2009 , 10:21 AM
Quote:
Originally Posted by Max1mums
Try running this speed test, just open any 20 PS/FT tables (Playmoney cash easiest), press f12 several times, how much will it be for you?
Code:
#NoEnv
#SingleInstance, Force
Settitlematchmode, 2


SysGet, xbord, 32
SysGet, ybord, 33
SysGet, cap, 4


f12::
StartTime:=A_TickCount
WinGet, listst, List, ahk_class PokerStarsTableFrameClass
WinGet, listft, List, ahk_class QWidget,,Full Tilt
Loop, %listst%
{
win:=listst%A_index%
col%A_index%:=PixelColorA(0.5,0.5,win)
}
Loop, %listft%
{
win:=listft%A_index%
col%A_index%:=PixelColorA(0.5,0.5,win)
}
ElapsedTime:=A_TickCount - StartTime
Gui, 2:Add, Text,,%ElapsedTime% milliseconds have elapsed
Gui, 2:+ToolWindow
Gui, 2:Show, w180 h40
Sleep, 1000
Gui, 2:Destroy
return




CreateDIBSection(hDC, nW, nH, bpp = 32, ByRef pBits = "") {
   NumPut(VarSetCapacity(bi, 40, 0), bi)
   NumPut(nW, bi, 4)
   NumPut(nH, bi, 8)
   NumPut(bpp, NumPut(1, bi, 12, "UShort"), 0, "Ushort")
   NumPut(0,  bi,16)
   Return DllCall("gdi32\CreateDIBSection", "Uint", hDC, "Uint", &bi, "Uint", 0, "UintP", pBits, "Uint", 0, "Uint", 0)
}

PixelColorA(colxa,colya,id)
{
critical ;speed up
global xbord,ybord,cap
hdc_frame := DllCall( "GetDC", "UInt", id)
hdc_buffer := DllCall("gdi32.dll\CreateCompatibleDC", "UInt",  hdc_frame)
WinGetPos, X, Y, W, H, ahk_id %id%
hbm_buffer := CreateDIBSection(hdc_frame, w, h)
DllCall( "gdi32.dll\SelectObject", UInt,hdc_buffer, UInt,hbm_buffer)
DllCall( "PrintWindow", "UInt" , id , "UInt" , hdc_buffer , "UInt" , 0 )
WinGetPos, X, Y, W, H, ahk_id %id%
DllCall("RedrawWindow",uint,id,uint,0,uint,0,uint, 1|16|32|128|256|1024) ; with all children windows
w := w - (2*xbord)
h := h - (2*ybord) - cap
Transform, X, Floor, W*colxa
Transform, Y, Floor, H*colya
pixel_x := x + xbord
pixel_y := y + ybord + cap
pix := DllCall("GetPixel", "UInt", hdc_buffer, "Int", pixel_x , "Int", pixel_y) 
SetFormat, IntegerFast, hex
pix += 0  ; Sets Var (which previously contained 11) to be 0xb.
pix .= ""  ; Necessary due to the "fast" mode.
SetFormat, IntegerFast, d
DllCall( "gdi32.dll\DeleteObject", "uint", hbm_buffer )
DllCall( "gdi32.dll\ReleaseDC"    , "uint", hdc_frame )
DllCall( "gdi32.dll\DeleteDC"    , "uint", hdc_frame )
DllCall( "gdi32.dll\DeleteDC"    , "uint", hdc_buffer )
return pix
}
I am averaging about 150ms with 20 tables...that being said,when I use stackntile it gets super laggy after about 14 tables
StackAndTile Quote
12-19-2009 , 10:28 AM
Well, maybe greg can optimize his script somehow.
StackAndTile Quote
12-19-2009 , 10:59 AM
And what do you mean by "gets super laggy"? Does script work too slow or does it look like cpu/videocard overload?
StackAndTile Quote
12-19-2009 , 11:02 AM
Quote:
Originally Posted by Max1mums
And what do you mean by "gets super laggy"? Does script work too slow or does it look like cpu/videocard overload?
The mouse starts skipping around and by the time I get to some tables they are timed out.I normally play 30 to 40 stacked with no problems but with this script I can only play 14 max.
StackAndTile Quote
12-19-2009 , 11:11 AM
Quote:
Originally Posted by Sorrybadbeat
The mouse starts skipping around and by the time I get to some tables they are timed out.I normally play 30 to 40 stacked with no problems but with this script I can only play 14 max.
Yeah, gets bad for me on my dual core 2.2ghz as well. I think it's always gonna be an issue with all the pixel searching. Loking forward to the TOI implementation which won't require any.
StackAndTile Quote
12-19-2009 , 11:13 AM
Quote:
Originally Posted by lennois
Yeah, gets bad for me on my dual core 2.2ghz as well. I think it's always gonna be an issue with all the pixel searching. Loking forward to the TOI implementation which won't require any.
Yeah I had hopped to be able to use this for SitNGos but I guess I'll just use it for cash games.Still a wicked program!
StackAndTile Quote
12-19-2009 , 12:12 PM
Quote:
Originally Posted by lennois
Yeah, gets bad for me on my dual core 2.2ghz as well. I think it's always gonna be an issue with all the pixel searching. Loking forward to the TOI implementation which won't require any.
Why's that? Should't be any problems if comp can handle pixel searching fast enough and it can according to your speed test results.

Purpose of pixel searching in this script is to detect situations when action is on hero (only VPIP function is another story), fold button is always visible in those situations so we check for it's visibility. It can be done without pixel searching if there is another way of detecting "action on hero" situations: we can look for betting slider instead on Pokerstars (which is window control and can be detected without pixel searching) but it is not present in "allin before hero" situations so script will miss them, and we can look for fold button as window control on Fulltilt using environment variable QT_USE_NATIVE_WINDOWS, but tableninja will stop working then (as far as i know).

So TOI implementation can be done without pixel searching, you can decide if you want it counting described limitations.
StackAndTile Quote
12-19-2009 , 01:52 PM
Quote:
Originally Posted by greg nice
so when you press Start, the stack is positioned in the upperleft corner of the left monitor. and when tables start to be tiled, they start in the upperleft of the right monitor? is that right?

i dont have 2 monitors right now to test on. can you copy and paste all the lines from the StackAndTile.ini file ?
Yes, that's correct.

INI:

Code:
[settings]
total_slots=4
slot1x=0
slot1y=0
slot2x=483
slot2y=0
slot3x=0
slot3y=361
slot4x=483
slot4y=361
stack_slot=0
stack_x=-1597
stack_y=-172
fold_hotkey=F3
stars_nofold_pixelcol=0x426774
include_stars=0
include_fulltilt=1
ft_fold_pixelcol=0x9C7708
gui_x=-859
gui_y=411
send_table_under_mouse=1
move_on_street=preflop
detect_stars_allins=1
StackAndTile Quote
12-19-2009 , 03:21 PM
Quote:
Originally Posted by xK1nGeNx
Yes, that's correct.

INI:

Code:
[settings]
....
StackAndTile count relative to the main monitor afaik and it seems you run your secondary monitor to the left just like me.
I think the easiest and most customizable way is to edit the ini file manually with negative x-values.

For example a 4x4 grid of 500x400 poker windows with slot 0 as stack on a secondary 1600x1200 screen to the left:

total_slots=4
slot1x=-1600
slot1y=0
slot2x=-1100
slot2y=0
slot3x=-1600
slot3y=400
slot4x=-1100
slot4y=400
stack_slot=0

etc continue to fill in more slots manually

Btw, you have to make sure yourself that the poker windows actually have the size you setup it for when using this method. Otherwise you might get some overlapping

Last edited by fsvo; 12-19-2009 at 03:28 PM.
StackAndTile Quote
12-19-2009 , 04:09 PM
Quote:
Originally Posted by Max1mums
Why's that? Should't be any problems if comp can handle pixel searching fast enough and it can according to your speed test results.

Purpose of pixel searching in this script is to detect situations when action is on hero (only VPIP function is another story), fold button is always visible in those situations so we check for it's visibility. It can be done without pixel searching if there is another way of detecting "action on hero" situations: we can look for betting slider instead on Pokerstars (which is window control and can be detected without pixel searching) but it is not present in "allin before hero" situations so script will miss them, and we can look for fold button as window control on Fulltilt using environment variable QT_USE_NATIVE_WINDOWS, but tableninja will stop working then (as far as i know).

So TOI implementation can be done without pixel searching, you can decide if you want it counting described limitations.
I haven't done speed test results. Must be someone else.

I was talking about flop detection method which runs slow for me. Like you say, if you don't use this you need to search for fold button with all ins because you aren't looking at the stack (this happens a bit with SS shoving from SB etc.) I haven't actually tested with that but I'm keener on the move only on VPIP idea anyway.

Moving tables on VPIP using hotkeys will be better for me. This uses flop detection which is better for others.

Edit: I assume it was pixel detection making it run slow anyway. Might have a play around again and see.
StackAndTile Quote
12-19-2009 , 04:56 PM
Quote:
Originally Posted by Sorrybadbeat
The mouse starts skipping around and by the time I get to some tables they are timed out.I normally play 30 to 40 stacked with no problems but with this script I can only play 14 max.
are you using "move tables on FLOP" or "preflop" ? max1mums speed test only searches for one pixel. when you use the "flop" method, it has to search many pixels at once for a flop card, its very resource intensive.
StackAndTile Quote
12-19-2009 , 05:02 PM
Quote:
Originally Posted by greg nice
are you using "move tables on FLOP" or "preflop" ? max1mums speed test only searches for one pixel. when you use the "flop" method, it has to search many pixels at once for a flop card, its very resource intensive.
Yeah I am using the flop detection.
StackAndTile Quote
12-19-2009 , 05:07 PM
Quote:
Originally Posted by greg nice
are you using "move tables on FLOP" or "preflop" ? max1mums speed test only searches for one pixel. when you use the "flop" method, it has to search many pixels at once for a flop card, its very resource intensive.
Even considered start using the PokerStars.log.0 to detect various stuff? From what I've seen in it, it logs basically anything that happens on the tables in realtime. Dealt, holecards, action required, table ID's, pots, etc
StackAndTile Quote
12-19-2009 , 05:08 PM
Quote:
I'm using 2 screens and want both the stack and tile on my left screen. When I'm setting this up right now I get the stack to be positioned upper left corner of left screen but then when it tiles it shows up on my right screen (upper left corner[slot1?] how can I change this?
Quote:
Originally Posted by xK1nGeNx

INI:
seems like fsvo figured it out regarding primary and secondary monitors. apparently your poker tables are 483x361. try replacing these values only, leave the others as-is:

Code:
[settings]
total_slots=4
slot1x=-1600
slot1y=0
slot2x=-1117
slot2y=0
slot3x=-1600
slot3y=361
slot4x=-1117
slot4y=361
stack_slot=1
stack_x=-1600
stack_y=-1117
this should set your 4 tables on the left monitor. the stack will be in slot1. then you'll have 3 slots to move tables into. see if this works, and then you can customize it further
StackAndTile Quote
12-19-2009 , 05:13 PM
Quote:
Originally Posted by Sorrybadbeat
Yeah I am using the flop detection.
thanks, that probably explains it. i'm not sure i can do anything to fix this better. i've already optimized it a few times before releasing. i think its just a limitation when you have to search for many pixels to detect whether theres a flop card.

just for kicks, can you try with "preflop" method and tell me if you get the same lag?
StackAndTile Quote
12-19-2009 , 05:15 PM
First why do you search for many pixels? Can't you get same result taking just one? Then i don't see why can't you take many pixels at once when you have image captured in buffer, does getpixel function cause that huge lag?
StackAndTile Quote
12-19-2009 , 05:15 PM
Quote:
Originally Posted by fsvo
Even considered start using the PokerStars.log.0 to detect various stuff? From what I've seen in it, it logs basically anything that happens on the tables in realtime. Dealt, holecards, action required, table ID's, pots, etc
was suggested earlier in the thread, i never heard of it. i'll have to check it out
StackAndTile Quote
12-19-2009 , 05:18 PM
Quote:
Originally Posted by Max1mums
First why do you search for many pixels? Can't you get same result taking just one? Then i don't see why can't you take many pixels at once when you have image captured in buffer, does getpixel function cause that huge lag?
i just used the function from BetPot that determines the street. i didnt spend a lot of time looking at it, i think it searches for 5 or more white pixels and then concludes that the area is indeed a card

change the variable in the autoexec of the script:

debug := 1

you will see a brief overlay on the table of the rectangle that gets scanned.
StackAndTile Quote
12-19-2009 , 05:40 PM
I'm not sure of the advantage of flop detection in the first place? Even if you don't use hotkeys, can't you just detect clicks of bet/call and move the table to grid (TOI does this)

Anything that can just use the top table rather than having to search through the stack makes more sense to me anyway.
StackAndTile Quote
12-19-2009 , 05:49 PM
Pixelcount function counts pixels of specified color looking through every pixel of specified region, but i don't really think you need it, you can take just one or two pixels from buffer and if all are white - there is card on that position.
StackAndTile Quote
12-19-2009 , 07:21 PM
This test will take 10 pixels per table, run it please.
Code:
#NoEnv
#SingleInstance, Force
Settitlematchmode, 2

SysGet, xbord, 32
SysGet, ybord, 33
SysGet, cap, 4

f12::
StartTime:=A_TickCount
WinGet, listst, List, ahk_class PokerStarsTableFrameClass
WinGet, listft, List, ahk_class Logged in QWidget,,Full Tilt
Loop, %listst%
{
win:=listst%A_index%
col%A_index%:=PixelColorA(0.8,0.7,win,30)
}
Loop, %listft%
{
win:=listft%A_index%
col%A_index%:=PixelColorA(0.8,0.7,win,30)
}
ElapsedTime:=A_TickCount - StartTime
Gui, 2:Add, Text,,%ElapsedTime% milliseconds have elapsed
Gui, 2:+ToolWindow
Gui, 2:Show, w180 h40
Sleep, 1000
Gui, 2:Destroy
return

CreateDIBSection(hDC, nW, nH, bpp = 32, ByRef pBits = "") {
   NumPut(VarSetCapacity(bi, 40, 0), bi)
   NumPut(nW, bi, 4)
   NumPut(nH, bi, 8)
   NumPut(bpp, NumPut(1, bi, 12, "UShort"), 0, "Ushort")
   NumPut(0,  bi,16)
   Return DllCall("gdi32\CreateDIBSection", "Uint", hDC, "Uint", &bi, "Uint", 0, "UintP", pBits, "Uint", 0, "Uint", 0)
}

PixelColorA(colxa,colya,id,delta)
{
critical
setwindelay,-1
global xbord,ybord,cap
hdc_frame := DllCall( "GetDC", "UInt", id)
hdc_buffer := DllCall("gdi32.dll\CreateCompatibleDC", "UInt",  hdc_frame)
WinGetPos,,, W, H, ahk_id %id%
hbm_buffer := DllCall("gdi32.dll\CreateCompatibleBitmap", "UInt",hdc_frame, "Int",w, "Int",h)
;hbm_buffer := CreateDIBSection(hdc_frame, w, h)
DllCall( "gdi32.dll\SelectObject", "UInt",hdc_buffer, "UInt",hbm_buffer)
DllCall( "PrintWindow", "UInt" , id , "UInt" , hdc_buffer , "UInt" , 0 )
WinGet,ctrls,ControlList,ahk_id %id%
Loop,Parse,ctrls,`n
{
  class:=A_LoopField
    ControlGet,ctrlid,Hwnd,,%class%,ahk_id %id%
    ControlGet,visible,Visible,,,ahk_id %ctrlid%
    If visible=1  
    DllCall("RedrawWindow","Uint",ctrlid,"Uint",0,"Uint",0,"Uint", 1|16|32|64|2048)    
} 
DllCall("RedrawWindow","Uint",id,"Uint",0,"Uint",0,"Uint", 1|16|32|64|1024)
x:=floor(((W-2*xbord)*colxa) + xbord)
y:=floor(((H-(2*ybord)-cap)*colya) + ybord + cap)
pix:=""
delta:=0
loop 10
{
pix%A_index% := DllCall("GetPixel", "UInt", hdc_buffer, "Int", x+delta , "Int", y+delta)
delta+=5
pix:=pix . pix%A_index% . "-"
}
DllCall( "gdi32.dll\DeleteObject", "Uint", hbm_buffer )
DllCall( "gdi32.dll\ReleaseDC"   , "Uint", hdc_frame )
DllCall( "gdi32.dll\DeleteDC"    , "Uint", hdc_frame )
DllCall( "gdi32.dll\DeleteDC"    , "Uint", hdc_buffer )
return pix
}

Last edited by Max1mums; 12-19-2009 at 07:39 PM.
StackAndTile Quote
12-19-2009 , 08:10 PM
Quote:
Originally Posted by greg nice
seems like fsvo figured it out regarding primary and secondary monitors. apparently your poker tables are 483x361. try replacing these values only, leave the others as-is:
Thank you both! The tables are now in the right position but after like 3-4 mins its starting to lag. Might be my computer but when i run the script
Code:
#NoEnv
#SingleInstance, Force
Settitlematchmode, 2

SysGet, xbord, 32
SysGet, ybord, 33
SysGet, cap, 4

f12::
StartTime:=A_TickCount
WinGet, listst, List, ahk_class PokerStarsTableFrameClass
WinGet, listft, List, ahk_class Logged in QWidget,,Full Tilt
Loop, %listst%
{
win:=listst%A_index%
col%A_index%:=PixelColorA(0.8,0.7,win,30)
}
Loop, %listft%
{
win:=listft%A_index%
col%A_index%:=PixelColorA(0.8,0.7,win,30)
}
ElapsedTime:=A_TickCount - StartTime
Gui, 2:Add, Text,,%ElapsedTime% milliseconds have elapsed
Gui, 2:+ToolWindow
Gui, 2:Show, w180 h40
Sleep, 1000
Gui, 2:Destroy
return

CreateDIBSection(hDC, nW, nH, bpp = 32, ByRef pBits = "") {
   NumPut(VarSetCapacity(bi, 40, 0), bi)
   NumPut(nW, bi, 4)
   NumPut(nH, bi, 8)
   NumPut(bpp, NumPut(1, bi, 12, "UShort"), 0, "Ushort")
   NumPut(0,  bi,16)
   Return DllCall("gdi32\CreateDIBSection", "Uint", hDC, "Uint", &bi, "Uint", 0, "UintP", pBits, "Uint", 0, "Uint", 0)
}

PixelColorA(colxa,colya,id,delta)
{
critical
setwindelay,-1
global xbord,ybord,cap
hdc_frame := DllCall( "GetDC", "UInt", id)
hdc_buffer := DllCall("gdi32.dll\CreateCompatibleDC", "UInt",  hdc_frame)
WinGetPos,,, W, H, ahk_id %id%
hbm_buffer := DllCall("gdi32.dll\CreateCompatibleBitmap", "UInt",hdc_frame, "Int",w, "Int",h)
;hbm_buffer := CreateDIBSection(hdc_frame, w, h)
DllCall( "gdi32.dll\SelectObject", "UInt",hdc_buffer, "UInt",hbm_buffer)
DllCall( "PrintWindow", "UInt" , id , "UInt" , hdc_buffer , "UInt" , 0 )
WinGet,ctrls,ControlList,ahk_id %id%
Loop,Parse,ctrls,`n
{
  class:=A_LoopField
    ControlGet,ctrlid,Hwnd,,%class%,ahk_id %id%
    ControlGet,visible,Visible,,,ahk_id %ctrlid%
    If visible=1  
    DllCall("RedrawWindow","Uint",ctrlid,"Uint",0,"Uint",0,"Uint", 1|16|32|64|2048)    
} 
DllCall("RedrawWindow","Uint",id,"Uint",0,"Uint",0,"Uint", 1|16|32|64|1024)
x:=floor(((W-2*xbord)*colxa) + xbord)
y:=floor(((H-(2*ybord)-cap)*colya) + ybord + cap)
pix:=""
delta:=0
loop 10
{
pix%A_index% := DllCall("GetPixel", "UInt", hdc_buffer, "Int", x+delta , "Int", y+delta)
delta+=5
pix:=pix . pix%A_index% . "-"
}
DllCall( "gdi32.dll\DeleteObject", "Uint", hbm_buffer )
DllCall( "gdi32.dll\ReleaseDC"   , "Uint", hdc_frame )
DllCall( "gdi32.dll\DeleteDC"    , "Uint", hdc_frame )
DllCall( "gdi32.dll\DeleteDC"    , "Uint", hdc_buffer )
return pix
}
I get from 150-210 milli sec for PS but when trying with FT it says 0 :S
How many tables can you guys play and what processors, memory and so on do u got?
StackAndTile Quote
12-19-2009 , 08:25 PM
greg-nice: Hey the new version seems to work now! I only tested it for a few tables for a couple minutes so I am not sure of performance yet on my system but I will try a real session tomorrow and report back. Thanks again.

Kevin
StackAndTile Quote
12-19-2009 , 08:42 PM
Quote:
Originally Posted by lennois
I'm not sure of the advantage of flop detection in the first place? Even if you don't use hotkeys, can't you just detect clicks of bet/call and move the table to grid (TOI does this)

Anything that can just use the top table rather than having to search through the stack makes more sense to me anyway.
i dont know that there is an "advantage", i suppose on VPIP only, many times you'll raise pf and just take down the blinds, which wastes a move to the slot. i'm not really sure how to detect clicks of bet/call like TOI does, i'd rather just implement my own hotkeys if i were to do it that way

but yeah i just looked over the flop detection, max1mums is right, it searches every pixel, but then only checks if > 5. seems like a wasteit can def be optimized better
StackAndTile Quote

      
m