project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Kaz

Pages: [1]
1
While testing another bug, I found this one. As I started he Dam map, I moved a soldier in the first turn to square (136,137,0) as shown under debug_map 3. As the soldier entes the building the square shows to have been occupied by a civilian, yet the soldier keeps moving to that square, until at the end of the motion, both the soldier and the civilian are standing in the same square, as shown in the first screenshot. Bad as this is, if you leave the soldier at that spot and end the turn, a little while later (presumably as the civilian's tries to move or something else) the game crashes claiming a failed assertion in file src\game\g_ai.c, line 516. It is my idea that the check for "square occupied" shows unoccupied for squares the player does not see, and is not rechecked while the soldier is moving.

Cheers!

[attachment deleted by admin]

2
Feature Requests / Display problems on high PPI screens
« on: April 05, 2009, 04:14:44 am »
An unfortunate accident with my laptop recently forced me to get a new display panel, and the new panel is very high resolution for the size (1680x1050 on 15.4"). Things looked so small that I did some research on the PPI configuration available for Windows Vista. As a result of this, I have configured the setting to the actual PPI setting ofmy new panel (129 PPI). This, combined with the PPI VIrtualization technology introduced in Vista has given a vey pleasant overall result. See http://blogs.msdn.com/kamvedbrat/archive/2006/12/02/dpi-scaling-in-windows-vista.aspx for more information.

Unfortunately, UFO:AI has an annoying problem with this. Since the game uses the pixel as it's basic unit, it is essentially a PPI aware application, so PPI virtualization should not mess with it. The catch: the executable is not marcked as PPI aware, so the OS virtualizes PPI. What this does is use the compositing engine to scale the windows as needed to the configured PPI configuration. Since this is usually done in hardware, perofmance is not affected much, but as a result even a 1024x768 window gets scaled larger than my entire screen when accounting for title bar and other decorations. My first workaround was to lower to mode 5 (960x720) which just fit in the physical screen. Unfortunately, between the downsampling to 960x720 and the upscaling from the virtualized PPI buffer the result was plain ugly.

Even worse was firing up the game in full screen mode. The upscaling remained in effect, blowing parts of the game display off screen and leaving me without a functional mouse cursor. I had to alt-tab out of the program and kill it from the OS.

Some more research, pointed me to an application compatibility property which allows you to disable the PPI virtualization for the app, without touching the rest of the system. To do this, you have to open the properties of the executable, go to the Compatibility tab and mark the "Disable display scaling on high DPI settings" checkbox. The game is again working as expected, in both windowed mode and full screen mode.

I will keep researching how to make this behaviour the default so the game works as expected out of the box in the future. Any new developments will be posted here.

Cheers!

Update: The definitive solution is to mark the application as "DPI aware" using a manifest. See the PDF document in the link above or http://www.rw-designer.com/DPI-aware for detailed information on this manifest. How to do this has already flown way over my head. Perhaps someone with more Windows development experience can add some information?

Pages: [1]