PokerPad - AHK hotkey script

[Xanderz]

@Dave

OK, here are the functions for creating a window capture, getting pixels from the window capture and deleting the window capture:

<font class="small">Code:</font><hr /><pre>/* Usage:
* Creates an offscreen capture of a window. The window cannot be minimized but may be invisible.
* Parameters:
* id: The window's id of which to create a capture
* device, context, pixels: Blank variables, see Releasing Memory below.
* Releasing Memory:
* After the capture is no longer needed, it's memory must be freed by calling Display_DeleteWindowCapture(device, context, pixels)
* where the 3 parameters are those that was passed to create the window capture.
*/
Display_CreateWindowCapture(ByRef device, ByRef context, ByRef pixels, ByRef id = "") {
if !id
WinGet, id, ID
device := DllCall("GetDC", UInt, id)
context := DllCall("gdi32.dll\CreateCompatibleDC", UInt, device)
WinGetPos, , , w, h, ahk_id %id%
pixels := DllCall("gdi32.dll\CreateCompatibleBitmap", UInt, device, Int, w, Int, h)
DllCall("gdi32.dll\SelectObject", UInt, context, UInt, pixels)
DllCall("PrintWindow", "UInt", id, UInt, context, UInt, 0)
; TODO: error checking, return true if succeeded
}

Display_DeleteWindowCapture(ByRef device, ByRef context, ByRef pixels) {
DllCall("gdi32.dll\ReleaseDC", UInt, device)
DllCall("gdi32.dll\DeleteDC", UInt, context)
DllCall("gdi32.dll\DeleteObject", UInt, pixels)
}


/* Usage:
* Gets the pixel from a window capture created from Display_CreateWindowCapture
* Parameters:
* context: the device context as given by Display_CreateWindowCapture
* x, y: the coordinate parameters
* Return:
* The pixel in RGB format.
*/
Display_GetPixel(ByRef context, x, y) {
return DllCall("GetPixel", UInt, context, Int, x, Int, y)
}</pre><hr />

They are now in a file called Display.ahk hence the Display_ prefix on each function name.

The only major changes I've made is restricting the size of the buffer to the size of the window (as opposed to the monitor size - it may even be possible to have a window larger than the monitor size and I don't know what kinds of fun that could pop up...) And also the use of ReleaseDC instead of DeleteDC. From what I've read, you are suppose to call ReleaseDC after you are finished with what is returned from the GetDC call (which I believe is the screen display device context hence my calling it "device"). I hope this is correct.

I have converted everything in PokerPad 0.1.5 (not yet released) to use these functions instead of reading from the screen and everything seems to work as before (This usually scares me into thinking I really didn't change anything! Usually something gets screwed up and nothing works anymore LOL).

[_dave_]

This looks much cleaner than the stuff I emailed you [img]/images/graemlins/smile.gif[/img] Awesome.

[ QUOTE ]

restricting the size of the buffer to the size of the window


[/ QUOTE ]

Required - a cheapo hack I just put in there because it was enough for testing at the time [img]/images/graemlins/smile.gif[/img]

[ QUOTE ]

also the use of ReleaseDC instead of DeleteDC.


[/ QUOTE ]

I'll have to read up on this, but I think you are correct. All I know is that without the DeleteDC commands, it stops working after a while (running out of GDI resources imo). What you say rings a bell - but it is &gt;3 years since I did any C++ Win32-GDI coding, so I need to check. I *think* DeleteDC does enough to free the resources - but it certainly can't hurt to ReleaseDC too.

Another thisn - not mentioned above, but in your email - about the PrintWindow options:

Either the documentation or the function is backwards [img]/images/graemlins/frown.gif[/img]

0 provides ClientOnly, 1 adds AFAICT borders (but not caption) to the captured DC.

[ QUOTE ]

I have converted everything in PokerPad 0.1.5 (not yet released) to use these functions instead of reading from the screen and everything seems to work as before (This usually scares me into thinking I really didn't change anything!


[/ QUOTE ]

Fantastic [img]/images/graemlins/smile.gif[/img]

You can be sur using these functions it is using the PrintWindow method - so if it all continues to work without noticable difference - sweet [img]/images/graemlins/smile.gif[/img]

I am halfway thru converting BetPot to use these (with ImageMatch also) ... about to fall asleep [img]/images/graemlins/frown.gif[/img]


You don't use ity in the above functions, but there MUST be a better way of adding a +/- for "Shades of variation" than my crapola method of SetFormat -&gt; StringMid -&gt; add/subtract -&gt;recombine Hex - SetFormat, which I'm sure is horrific but works.

I guess The Binary / BitShift operators, but hose confuse me no end [img]/images/graemlins/frown.gif[/img]

dave.

[Xanderz]

[ QUOTE ]
I'll have to read up on this, but I think you are correct. All I know is that without the DeleteDC commands, it stops working after a while (running out of GDI resources imo). What you say rings a bell - but it is &gt;3 years since I did any C++ Win32-GDI coding, so I need to check. I *think* DeleteDC does enough to free the resources - but it certainly can't hurt to ReleaseDC too.

[/ QUOTE ]
I don't use DeleteDC on the device handle at all (That returned from the GetDC call). It is my understanding that you only delete things you create, therefore you are not suppose to delete 'device', but as the 'context' and 'pixels' are created, those must be deleted.

[ QUOTE ]
Another thisn - not mentioned above, but in your email - about the PrintWindow options:

Either the documentation or the function is backwards [img]/images/graemlins/frown.gif[/img]

[/ QUOTE ] The documentation never specified what the values are, but 0 works whereas 1 doesn't so I use 0 [img]/images/graemlins/smile.gif[/img]

[ QUOTE ]
You can be sur using these functions it is using the PrintWindow method - so if it all continues to work without noticable difference - sweet [img]/images/graemlins/smile.gif[/img]

[/ QUOTE ]Only noticeable difference was after benchmarking the two OCR methods (screen reading and print window), the print window method was 5x faster [img]/images/graemlins/grin.gif[/img] There seems to be quite a bottleneck somewhere in getting each pixel from the screen.

[ QUOTE ]
You don't use ity in the above functions, but there MUST be a better way of adding a +/- for "Shades of variation" than my crapola method of SetFormat -&gt; StringMid -&gt; add/subtract -&gt;recombine Hex - SetFormat, which I'm sure is horrific but works.

I guess The Binary / BitShift operators, but hose confuse me no end [img]/images/graemlins/frown.gif[/img]

[/ QUOTE ]
You are correct. Here is the function I use:

<font class="small">Code:</font><hr /><pre>Display_CompareColors(ByRef bgr1, ByRef bgr2, ByRef variation) {
c1 := bgr1 &amp; 0xff
c2 := bgr2 &amp; 0xff
if (abs(c1 - c2) &gt; variation)
return false
c1 := (bgr1 &gt;&gt; 8) &amp; 0xff
c2 := (bgr2 &gt;&gt; 8) &amp; 0xff
if (abs(c1 - c2) &gt; variation)
return false
c1 := (bgr1 &gt;&gt; 16) &amp; 0xff
c2 := (bgr2 &gt;&gt; 16) &amp; 0xff
if (abs(c1 - c2) &gt; variation)
return false
return true
}</pre><hr />

Just ignore the fact that the parameters say bgr1 and bgr2, as RGB format works just as well. The bgr names are just an artifact from screen reading which returns the values in BGR format.

Also, besides the Display_ReadArea function, I also made the following pixel search function:

<font class="small">Code:</font><hr /><pre>/* Usage:
* Searches for the specifed color in the given rectangle of a window capture created from Display_CreateWindowCapture
* Parameters:
* id: either a window id or the letter c followed by the device context handle as given by Display_CreateWindowCapture
* x, y, w, h: the rectangle parameters
* color: the color in RGB format
* variation: the allowed variation from the specified color
* Return:
* Returns true if the specified color/variation is found within the given area, false otherwise.
*/
Display_PixelSearch(x, y, w, h, color, variation, ByRef id = "") {
if !id
Display_CreateWindowCapture(device, context, pixels)
else if (SubStr(id, 1, 1) = "c")
context := SubStr(id, 2)
else
Display_CreateWindowCapture(device, context, pixels, id)
Loop, %w% {
j := y
Loop, %h% {
rgb := Display_GetPixel(context, x, j++)
if Display_CompareColors(rgb, color, variation) {
if device
Display_DeleteWindowCapture(device, context, pixels)
return true
}
}
x++
}
if device
Display_DeleteWindowCapture(device, context, pixels)
return false
}</pre><hr />

[Xanderz]

Version 0.1.5 is now available.

For the most part, screen reading has been removed (except for situations where just 1 pixel needs to be checked on the active table). The new methods contributed by _dave_ are used which allow accurate reading even if the window is partially covered by another window.

The other major change is that checkboxes are now handled correctly. Use the same hotkey as fold/call/raise to click the top checkbox and use Ctrl + {hotkey} to click the bottom checkbox. If Ctrl is not used and the top checkbox is not present but the bottom checkbox is, then the bottom checkbox will be clicked in that scenario without use of the Ctrl key.

Also, the old Timers.ahk add-on will not work with PokerPad 0.1.5 or higher, however, the latest Timers.ahk (version 0.2) has been updated which uses the new methods mentioned above and will only work with PokerPad 0.1.5 or higher.

As always download is available here:
http://www.autohotkey.net/~Xander/PokerPad/

[Xanderz]

Version 0.1.6 has been updated with a total overhaul of the pot bet calculations. They should now be accurate for all window sizes. The only time they won't be accurate is when you have placed a bet and the pot has been reraised two times before action comes back to you. The script can't tell if it was a single raise or multiple raises...

Also fixed the colors changed in 0.1.5 which rendered some hotkeys useless.

[HighSteaks]

Can you please consider Everest for this, there are no Auto hotkeys that work there and the betting setup is a nightmare for multi tabling. [img]/images/graemlins/cool.gif[/img]

[Xanderz]

OK, I will have a crack at it and see what I can come up with.

[Chewbacca]

I tried this out today. Great work and thanks.

I use an external USB keypad with my laptop and the fold/call/raise buttons work fine as does the direct write to the bet amount window if numlock is pressed. But none of the x pot bets work at all. My numpad works fine in a text window (i,e, numpadhome, etc do what you would expect).

Do you have any ideas on what I need to do to fix this?

p.s. I didn't see this mentioned here in the thread, but pokerpad seems to work flawlessly with TableNavigator (and I disabled TableNav to double check that wasn't what was screwing up the pot bet commands)

[Xanderz]

[ QUOTE ]
I use an external USB keypad with my laptop and the fold/call/raise buttons work fine as does the direct write to the bet amount window if numlock is pressed. But none of the x pot bets work at all. My numpad works fine in a text window (i,e, numpadhome, etc do what you would expect).

Do you have any ideas on what I need to do to fix this?

[/ QUOTE ]What site does it not work for? Some possible problems could arise if:

1) On Full Tilt, if the button images have been changed.
2) On Poker Stars, if the theme isn't Classic (other themes can be supported by editing the PokerPad.ini file)
3) On iPoker, if the theme isn't Titan (again, other sites can be supported by editing the PokerPad.ini file)

Also, it is possible that some window sizes may not be read properly. You can try resizing the table to the smallest size (this size should always work) and see if you still have problems. If this fixes your problem, just tell me which table size is not working (and for which site) and I'll fix it.

[ QUOTE ]
p.s. I didn't see this mentioned here in the thread, but pokerpad seems to work flawlessly with TableNavigator (and I disabled TableNav to double check that wasn't what was screwing up the pot bet commands)

[/ QUOTE ]
Good to know it works with TableNavigator. I added support for it awhile back but couldn't test if it really did work as I don't have TableNavigator configured to even work [img]/images/graemlins/ooo.gif[/img]

[Chewbacca]

I tihnk what might be happening is that the script thinks the external keypad buttons are the same as the regular keyboard buttons for pageup and pagedown for example.

When I switched to the PS default theme (was using hypersimple) I was able to move the slider using "3" and "9" on the keyppad for example. Before I was able to type numbers in the betting window, but this didn't seem to work anymore.

I noticed a couple times I would get an auto-rebuy to using my keypad.

Maybe this is dumb, but is it possible that there is a setting for laptop vs desktop keyboard? Or should I just be thinking about editing the hotkeys onto my laptop keyboard instead of the external keypad?

I'll try deleting the commands for the slider and rebuy and see if the pot bets work. Seems like that might be a possibility.

Another question I have is whether I can enter gamepad commands for my hotkeys. Is there a way to specify button 1, etc, for the various betting actions?