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

Sorry I haven't responded, I've been away for the last days. Well it seems there are other people that experience similar difficulties. From http://www.goldhawkinteractive.com/forums/showthread.php/1620-Windows-becomes-unresponsive-while-playing-Xenonauts You've seen this thread already. If I find the time today or in the next days I will perform some more tests, e.g. locking the GPU at a single power state so it doesn't change between light/medium/high load power states, trying windowed mode and other tests that come to mind until then.

Damn the forum is eating my posts... (also got a HTTP response 500... nice...) Short summary because I won't write all the stuff again: freezes with: - Catalyst 12.10, V17.52 while showing a soldier moving along the laid out path - Catalyst 12.10, Kickstarter version during "hidden movement" screen - Catalyst 13.1, Kickstarter version while showing alien reaction fire within NPCs' turn CPU and GPU Temperatures were always below 50°C

Running the kickstarter version with Catalyst 13.1 gave me 5-10 minutes of gameplay before freeze. This time while showing alien reaction fire during the NPCs' turn. FYI GPU temperature was 47°C, CPU temperature was 46.5°C

This were my exactly first thoughts. Such a hard lockup is usually only possible by hardware hickups or very hardware-centric drivers (e.g. VGA) The card runs very cold and under normal usage never exceeds 65°C (custom VGA fan, very good computer case) which leaves plenty of headroom... True. alas, the rig runs stable since 1,5 years. Windows, Linux, low usage, high usage. no, never. I've run Crysis 2 + DX10 + HD textures for several hours without a glitch (never exceeding the 65°C), Crysis and Crysis warhead likewise. Metro 2033 for hours. Also Intel Burn in test, OCCT, Furmark, etc. all run stable with the normal settings I run. However as stated in the opening post I've even reverted to the original stock BIOS so it runs plain vanilla hardware just as the vendor intended to no avail. I'm currently running AMD Catalyst 12.10, from October 2012. But I've got 1301081458-9.012-121219a-151592C-ATI (aka Catalyst 13.1) sitting here, too, so maybe I'll try this one. memtest from UBCD came out okay. However I don't remember freezes with the Xenonauts kickstarter version (Demo 10.2). Maybe I'll fire this one up and check if this version triggers the Gremlin, too.

Oh Chris, don't worry. I just wanted to make sure I'm not missing something

Since I'm the OP I'm not quite sure who you're referring to 100% complete freeze. No mouse movement, no HDD activity anymore, not even keyboard lights working (scroll lock, caps lock, etc.) So far I have encountered this only during ground combat. But then again I've become somewhat shy after the first lock ups. After having figured out it was always reprodible I had no need to have it wrecked yet again ^^ It happened during the initial turn, the turn you get to move your soldiers the first time. movement turn, not hidden turn Just moving. It crashed while the movement animation played. However the animation is not necessary as it locked up the other time without any movement IIRC. I think there are others with the same effect (to my ears) -> http://www.goldhawkinteractive.com/forums/showthread.php/1620-Windows-becomes-unresponsive-while-playing-Xenonauts

For me it happened during my soldier movement phase. I selected one of the poor slobs and had him trample down a field of crops and during the animation of the solider moving along the path it froze.

Just found this thread after posting one myself (see below) Game causes Windows and whole computer to freeze, only a hard reset/power cycle does help. Glad others are seeing this too. For specs and problem description see my thread -> http://www.goldhawkinteractive.com/forums/showthread.php/3999-V17-52-Ground-Combat-Computer-Freeze-Hard-Lock

Howdy everyone This is my first post to the forums, so please be gentle ^^ Usually I just lurk at forums but this time I was motivated to create a post because of the severity of the situation: When in ground combat my computer frequently freezes with a hard lock. No more sound playing, no mouse movement, no harddrive action, not even the keyboard lights (scroll lock/etc) are responsive, really a deep deep frozen solid rock. Long wall of text: At first I thought it might be my video card because it is a Radeon 6950 with the shader-unlock-mod and additional undervoltaging. To my defence I'm under/overvolting and over/underclocking CPUs and GPUs now since my 486DX2-66. The system is (as far tests can go) rock stable with prime, intel-burn-in-test, Crysis, Metro 2033, OCCT, Furmark and everything I've thrown at it. So this was quite unexpected. Being a defesive nature of course I thought my special set-up was responsible for this, having Xenonauts maybe trigger something I might have overlooked. So to rule this out I flashed back the original BIOS of the card, reverting it to original factory defaults. A power cycle later I disabled MSI Afterburner, HWiNFO64 and every other hardware-centric software to minimize crosstalk and interactions to the hardware (never had any issue with this, but for testing rule out everything remotely associated). I fired up Xenonauts again and resumed the last savegame. I was pleased to witness a stable game. For some minutes. Then it locked up again. Then I rethought of something I might have missed. And after nothing came to my mind I thought maybe it would be best to report this at the forum. Maybe others have encountered this too, maybe there is something the devs would like to have a drift at. Essentially the game is currently unplayable for me. Starting it endangers my data as the computer hard locks with all caches unwritten to discs, corrupting file system and data files and programs getting panic because of being shut down unclean. (I HAD to fix some corrupted data, god bless backups!) snipped dxdiag: ------------------System Information------------------ Operating System: Windows 7 64-bit (6.1, Build 7601) Service Pack 1 Processor: AMD Phenom II X6 1090T Processor (6 CPUs), ~3.2GHz Memory: 8192MB RAMAvailable OS Memory: 8186MB RAM Page File: 3620MB used, 4562MB available Windows Dir: C:\Windows DirectX Version: DirectX 11DX Setup Parameters: Not found User DPI Setting: Using System DPISystem DPI Setting: 96 DPI (100 percent) DWM DPI Scaling: Disabled DxDiag Version: 6.01.7601.17514 32bit Unicode------------DxDiag Notes------------ Display Tab 1: No problems found. Sound Tab 1: No problems found. Input Tab: No problems found.---------------Display Devices--------------- Card name: AMD Radeon HD 6900 Series Manufacturer: Advanced Micro Devices, Inc. Chip type: AMD Radeon Graphics Processor (0x6719) DAC type: Internal DAC(400MHz) Device Key: Enum\PCI\VEN_1002&DEV_6719&SUBSYS_0B001002&REV_00 Display Memory: 1771 MB Dedicated Memory: 2030 MB Shared Memory: 3836 MB Current Mode: 1920 x 1200 (32 bit) (60Hz) Monitor Name: PnP-Monitor (Standard) Native Mode: 1920 x 1200(p) (59.950Hz) Output Type: DVI Driver Name: aticfx64.dll,aticfx64.dll,aticfx64.dll,aticfx32,aticfx32,aticfx32,atiumd64.dll,atidxx64.dll,atidxx64.dll,atiumdag,atidxx32,atidxx32,atiumdva,atiumd6a.cap,atitmm64.dllDriver File Version: 8.17.0010.1151 (English) Driver Version: 9.2.0.0 DDI Version: 11 Driver Model: WDDM 1.1 Driver Attributes: Final Retail Driver Date/Size: 9/28/2012 02:41:40, 1120768 bytes WHQL Logo'd: n/a WHQL Date Stamp: n/a Device Identifier: {D7B71EE2-2459-11CF-CD77-0A2BBEC2C535} Vendor ID: 0x1002 Device ID: 0x6719 SubSys ID: 0x0B001002 Revision ID: 0x0000Driver Strong Name: oem12.inf:ATI.Mfg.NTamd64.6.1:ati2mtag_NICayman:9.2.0.0:pci\ven_1002&dev_6719 Rank Of Driver: 00E62001 Video Accel: ModeMPEG2_A ModeMPEG2_C Deinterlace Caps: {6E8329FF-B642-418B-BCF0-BCB6591E255F}: Format(In/Out)=(YUY2,YUY2) Frames(Prev/Fwd/Back)=(0,0,1) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY DeinterlaceTech_PixelAdaptive {335AA36E-7884-43A4-9C91-7F87FAF3E37E}: Format(In/Out)=(YUY2,YUY2) Frames(Prev/Fwd/Back)=(0,0,0) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY DeinterlaceTech_BOBVerticalStretch {5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}: Format(In/Out)=(YUY2,YUY2) Frames(Prev/Fwd/Back)=(0,0,0) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY {6E8329FF-B642-418B-BCF0-BCB6591E255F}: Format(In/Out)=(UYVY,UYVY) Frames(Prev/Fwd/Back)=(0,0,1) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY DeinterlaceTech_PixelAdaptive {335AA36E-7884-43A4-9C91-7F87FAF3E37E}: Format(In/Out)=(UYVY,UYVY) Frames(Prev/Fwd/Back)=(0,0,0) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY DeinterlaceTech_BOBVerticalStretch {5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}: Format(In/Out)=(UYVY,UYVY) Frames(Prev/Fwd/Back)=(0,0,0) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY {5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}: Format(In/Out)=(YV12,0x32315659) Frames(Prev/Fwd/Back)=(0,0,0) Caps= {3C5323C1-6FB7-44F5-9081-056BF2EE449D}: Format(In/Out)=(NV12,0x3231564e) Frames(Prev/Fwd/Back)=(0,0,2) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY DeinterlaceTech_PixelAdaptive {552C0DAD-CCBC-420B-83C8-74943CF9F1A6}: Format(In/Out)=(NV12,0x3231564e) Frames(Prev/Fwd/Back)=(0,0,2) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY DeinterlaceTech_PixelAdaptive {6E8329FF-B642-418B-BCF0-BCB6591E255F}: Format(In/Out)=(NV12,0x3231564e) Frames(Prev/Fwd/Back)=(0,0,1) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY DeinterlaceTech_PixelAdaptive {335AA36E-7884-43A4-9C91-7F87FAF3E37E}: Format(In/Out)=(NV12,0x3231564e) Frames(Prev/Fwd/Back)=(0,0,0) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY DeinterlaceTech_BOBVerticalStretch {5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}: Format(In/Out)=(NV12,0x3231564e) Frames(Prev/Fwd/Back)=(0,0,0) Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY {5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}: Format(In/Out)=(IMC1,UNKNOWN) Frames(Prev/Fwd/Back)=(0,0,0) Caps= {5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}: Format(In/Out)=(IMC2,UNKNOWN) Frames(Prev/Fwd/Back)=(0,0,0) Caps= {5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}: Format(In/Out)=(IMC3,UNKNOWN) Frames(Prev/Fwd/Back)=(0,0,0) Caps= {5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}: Format(In/Out)=(IMC4,UNKNOWN) Frames(Prev/Fwd/Back)=(0,0,0) Caps= {5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}: Format(In/Out)=(S340,UNKNOWN) Frames(Prev/Fwd/Back)=(0,0,0) Caps= {5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}: Format(In/Out)=(S342,UNKNOWN) Frames(Prev/Fwd/Back)=(0,0,0) Caps= D3D9 Overlay: Not Supported DXVA-HD: Not Supported DDraw Status: Enabled D3D Status: Enabled AGP Status: Enabled

I can confirm the observation. After a combat (even quick-aborting triggers this, so it's easy and quick to test) the top row of the geoscape buttons (bases, research, workshop, xenopedia) does not hover and is not clickable. The lower row (build base, intercept) works flawless. Resolution 1920x1200 Always reproducable