munchimon

There is no way to have a game window with the size of the screen (game engine limitation). Windowed mode is quite useless because you keep slipping out of the game's window.

Hooray! \o/

- Processor: AMD Phenom II X6 1090T Processor (6 CPUs), ~3.2GHz - Card name: AMD Radeon HD 6900 Series (actually a 6950 based on AMD's reference board, 2 GiB) Other system's specs are in post #1. As Intel+AMD, nVidia+AMD is affected (dee post #16) I'm not sure this is hardware specific, but then again I'm not the developer

Hi Matthew, thanks for checking back! What makes me wonder is the diversity of systems affected (see post #16): - AMD and Intel CPUs - AMD and nVidia GPUs - Win7 and win 8

If you're going to stick with flat topology 2D maps disregarding 3D aspects like curvature etc, then for consistency remember to remove the sinusodial day/night border as it is an effect of a spherical world FMPOV the flat 2D map is a true letdown, it makes the game look somewhat casual. It remembers me of Uplink. In Uplink distances were not that meaningful and the sperical nature of Earth neglectible. However in XCOM the strategic placement of bases is very important and goes down the drain on a flat map. For example having interception bases at north/southpole is a very clever way to reach the warmer climate areas with population at a short travelling distance and without having to chase an UFO along the equator. Base placement on a sperical playfield is a very core-ish game element for me and I think it ties the player very much to "his world" as the "real" world lies at his fingertips to be rotated, zoomed etc., just what Google Earth gave its affections.

Thanks Giovanni. I did not know it's a limitation of the game-engine. Graying out the checkbox would be nice but I'd consider it somewhat lowprio, I was just puzzled by the game's behaviour.

Then for consistency the "windowed" checkbox should be disabled if the game would go fullscreen, otherwise confused user ^^ Then what's the problem having a game window with the size of the screen? This way other windows (like you E-Mail-client, spreadsheet, text editor or whatever) could float above the game screen, exactly what I personally would have liked to be possible. (and thought possible because of "windowed") Also 1920x1080 leaves me around 120px to store stuff at without overlaying the game screen for quick notices.

Let it run on a small resolution and windowed. It run for a very long time, giving me hopes ... but eventually froze again

Selecting windowed and a horizontal resolution equal to the screen's resolution makes game go always fullscreen, regardless of vertical resolution selection and having windowed ticked.

Yes I read about the engine and half expected such an answer. But maybe some other load could be sent into another thread so the OS puts it on a different core? If redrawing the screen only when necessary isn't possible then at least vsync should be done. This limits redraw to 60 Hz against the 300+ Hz otherwise which are complete overkill.

Howdy, two bugs or at least structural deficits. 1. FPS not limited The screen redraws do not seem to be limited. So when a screen has been drawn the next one is right away in the pipeline. I usually use a framerate limiter (60 fps) so this was not that apparent to me but when I removed the limiter I noticed Xenonauts to shoot up FPS like gone crazy. This is not a good way. The screen should be redrawn only, and ONLY then, when the contents of the display have changed. This might sound a little weird and maybe many people are not caring about this, but with the current state my GPU is redrawing frames like wild, consuming power (200 Watt). Entirely unnecessarily, because the screen has not changed - there's just nothing new to show the user again. Please see attached screenshots, the FPS are highlighted by a red rectangle. And pleeease fix this, it's just a bad practice. 2. CPU only single core usage I've got a six-core Phenom-II. Multicore processors have been around like nearly 10 years. Even my phone has 4 cores. Thus by only utilizing one of the, in my case, six cores, makes this core go to 100% usage, which in return makes the whole CPU go to it's fullest speed (in my case 3.6 GHz), consuming power unnecessarily. The other cores are nearly idle and just don't know what to do with their increased free processing time. Making the game multicore capable and spreading the workload across cores would therefore use only 1/6th of the power necessary, or the other way around: currently it is wasting 83% processing power, consumes energy, heats the CPU and makes the fans swirl for nothing. In the attached graphics the cores are highlighted with a green box, right from this you can see the CPU frequency. Programming with multiple threads isn't that hard, please make it right. However I think in this late phase of development improving code that way is not easily done. Sorry if this might sound rude, english isn't my native language. However I was frankly stumped by these two points.

you guys seriously need a bug tracker...

Is there a way to provide a torrent-system or such?

wow this looks awesome! modern tech and oldschool feelings blend oh so well ^^

If your computer does not hard lock, this isn't the thread for you