64-bit unitsync for Windows?

[Cheesecan]

Why is there no 64-bit executable available for Windows???

I don't know anyone who plays games and still runs a 32-bit Windows.

This is causing problems when an external 64-bit application tries to load the 32-bit unitsync dll.

[abma]

This is causing problems when an external 64-bit application tries to load the 32-bit unitsync dll.

what problems? afaik a 64 bit application can't load a 32 bit dll. all aplications using unitsync are currently 32 bit, so everything should work well...

[Cheesecan]

That's correct it's not possible to load.

All applications using unitsync are 32-bit because they have to be. This is blocking progress.

[Licho]

Why the hell do you even want 64bit? There is no benefit

[danil_kalina]

It is not the proper time for it, I think.

For now, Spring allocates approximately 500 MB for playing
If someone makes a huge map, for example 4 times larger We will need 64 bit. more units on the battlefield, more powerful CPU 12 core, not buggy spring-multithreaded. I think you get me point.

[Jools]

There's a lot of people still running 32-bit windows (and probably other OS:s too).

I thought that x64 systems were backwards compatible with 32-bit ones. What kind of 64-bit app are you talking about?

I have seen the issue once, when running windows powershell. If you use the x64 version you can't use it together with windows powermenu (a program that let's you send windows to minimise to the system tray), but luckily there's a x86 version of powershell that you can use instead.

Edit: that's related to spring only by the fact that it's my preferred method of launching spads.

[Jools]

Is the main benefit of going x64 that you can use more than 2 Gb of memory?

[hoijui]

if you provide a 64bit MinGW build-slave, and you provide all the fixes required to compile there, there cold be 64bit releases too.
... i quite agree though, that it is of little to no use at the moment.

[Cheesecan]

I don't really care if spring is 64-bit, but unitsync.dll should be provided in a 64-bit version.

This way 3rd party programs don't need to be limited to x86 if they load unitsync.

My personal reason being some people are running JRE x64 now. I want to maintain compatibility for them and not have to force them to install JRE x86.

Also it just seems like good practice at this point in time. Many graphics libraries e.g. lwjgl provide x64 DLLs.

[hoijui]

if you provide a 64bit MinGW build-slave, ...

[danil_kalina]

if you provide a 64bit MinGW build-slave, ...

Download sezero_4.5_20111101 ( mingw 4.5.4 )
That package passed all stack checking. Try another packages

http://sourceforge.net/projects/mingw-w ... %20Builds/

[Forboding Angel]

Is the main benefit of going x64 that you can use more than 2 Gb of memory?

If spring is using that much memory, something is very very wrong.

Why the hell do you even want 64bit? There is no benefit

^^ this.

[Cheesecan]

Thread title was misleading(not my own). This was originally a question posted in the FAQ thread not a feature request per se. Changed the title now to better reflect the subject.

The issue is not spring itself but unitsync which is loaded by lobbies, AIs, bots, etc.

It doesn't make a lot of sense to run a 64-bit version of spring unless maps were to suddenly get a lot larger. Of course a lot bigger isn't as radical as it sounds, if we are using 32x32=16384x16384 pixels to show a very large map today at 32 bpp without compression you get a 1 gb bitmap file. If you then increase it to say 64x64 you suddenly have 4gb file which means you'll be wanting 64-bit spring. Since spring is an open source engine it would make sense to make it future proof as there is no best before-date.

I'm willing to simply drop the issue and tell people to install x86 JRE - if I am the only person who gives a damn then it's not worth the trouble for the person doing the releases.

[hoijui]

you obviously don't give a damn, cause else you would...

provide a 64bit MinGW build-slave

tip: i am trying to show you how you ridicule yourself. repeating yourself over and over does not help your cause; it turns you into a troll.

[Cheesecan]

you obviously don't give a damn, cause else you would...

provide a 64bit MinGW build-slave

tip: i am trying to show you how you ridicule yourself. repeating yourself over and over does not help your cause; it turns you into a troll.

Obviously I don't want to bother doing it myself, but I also want to motivate someone else into thinking it's a worthwhile effort.

*saint*

[Forboding Angel]

From a creation standpoint, a 64x64 map isn't feasible (assuming you're using an actual texture and not just a single color).

[Cheesecan]

Why not? You build it from say two symmetrical 64x32 or four 32x32..

[Forboding Angel]

Orly? Well since it's that simple, then why don't you go try it (Good fucking luck. Oh btw, you can only use png or bmp as the file format. Jpg has a hard limit of something like 30kx30k pixels. Also, the compiler will crash, so have fun getting around that one).

Also, you're missing the obvious fact that spring simply wouldn't load it, and that has nothing to do with 32/64 bit. Spring refuses to load anything larger than 44x44 iirc.

And if you DID manage to load a 64x64, your graphics card would immediately rip itself in half due to the strain.

[Cheesecan]

Since you already figured out which things don't work, set about making them work instead of pointlessly raging. You're not even on topic.

[Forboding Angel]

I'm not raging. Nowhere even close. Get a grip.

I am informing you that contrary to your objections, 64bit spring is more or less pointless at this juncture because there is no benefit. Unfortunately you failed to see the reason and logic behind such a statement so I explained further.

I have spent countless hours trying to make gigantic maps work. 44x44 is effectively the limit. If you make it past the compiler (good luck, you'll need it), you won't make it past spring. And if you did actually make it into spring, the map geometry would cause your gpu to spontaneously combust.

I'm being sort of silly to make a serious point. There are bottlenecks, but the largest and most pertinent bottlenecks have nothing to do with 32/64 bit.

The engine devs will give you short concise explainations that you won't understand in most likelihood. I am giving you an explanation that is easy to read and understand.