I had to force my resolution (1600x1200) with a custom flag, newest wxlauncher 0.10.1. Otherwise it would give me "old school" resolution :)Are you using Windows 10? I also have this issue but I am unable to track it down. It randomly stopped working for some reason this week (I think it happened after a Windows update).
Yeah, it'd be nice to replace the SSE builds with AVX... and maybe ditch no-SSE completely.It doesn't make any difference anyway.
I use Windows 7.I was hoping that the issue was isolated to Windows 10 but apparently it isn't. I'll try to track it down and fix it.
we didn't really document that new functionality anywhere.Well, outside of some forum threads most people didn't read, anyway... someone remind me to go over any wiki articles on voice recognition when I have a spare minute or two.
Hopefully soon. No real issues have been reported, there are a couple of bugfixes we may debate backporting from master to 3.7.4, but I'd like at least a couple weeks for the entire RC phase, before we go final, to give poeple a chance to run it through its paces.
Also be nice to see the Linux builds still in the main sectionMaybe a 64 bit debian build would be good, instead of the 32 bit ubuntu build. I don't know of anyone that has a 32 bit computer anymore, aside from legacy systems for running older software.
Also be nice to see the Linux builds still in the main sectionMaybe a 64 bit debian build would be good, instead of the 32 bit ubuntu build. I don't know of anyone that has a 32 bit computer anymore, aside from legacy systems for running older software.
x86 is still a choice offered to consumers.x86 is the name of the whole familiy including x86_64. 32 bit x86 CPUs (aka i386) are very rare in the consumer market and most linux distributions have been moving away from providing 32 bit installation ISO for quite some time. If a linux build is provided then it should be 64 bit because that's what pretty much everyone is using. If someone is actually using a 32 bit OS then they can still compile the binary from source.
So I'm getting SEVERE frame rate drops with this release.In comparison to 3.7.2, or in comparison to nightly builds?
Is there any reason the "Don't limit FPS" flag was removed?It is no longer exposed to the launcher because it never should have been in the first place.
So I'm getting SEVERE frame rate drops with this release.In comparison to 3.7.2, or in comparison to nightly builds?Is there any reason the "Don't limit FPS" flag was removed?It is no longer exposed to the launcher because it never should have been in the first place.
So out of curiosity, what is going on with SDL? I stumbled on an old thread from a few months ago showing that someone had to use a virtual joystick to use both X-55 devices, and I plan on getting the X-56.
The biggest difference between 3.7.2 and 3.7.4 is the new deferred lighting renderer; try adding -no_deferred to your command line ("Disable Deferred Lighting" in the launcher).Thanks! Thats what was killing my FPS
I think 3.7.4 is for getting the deferred lighting bugs out before merging SDL Antipodes in 3.7.6.FYI, current plans are for the version after 3.7.4 to be 3.8.
I didn't have the impression that everyone had to use that 64-bit build in order to play those missions. Only some of us. Why is that? [/tangent]It's important to remember that a malloc failure dosn't mean that you're out of memory, just that it can't find a large enough contiguous piece of it for whatever FSO is trying to allocate. How your computer responded to its previous requests changes how free memory is laid out later, and so seemingly-unimportant things (like looking at ships in the tech room) can change if/when you hit a malloc failure.
As a stopgap, maybe it would be worthwhile to provide LAA-enabled builds of 3.7.4.I don't think it's worth the effort if true 64-bit builds are going to be possible "soon". Additionally, LAA would need to be tested well because it may break things that currently work (I don't think that's actually the case but it may happen).
I used LAA while testing something else (that consumed more memory and hence caused more malloc failures without it) and encountered no problems in some very intense missions, but that's obviously a very small sample size; I was thinking more along the lines of simply having them available with lots of warning text that they may cause unexpected problems. If nothing else, the old LAA test build thread could just be revived with some more up-to-date builds.As a stopgap, maybe it would be worthwhile to provide LAA-enabled builds of 3.7.4.I don't think it's worth the effort if true 64-bit builds are going to be possible "soon". Additionally, LAA would need to be tested well because it may break things that currently work (I don't think that's actually the case but it may happen).