View Single Post
  #7  
Old February 23rd, 2021, 06:51 AM

Anton Anton is offline
Corporal
 
Join Date: Jul 2008
Posts: 81
Thanks: 7
Thanked 12 Times in 6 Posts
Anton is on a distinguished road
Default Re: Interface improvement for area fire

Quote:
Originally Posted by DRG View Post
Seriously.... How "inconvenient" is it to press Z+ use the mouse to hold the cursor on the target hex and click the left button to fire?

Z+Left click-Z+Left click-Z+Left click-

Seriously.... that can be done just as quickly as pressing one button repeatedly.
Yes, I am serious. Yes, it is very inconvenient, especially when the firer and target are more than a screen away, so that you have to scroll from firer to target hex again and again. After all, WinSPWW2 still supports resolutions from as low as 640x480, where much scrolling around is necessary.

Quote:
Originally Posted by DRG View Post
Even if it wasn't a PITA to code it's a trivial issue but that is what the game is down to after 20+ years of development
Well, details make perfection, and whether anything is hard to do or not—is the problem of the programmer, not of the user. I will cite an example from my own contribution to free software—I am implementing a trivial and obvious function in an MS-DOS emulator—pixel-perfect magnification without either the jaggedness of nearest-neighbor interpolation nor the blur of the bilinear, because low-res pixel-art must be shown in sharp regular pixels.

Now, this upscaling of the emulated display with integer horizontal and vertical scales was very easy to do, but I found it requires that the emulator application be high-DPI aware in order to avoid unwanted zooming by the OS, and when I made it so, the cursor and UI elements became very small of high DPI displays, so I had to implement programmatic generation of the cursor bitmap of a suitable size and an upscaling of the emulator's raster UI. Then I found that different OSes have different limitations on cursor size, which the program has to know about, too. Furthermore, whereas display scale is easy to estimate by querying the desktop dimensions, it is not so with cursor size, which requires analysis of several factors: desktop dimensions, system DPI, and window-specific DPI. The algorithm is further complicated by the need to use OS-specific APIs and unavailability of some of the values on some of the supported OSes.

This shows how difficult it may be to implement such trivial detail as integer magnification, but it is certainly worth it, and it is my headache, not that of my users.
Reply With Quote