Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: AdmiralRalwood on November 09, 2015, 10:07:47 pm
-
AVX: http://deviance.duckish.net/downloads/fs2_open_AVX_x64.7z
SSE2: http://deviance.duckish.net/downloads/fs2_open_SSE2_x64.7z
Don't try running these through the launcher; it will almost certainly crash.
You can run them directly instead; as long as you've used the launcher to launch a regular 32-bit build before, it should have cmdline_fso.cfg already set up and ready to go.
I get an error about vcruntime140.dll being missing:
Install the Visual C++ 2015 Redistributable (https://www.microsoft.com/en-us/download/details.aspx?id=48145).
I get an error saying "unable to start correctly 0xc0000007b":
Not sure what causes this; all I can say is to Google it (https://www.google.com/?q=unable+to+start+correctly+0xc00007b) and try stuff. If you manage to fix it, let us know what you did.
What the heck are these?
These builds are 64-bit builds of FreeSpace Open. 64-bit builds have been possible for non-Windows systems for a while, but current master can't build x64 builds for Windows (for various reasons). These builds are based on Antipodes by way of m!m's cmake branch (https://github.com/asarium/fs2open.github.com/tree/cmake). No code changes were done to make them compile; Antipodes doesn't have the same x64-related problems as current master. However, these builds don't have text-to-speech or voice recognition (and I made no attempt to build FRED, either).
Try these builds. Let us know what happens. These might become the new standard in the future.
-
Haven't tried these builds, but I'll just give my :yes:.
-
... No code changes were done to make them compile ...
Well, that's not entirely true :nervous:. Current master has some type issues that just happen to work because the sizes match. I fixed those but nothing more.
-
... No code changes were done to make them compile ...
Well, that's not entirely true :nervous:. Current master has some type issues that just happen to work because the sizes match. I fixed those but nothing more.
I made no code changes to make them compile. :P
-
There are two code changes that need to be made in code.lib to make it compile, one to fix endianness detection, the other to fix a line in the call stack eval code; FRED has a few more lines that need looking at.
-
Checkpoint boxes(and other stuff you have to click mid-mission) don't agree with this build. Not sure if it's specific to the 64bit ones or the whole branch.
More specifically, the cursor will keep resetting to the middle of the screen, preventing you from clicking anything.
-
Yeah; that's an antipodes issue rather than a 64bit build issue. Recorded here (https://github.com/scp-fs2open/fs2open.github.com/issues/436)
-
While loading "War in heaven" (cinematic credits of tenebra) there's 1 error, but can continue attached below.
Later on in the mission the music will stop playing much before its suposed to, sound effects still play, no errors or notifications, it simply stops.
Error: ERANGE: String error. Please Report.
Trying to put into 32 byte buffer:
��������������������������������Radar02
File: modelread.cpp
Line: 422
ntdll.dll! NtWaitForSingleObject + 10 bytes
KERNELBASE.dll! WaitForSingleObjectEx + 156 bytes
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
fs2_open_3_7_3_SSE2_x64.exe! <no symbol>
kernel32.dll! BaseThreadInitThunk + 13 bytes
ntdll.dll! RtlUserThreadStart + 33 bytes
-
While loading "War in heaven" (cinematic credits of tenebra) there's 1 error, but can continue attached below.
Model issue not specific to 64-bit builds; there should have been a BP update to fix it recently.
Later on in the mission the music will stop playing much before its suposed to, sound effects still play, no errors or notifications, it simply stops.
Might be a bug with Antipodes; next time I compile a set of builds, I'll include a regular set of 32-bit Antipodes builds so any problems that show up in both can be ignored as problems specific to 64-bit builds.
-
The BP update introduced the model error for me.
-
Scratch that, the update apparently didn't include that fix. Expect it to be fixed in an upcoming BP update, then.
-
Thanks,
This either directly or indirectly fixed a CTD I was having with the 32 bit client.
Im running a pretty unique hardware build so I would not be surprised for the 32 bit build to have issues
-
I've tested this 64-bit build against the eleventh mission of the mod Shattered Stars, and I've got the BMPMAN assertion:
Assert: bm_bitmaps[bitmapnum].handle == handle
File: bmpman.cpp
Line: 683
Invalid bitmap handle 561502 passed to bm_get_info().
This might be due to an invalid animation somewhere else.
ntdll.dll! ZwWaitForSingleObject + 12 bytes
KERNELBASE.dll! WaitForSingleObject + 18 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! SCP_DumpStack + 354 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! WinAssert + 293 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! bm_get_info + 180 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! HudGaugeWeaponEnergy::render + 2820 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! hud_render_gauges + 555 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! hud_render_all + 37 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! game_render_hud + 150 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! game_frame + 957 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! game_do_frame + 231 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! game_do_state + 403 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! gameseq_process_events + 232 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! game_main + 787 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! WinMain + 328 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! invoke_main + 30 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! __scrt_common_main_seh + 346 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! __scrt_common_main + 13 bytes
fs2_open_3_7_3_SSE2-DEBUG.exe! WinMainCRTStartup + 8 bytes
KERNEL32.DLL! BaseThreadInitThunk + 36 bytes
ntdll.dll! RtlUnicodeStringToInteger + 595 bytes
ntdll.dll! RtlUnicodeStringToInteger + 542 bytes
EDIT: Overall, this looks promising for mods like Blue Planet and Shattered Stars. I'm looking forward to implementing it into master branch.
-
That doesn't really look like a 64bit issue. You need to check if the same issues occurs in the latest nightlies, and well as in the non-64bit antipodes builds.
-
And what about the 64-bit positioning seen in the Star Citizen trailer "From Pupil to Planet":
-
Not necessary for us.
-
I guess you might want something like that if you were doing a super high velocity mod with everything zipping around at 30000m/s but you could always just hack the HUD to display higher numbers and use post-proc to make it feel zippier and stuff.
-
Exactly. The work necessary to do 64-bit precision coordinates is only useful to mods that haven't been made yet. Starting on it without clear need strikes me as a bad investment of time.
-
I guess you might want something like that if you were doing a super high velocity mod with everything zipping around at 30000m/s but you could always just hack the HUD to display higher numbers and use post-proc to make it feel zippier and stuff.
No hack required: hud_gauges.tbl has two (http://hard-light.net/wiki/index.php/Hud_gauges.tbl#.24Length_Unit_Multiplier:) settings (http://hard-light.net/wiki/index.php/Hud_gauges.tbl#.24Speed_Unit_Multiplier:) specifically for that sort of thing.
-
I guess you might want something like that if you were doing a super high velocity mod with everything zipping around at 30000m/s but you could always just hack the HUD to display higher numbers and use post-proc to make it feel zippier and stuff.
No hack required: hud_gauges.tbl has two (http://hard-light.net/wiki/index.php/Hud_gauges.tbl#.24Length_Unit_Multiplier:) settings (http://hard-light.net/wiki/index.php/Hud_gauges.tbl#.24Speed_Unit_Multiplier:) specifically for that sort of thing.
If I recall correctly, wing commander saga used these settings to get the same hud speeds as see in the actual wing commander games.
-
:bump:
Was there a separate branch for these builds, or was it just the cmake branch? And if it's just the cmake branch then I presume you need to make changes to MSVC to compile in 64bit mode?
-
:bump:
Was there a separate branch for these builds, or was it just the cmake branch? And if it's just the cmake branch then I presume you need to make changes to MSVC to compile in 64bit mode?
Just the cmake branch, and no, no changes were necessary; the cmake branch can create 64-bit MSVC project files.
-
:bump:
Was there a separate branch for these builds, or was it just the cmake branch? And if it's just the cmake branch then I presume you need to make changes to MSVC to compile in 64bit mode?
You need to select the Win64 version of Visual Studio in the CMake configure dialog. Then CMake will generate project files that that are configured for 64-bit building.
-
Thanks guys, I'll have to see how this turns out :nervous: :D
-
Since FS2_Open 3.7.4 was released, why it is quiet here? I've never seen it committed to main branch. I've love to see it, along with large-addressing features.
-
The ability to build 64-bit builds has been integrated into the main branch but the nightlies are not built in 64-bit mode yet.
-
Is there any obstacle to doing so?
-
The poll is still active but it's currently in favor of only providing 64-bit builds.