在寫WG或者一些輔助小工具的過程中，難免會涉及到向窗口的某個控件發送鼠標消息，或者是直接點擊窗口或者屏幕上的某一個區域。在資料不充分（例如對方使用的是DirectUI，控件的句柄就很難獲得，自然也很難知道某個控件或者對象相對于窗口或者屏幕左上角的坐標值）的情況下，很難確定在發送鼠標消息的時候，鼠標的坐標是多少。那么，如何快速地利用工具作簡單的查找呢？
筆者在制作一個QQ游戲的輔助工具時，就曾經因為一時間找不到兩幅圖片相對于窗口左上角的坐標而苦惱。
（因為這個找茬輔助工具是基于屏幕截圖，像素點之間逐一直接比對的）
如何知道上圖兩個紅點分別相對于窗口左上角的坐標值呢？
擴展，又如何知道兩幅找茬圖片的寬度和高度呢？
網上不乏好的查找方法，但是為了獲取幾組值而另外寫程序，筆者認為不夠靈活。程序員還是應該懶一點~解決方案如下：
運用photoshop的標尺功能即可完成任務：
筆者用的是photoshopCS4，估計其他版本也有這個功能。
第一步：
利用QQ自帶的截圖功能（TX這回自作聰明了，QQ截圖居然可以針對某個特定窗口或者某個特定控件截圖，從而省卻了全屏截圖過后裁切窗口的步驟），截取游戲窗口的PP，如下
：
第二步，在photoshopCS4中打開這張圖片，放大之，然后在工具欄中選擇標尺工具，如圖：
標尺工具
接著在圖片左上角的位置開始，沿著任意方向拖曳標尺工具，就像平時在windows畫圖中畫直線一樣，然后我們會看到一條很細的直線被拖出；
筆者往下垂直拖曳，這除了能夠確定左上角坐標之外，還可以測量出圖片的高度。
紅色框框里面的灰色線條（兩頭有十字圖案的）就是拖曳出來的直線標尺。
藍色框框有幾組值，熟悉windows窗口編程的童鞋們應該都可以笑而不語了，筆者不才，還是斗膽解說一下：
x：相對于圖片左上角的像素橫坐標（也就是我們要找的圖片或者控件相對于窗口左上角的坐標值）
y：相對于圖片左上角的像素縱坐標（同上）
w：width，線段兩端端點之間的
水平寬度（單位是像素）在這里是負數是因為筆者的終點在起點的水平方向左邊，因此是負數。
h：height，線段兩端端點之間的
垂直寬度（單位是像素）
注意：這里得到的數值是一個小數，其實說白了也是精度問題。
平時在做windows窗口編程的
過程中，控件的坐標總是整數，例如上圖的x = 9.44，要取9還是取10，那就要看我們在一開始選點的時候是否夠貼近真值。
這里目測一下（噗！O(∩_∩)O哈哈~），顯然是比真實圖像稍微偏左了，因此取10，其他值都按照這個方法處理。
用這種方法，可以測出兩幅圖片的左上角坐標和圖片的寬、高。獲得值之后，運用到程序中，誤差不會超過5個像素，到時在測試過程中微調一下就OK了。
筆者很幸運，第一次取整的時候就估中了，O(∩_∩)O哈哈~
針對QQ游戲大家來找茬，發放一下小屏幕版本的關鍵數據吧：
x1 = 10
y1 = 185
x2 = 403
y2 = 185
nWidth = 380
nHeight = 285
最后惡心一下：祝各位準備YY各種游戲輔助工具的親們開發愉快，噗哈哈哈哈哈！
誰說只有美工能用PS捏？咱們程序員也可以適當投機取巧一下嘛~哈哈posted @
2011-07-24 22:22 ArthasLee 閱讀(10153) |
評論 (0) |
編輯 收藏
Q1：為什么程序的數據需要放在堆、棧兩個不同（甚至更多）的地方？
對于堆和棧中的數據內容來說：
棧：編譯器需知道數據內容的生存周期、但是可以快速管理和分配棧內存；
堆：編譯器無需知道數據內容的生存周期，保證靈活性、但是分配和回收內存不如把數據放在棧中來得快；
Q2：對象在其生命周期結束后經歷什么步驟而后被釋放？銷毀機制具體是怎樣的？底層通過什么實現？
當程序執行到一個塊or作用域（scope）的結尾，會自動清理其維護的棧中的內存數據。
于是，如果保存在棧中的唯一reference掛掉了，就意味著再沒有辦法可以操作其原先引用的對象了。
但是保存在堆中的對象在這時候還沒有被清理掉。
對于在堆中，沒有被引用的對象。垃圾回收器會直接把他們占據的內存空間釋放掉。
真的如書中所說，這種機制滴水不漏嗎？會不會有陷阱？
會不會有一些不經意的操作導致引用計數永遠不為零，然而用戶卻懵然不知呢？
內存泄漏真的可以在真正意義上得到避免嗎？
Q3：垃圾回收機制究竟能干什么，不能干什么？究竟本質是什么？
垃圾回收機制原來只會對new出來的堆內存起作用！！！
萬一不是new出來的，那還是得人工回收……
1、You might not get garbage collected！
哎……這樣的垃圾回收機制啊……
還真是懶啊……
總之就是，垃圾回收機制只會回收對象在堆中的內存，但究竟這個對象的操作曾經干了什么，有沒有“歷史遺留問題”，java是一概不管的……
這個垃圾回收機制還是回到回憶中去吧……（我沒吐槽最終幻想，真的沒有！）
ClassName obj；//局部對象，放在棧中（C++可以這樣，java不行）
C++的好處：作用域結束，局部對象的destructor自動被調用，釋放棧中內存；
New出來的對象：
//C++的壞處：不執行delete的話，對象占用的內存會一直賴在堆中。就讓內存漏一會兒吧。
//java的好處：不用顯式執行，只要作用域結束，reference被清除，垃圾回收器就會自動回收堆中的內存；
而且，java兄還不讓你在棧中創建局部對象呢……
Q3/1：那究竟new操作發生的時候，java語言為用戶干了什么？new的操作也會對引用計數產生作用——例如初始化和創建嗎？垃圾回收器如何工作呢？
相對于堆而言，在棧中釋放和分配內存還是效率較高。這可能也是一些程序的數據放在棧中，一些放在堆中的原因之一吧？
引用計數類似是一個對象中的成員；有東西引用對象，就增加1，當有引用在棧中被釋放或者設為NULL，就減少1；發現引用計數為0，就證明這個對象已經沒人要了……
缺點：
垃圾回收器要掃描整個對象列表，查找引用計數為0的對象；
如果有兩個對象碰巧相互引用了彼此，那這兩個對象的引用計數就用不為零，即使沒人要也不會被清除掉；
最悲催的是：
JVM都不是通過這種機制實現垃圾回收滴……
JVM是這么干的……
逆向思維，不找死的，找活的！從一個引用出發，遍歷其對象-樹（自己作的）。透過每一個在棧中或者在靜態區中保存的引用，以之為根節點，遍歷由他出發可以到達的對象節點。
好處：
不用遍歷所有堆中的對象。
解決兩個對象互相引用而導致引用計數恒不為0的問題；
經過上述處理，沒被找到的對象會被清理掉，但是會留下內存碎片，浪費空間。所以……
妙！
把程序停止下來，把活動的對象copy到新的堆內存，連續存放，這樣就騰出了那些原先成為碎片的空間。
然而，一直copy來copy去需要有額外的堆內存來保存copy的數據，實際上copy發生的時候需要雙倍于被copy內容的堆內存同時可用。
其次，copy也需要時空開銷……
于是……
JVM就把sweep-and-mark和stop-and-copy結合起來（thinking in java有詳述）
大對象占用一個block，每個block有一個generation count作為其可用與否的標記。
一些小對象放在一個block里；
根據引用來遍歷其對象-樹的操作開始執行：
一般來說，大對象是不會被copy的；
小對象會被復制和重新管理，釋放內存碎片；
JVM在碎片多的時候進行stop-and-copy來整理碎片，騰出空間；在堆內存足夠和碎片不多的情況下，則只執行sweep-and-mark。
在這樣的垃圾回收機制下，只要是new出來的東西，真的都能回收了。某程度上還真是滴水不漏啊……
顯然是抄IBM大型機的外存管理嘛！數據集放在block中，被刪除的數據集的block標記為不可用，新建的數據集放在后面的block中。當存儲空間不夠了，整理那些已經存在又可用的數據集，存放在一片連續空間中，把碎片重新整理為可用內存，真是……
抄吧抄吧，不是罪……
posted @
2011-03-04 20:49 ArthasLee 閱讀(827) |
評論 (1) |
編輯 收藏