From b67f088bba5d4c617916cb485bd91c015c7423ed Mon Sep 17 00:00:00 2001 From: user726687 <98432183+user726687@users.noreply.github.com> Date: Mon, 1 May 2023 15:34:49 +0800 Subject: [PATCH] v1.0.1 (#1) * Rename demo.txt to demo.au3 * Update README.md * Add files via upload * Add files via upload * Update README.md * Update README.md * Update README.md * Update README.md * Update README.md * Update README.md --- README.md | 17 +++++++++++------ RunDemo.vbs | 2 +- demo.txt => demo.au3 | 10 ++++++++-- 3 files changed, 20 insertions(+), 9 deletions(-) rename demo.txt => demo.au3 (95%) diff --git a/README.md b/README.md index d4846d2..3c8995e 100644 --- a/README.md +++ b/README.md @@ -1,20 +1,25 @@ # NaturalEdgePan -An RTS/MOBA camera controls scheme for the 21th century. +A modern, displacement-based edge-panning instead of the legacy velocity-based behavior of 90's RTS games. + +[Download demo here.](https://github.com/EsportToys/NaturalEdgePan/releases) https://user-images.githubusercontent.com/98432183/235227114-13128d48-fe16-4c28-af13-93ed578ad0f6.mp4 +![image](https://user-images.githubusercontent.com/98432183/235364466-d2537e0d-2602-4b69-80bf-1559104d6ba6.png) + + ## What's wrong with current systems -The cumbersome way top-down games moves the camera at a fixed velocity when the cursor touches the screen/window edge is a vestige from 90s real-time-strategy games that has stayed entirely unchanged. +The way top-down camera moves at a preset rate when the cursor touches the screen/window edge is a legacy UX largely unchanged from 90's real-time-strategy games. -While some games provides a menu option for setting a preferred preset camera speed, it takes a lot of fiddling to find an acceptable compromise between being too slow for large displacements and too fast for fine adjustments. +While some games provide menu options to adjust the panning speed/curve, it takes a lot of fiddling to find an acceptable compromise between being too slow for large displacements and too fast for fine adjustments. -This has resulted in players usually being recommended to exclusively use the minimap for large movements and middle-click drag scroll for small adjustments, leaving edge-panning an infrequently used, awkward interaction unsuited to either tasks. +This has resulted in players usually being recommended to exclusively use the minimap and hotkeys for large movements and middle-click drag scroll for small adjustments, leaving edge-panning in an awkward position being unsuited to either tasks. -Basic UX common sense tells us that an action requiring the least cognitive load is best suited to frequently performed tasks, conversely an infrequently performed task requiring conscious intent should be activated by a deliberate action. +Basic UX common sense tells us that frequently performed tasks should have little cognitive friction, while strongly effectful actions should require conscious intent to activate. -Yet both minimap clicking and middle-click drag require a conscious action (the former needing to visually confirm where you're clicking, the latter requiring a button to activate), whereas simply moving your cursor against the edge is something that has the least cognitive load. +Both minimap clicking and middle-click drag require a conscious action that interrupt unit control (the former needing to visually confirm where you're clicking, the latter requiring a button to activate), whereas simply moving your cursor against the edge is practically no different than generally manipulating your mouse. Yet the effectful auto-panning is assigned to the easy-to-accidentally-trigger edge, while performing the frequently needed stateful adjustment require you to interrupt your current task to click an obscure button. This inversion of frequency-of-action vs friction-against-activation leads to unnecessary cognitive burden in the skill acquisition process -- instead of skill-differentiation via expressivity, this is just learning-segregation via cruft. diff --git a/RunDemo.vbs b/RunDemo.vbs index cce22cb..03689a4 100644 --- a/RunDemo.vbs +++ b/RunDemo.vbs @@ -1,2 +1,2 @@ Set WshShell = WScript.CreateObject("WScript.Shell") -WshShell.Run ".\AutoIt3_x64.exe .\demo.txt" +WshShell.Run ".\AutoIt3_x64.exe .\demo.au3" diff --git a/demo.txt b/demo.au3 similarity index 95% rename from demo.txt rename to demo.au3 index b1b9d30..4357e61 100644 --- a/demo.txt +++ b/demo.au3 @@ -38,7 +38,7 @@ Func Init() @CRLF & _ "Default = Edge-Pan" & @CRLF & _ "Hold MB3 = Auto-Pan" & @CRLF & _ - "Hold MB1 = Drag-Pan" & @CRLF & _ + "Hold MB1 = Grab-Pan" & @CRLF & _ "Hold Space = Lock Cam" & @CRLF & _ "Hold Shift = Map-Pan" & @CRLF & _ "CapsLk = Lock Map-Pan" , 0 , 0 ,150,$dim[3] ) , 8.5*96/GetDpiForWindow($hWnd) ) @@ -46,6 +46,8 @@ Func Init() Global $hOverlay = GUICreate("Overlay",$dim[2],$dim[3],$dim[0],$dim[1],0x80000000,0x02080080,$hWnd) Global $hCha = GUICtrlCreateButton("",Round($xImg)+Round($xCha)-$rCha,Round($yImg)+Round($yCha)-$rCha,2*$rCha+1,2*$rCha+1) GUICtrlSetBkColor($hCha, 0xff00ff) + Global $hDrg = GUICtrlCreateButton("",-6,-6,2*3+1,2*3+1) + GUICtrlSetBkColor($hDrg, 0xffffff) GUISetBkColor(0x0000F4,$hOverlay) DllCall("user32.dll", "bool", "SetLayeredWindowAttributes", "hwnd", $hOverlay, "INT", 0x00F40000, "byte", 255, "dword", 0x03) @@ -207,9 +209,12 @@ Func ProcessInput($struct,$pos,$hWnd) $panX = $x $panY = $y AdlibRegister ( "Pan" , 16 ) + Local $dim = WinGetPos($hWnd) + GUICtrlSetPos($hDrg,$x-3-$dim[0],$y-3-$dim[1]) EndIf If BitAnd(32,$_.bflg) Then AdlibUnRegister ( "Pan" ) + GUICtrlSetPos($hDrg,-7,-7) EndIf If BitAnd(1,$_.flag) Then ; absolute movement @@ -276,6 +281,7 @@ Func ProcessInput($struct,$pos,$hWnd) ElseIf $focusChange Then resetSens() AdlibUnRegister ( "Pan" ) + GUICtrlSetPos($hDrg,-7,-7) EndIf EndFunc @@ -392,4 +398,4 @@ EndFunc Func _Clamp($min, $val, $max) Return $val<$min?$min:($val>$max?$max:$val) -EndFunc \ No newline at end of file +EndFunc