[Maybe?] x64 windowed mode.

[Eskandare]

Interesting thing I have discovered. So, far as of two hours playing with sock KSP (then modded KSP) x64 Windows hasn't crashed. It crashed all the time in full screen, but is okay (so far) in a window. There are still visual bugs but runs stable. I'll update this if it does or does not explode.

UPDATE: So far running '-force-opengl' in a window is working for me. I will be testing this further with mods (at least the ones not locked out of x64) to see if the x64 stability is compromised. (I doubt it).

UPDAT2: Appears to be stable so far. I think it is worth a try to see if it works for anyone else using KSP x64 Unmoded and moded. (NOTE: This may not work for everyone.)

Edited October 13, 2014 by Eskandare
UPDATE 2

[slumpie]

A normal window or a borderless window?

[skeevy]

I just have to report that, on x64 Linux, I was alt-tabbing between my web browser and KSP yesterday, and after a few times KSP started getting really laggy and glitchy. Remembering this thread, I pulled an alt+F11 (linux command to change full screen to windowed) and it cleared all my issues right up, alt+F11 back to full screen, and KSP was running like I just started it up. It seems to me like there's some magical fix that occurs when windowed mode kicks in. I mean, it went form choppy and unplayable to completely smooth and stable in an instant.

Normal window and normal fullscreen, no borderless at all.

[Eskandare]

I just have to report that, on x64 Linux, I was alt-tabbing between my web browser and KSP yesterday, and after a few times KSP started getting really laggy and glitchy. Remembering this thread, I pulled an alt+F11 (linux command to change full screen to windowed) and it cleared all my issues right up, alt+F11 back to full screen, and KSP was running like I just started it up. It seems to me like there's some magical fix that occurs when windowed mode kicks in. I mean, it went form choppy and unplayable to completely smooth and stable in an instant.

Normal window and normal fullscreen, no borderless at all.

So far it has been inconclusive since I've had to go to an event, and then work the next day. I turned off our computer to save electricity.

Except for parts catalog having a crash after cataloging the parts, in general I haven't seen a crash yet in a normal window, but I am still testing my hypothesis. Running KSP x85 to test again, then KSP x64 to test again. My hypothesis is based on how windows manages memory addressing from a window vs. a full screen. Although not sure about the details, but I know both display methods are handeled differently (also testing -force-opengl in both settings seperately)

Edited October 13, 2014 by Eskandare

[skeevy]

Also inconclusive, but I get an fps boost windowed. Again, on linux x64.

And that Part Catalog bug is known on x64 Windows. When the prompt comes up, don't scan, instead go to Part Catalog settings and ctrl click the autotag button. It crashes when adding parts and things are already tagged, wiping the list first with ctrl+left click prevents it...at least it did on rc7 and 24.2.

[Ignath]

I'm running the Win x64 version from the STEAM Betas option.

Toolbar

Alternate Resource Panel

Chatterer

Contracts Window

Custom Asteroids

DOE

DMagic Orbital Science

Editor Extensions

EVE

FinePrint

ImprovedChaseCamera

RasterProp

KerbalEngineer

NavUtils

Kerbal Alarm Clock

KerbinSide

Kerbin Constructs

Protractor

SCANSat

mk1 Inline cockpit internals

Texture Replacer

Trajectories

Universal Storage

ModuleManager

I've had no crashing myself when using the -popupwindow launch option. That launches the game in fullscreen-windowed mode.

I've tried using both -force-opengl and not in my launch options and myself haven't seen a lot of change between the two, both seem stable for me over 2 to 4 hour sessions.

The only major bugginess I've noticed is the right-click bug creeping back in (frustrating, but not game-breaking) and the lockout of web-browsers when running in x64. I've found you can solve your browser lockout issues by right-clicking a tab/window on the browser and then your mouse clicks will work again.

[Alewx]

If there could be more tests from different ppl with different hardware gathered, it would be nice, because with that it sounds like the instability is caused by the renderer.

[Ignath]

My Hardware is as follows:

i5 2500k (currently not OC)

16GB G-Skill DDR3 RAM (4X4GB)

EVGA GeForce GTX550Ti VidCard

ASUS MoBo (not sure of exact model offhand, built the rig 3 years ago or so)

KSP is also running on an old 250GB Samsung HDD, probably something like 6 years of service on it.

[skeevy]

@Ignath...wtf aren't you running KSP on x64 Linux. Your setup would be awesome for that...I mean, you could have upwards of 14GB in mods running....and Nvidia GPU's are much better with Linux than my AMD card is...well, currently they are, but AMD is supposedly gonna move most, if not all, of the 3d code over to the open source driver sometime soon, leaving only a few bits of Catalyst as closed source. An open sourced 3d driver from AMD would really show some Linux commitment as well as allowing all the Linux gurus to take better advantage of AMD GPU hardware. It'll be a good day when that gets released.

I do find it odd that we're running different OS's and finding the benefit playing in widowed and borderless full screen. Makes this seem like it's a decent bug in KSP's coding...or it could just be another Unity 4 issue we're dealing with. Because the thread is titled about x64, I wonder how many Linux and x32 Windows users are skipping over this and not trying it out.

Also gonna do some Linux tests comparing performance with the proprietary FGLRX driver and the open source Radeon driver throughout the day. I'm just looking for any way to increase my performance. And by tests, I simply mean watching the FPS mod's window when I launch big rockets as well as comparing "how it feels" with the other driver. Actual benchmarks using benchmark software won't really show me anything substantial due to Unity 4 and how KSP utilizes threads.

[Eskandare]

What prompted to investigate this was an issue I had with Spintires where the game wasn't rendering correctly in full screen. I switched to windowed mode and it fixed everything.

Also inconclusive, but I get an fps boost windowed. Again, on linux x64.

And that Part Catalog bug is known on x64 Windows. When the prompt comes up, don't scan, instead go to Part Catalog settings and ctrl click the autotag button. It crashes when adding parts and things are already tagged, wiping the list first with ctrl+left click prevents it...at least it did on rc7 and 24.2.

The issue I saw with part catalog wss when it crashed ksp shortly after scanning and typically crashed during scene change. Once ksp was rebooted, as long as catalog didn't need to scan any parts, it ran seamlessly. (Minus minor visual bugs during scene change.)

I feel that x64 has a read write issue between scene changes and it could relate to the process of rendering, or switching renders between the scene changes.

Should test to see if this is true.

Edited October 13, 2014 by Eskandare

[skeevy]

Only reason I thought about trying windowed mode was this post and a though of, eh, it only takes a half a second to try it and restarting KSP is a 10 minute affair with 0.25.

With PC, for me, it would always crash when I'd enter the VAB or SPH with new parts needed tagging and I click auto tag. If I instead hit cancel and manually auto tagged in PC settings with a crtl+left click, no crash when tagging. With PC, I think the issue is in parsing lists; though I have seen some Wx64 r/rw issues in other threads. I also found that if I deleted the parts list before starting KSP, it wouldn't crash when entering the VAB and I had new parts. Between that and crtl+click working, it's clearly not an rw issue (if it was an r/rw issue, the list wouldn't get made in the first place). Since PC works correctly on all other platforms, just chalk it up as a Wx64 issue and don't expect it to be resolved anytime soon.

Sucks that I never actually got KSP to run with the open source Radeon driver...though I have a newer AMD GPU and it isn't fully supported yet. KSP would always crash when loading, switched back to fglrx, worked perfectly.

[Eskandare]

Only reason I thought about trying windowed mode was this post and a though of, eh, it only takes a half a second to try it and restarting KSP is a 10 minute affair with 0.25.

...I think the issue is in parsing lists...

That's the chap, and makes sense too. I never expect it to be resolved. Windows will never be resolved. lol

Sucks that I never actually got KSP to run with the open source Radeon driver...though I have a newer AMD GPU and it isn't fully supported yet. KSP would always crash when loading, switched back to fglrx, worked perfectly.

I'm currently on the system I built for my GF, it is all AMD. My original system was all AMD too and I ran a duel boot Linux with Windows but the drive controller on the mobo fried. I had issues with the AMD chipsets in Linux, even with older boards.

Edited October 14, 2014 by Eskandare

[skeevy]

I don't have any real issues with my GPU using the proprietary driver, only the open source radeon driver. I have a Sea Island based GPU (R7 260x; C. Islands in the chart) and those aren't very well supported with older Mesa and kernel versions that come with Mint 17/Ubuntu 14.04. It's the main reason I'm gonna be switching over to Arch Linux sometime real soon. Plus Arch supports using my proprietary GPU driver with Xorg and Kernel revisions higher than what AMD does.

And Win x64 will likely only be resolved with Unity 5; that's why I just switched to my Linux setup for playing KSP. I just don't see a Unity 5 KSP coming anytime soon. Why deal with Win x64 instability or Win x32 crappy ram limits when I can have the best of both while waiting on the better, updated Unity engine?