amwild
Posts: 105
Joined: 2/9/2004 Status: offline
|
quote:
ORIGINAL: Shannon V. OKeets I do not know for certain - I did not write the original code that handles this. What the program does is take the width of a panel (the full screen can be viewed as a panel), multiples it by the pixels per inch for the screen and then divides by 96. Each hexagon is 136 pixels wide at the highest zoom level, so we are talking about 1.4 inches per hex - if the density of the pixels on your monitor are 96 per inch. I am a little out of my depth here - the more you drift into hardware, the less sure I am of my footing. A simple analysis would say 1600/96 = 16 2/3 hexes at zoom level 8. I am not certain that is a valid conclusion however. As you zoom out the pixels per hex (width) drop by multiples of 17: 136, 119, 102, 85, 68, 51, 34, 17 are zoom levels 8 through 1 respectively. I expect the game to be primarily played at zoom levels 5 and 6, with some dropping back to zoom levels 3 and 4 for seeing the big picture and naval moves. Level 2 should also work for naval moves (I certainly intend to make the counters legible for that purpose). Zooming in to levels 7 and 8 will be used for analyzing close in combet - which units attack which hexes along a short section of the front line. I still am unable to answer your going in question though: "Will a larger video mode such as 1600x1200 display more physical map than 1024x768?". Sorry. Perhaps some one who is more familiar with how the hardware (monitor/video card) and software (operating system's definition of pixels per inch) interact can provide more insight into this issue. The hexes are interlaced vertically, so the 152 pixel vertical height per hex is effectively 114 pixels per row. 1200/114 = 10 1/2 hexes. As a Windows developer myself, I can say that unless C/MWiF includes code that scales visual elements to the size of the window, the larger the window, the more that should be able to be displayed in it. Thus, the more screen pixels available for the window to fit inside, the more map should be visible within a maximised window. Since I have been reading posts regarding the "number of pixels" in display element positioning, I can guess that there is probably no code that scales the map to the window size. If there was, I'd expect to be hearing about inches, centimetres or twips. Whether working in pixels, centimeters, inches or twips, Windows appears to assume that the number of pixels per whatever unit of linear measurement you use is constant for monitors (72 DPI, I think), regardless of the screen resolution. It is variable for other devices such as printers where the DPI is variable. Of course, the units used depends upon the development environment. MS products tend to use twips, or centimetres/inches if MS was being nice when they produced the development software. Some Windows system API calls require pixels. I don't know what other dev environments require for form development. With what Steve described, it seems that MWiF may scale graphics to the window size. This can be answered by performing the following tests: 1. If the size of the map window is increased or decreased, is more or less of the map shown, or do the hexes and their contents grow or shrink? 2. If the Windows screen resolution is increased or decreased, is more or less of the map shown, or do the hexes and their contents grow or shrink? It seems to me that ideally the users should have the choice between scaling the graphics or displaying more of the graphics, though if such a choice is not available, I would prefer to see more map than a scaled map, especially since scaling TTF fonts is occasionally prone to problems.
< Message edited by amwild -- 2/15/2006 10:16:55 AM >
|