New Linux game: Conquest Divide and Conquer

[Naib]

Heya, someone forwarded this thread to me and I want to clear a couple things up.

I'm not the person compiling the different builds, and I was told offering a 64 bit Linux version was annoying/non-trivial to manage (we had one in the past). Our building process is fully automated and synchronized for all platforms, in order to bring fixes and updates live immediately. Though I personally develop on a 64 bit Gentoo box, the release builds for Windows and Linux are compiled on a 32 bit Gentoo machine.

Now, is running a 32 bit application under a 64 bit system such a big deal? Because honestly, in my own experience it isn't at all. The performance is basically identical, and we're at a transition stage right now. Even on Windows my "Program Files (x86)" folder contains significantly more apps/games than my "Program Files" folder. Is there something for other distributions that makes it complicated to run 32 bit apps, or is it pure idealism? At least for me 32 and 64 bit Conquest run equally good.

Exactly! 16bit apps existed for a very long time (and to some extent still do) for 32bit windows.
The x86 processor can easily cope with it.

Multilib support has existed for linux since the year dot of 64bit distro's and running 32bit apps on a 64bit system has no performance hit - only time it is an issue is for gentoo and the binary provided emul packages that can significantly lag behind...

64bit would be nice, but does it really matter if the game is release 32bit? HoN has a 64bit client and in running HoN I don't see any part of it that warrants a 64bit version. It uses just over 2Gig in memory so a 32bit linux can cope with this (1g:3g split) - windows can't

[snuwoods]

Running multilib is just a hassle for me.
It feels like running wine, albeit a much more benign, tolerable wine.
Running a pure 64bit system is about maintaining one set of libraries instead of having to maintain the additional 32bit copies.
At this point 64bit systems are ubiquitous as most gamers have modern machines.

[Zhick]

Now, is running a 32 bit application under a 64 bit system such a big deal? Because honestly, in my own experience it isn't at all.

I just wanted to give the demo a try, but it fails to start, apparently because there's no libcrypto.so. The game doesn't ship one, and my distribution (OpenSuse 11.3) apparently also doesn't ship a 32bit libcrypto-build. So at least for me the lack of a 64bit-build means I can't play the game.

[void161]

Alright, I'll check out why managing the 64 bit build is so troublesome / what's the problem with it.

[Svartalf]

Heya, someone forwarded this thread to me and I want to clear a couple things up.

Works for me. In and of itself, my impression of you and the studio's changed quite a bit just now.

I'm not the person compiling the different builds, and I was told offering a 64 bit Linux version was annoying/non-trivial to manage (we had one in the past). Our building process is fully automated and synchronized for all platforms, in order to bring fixes and updates live immediately. Though I personally develop on a 64 bit Gentoo box, the release builds for Windows and Linux are compiled on a 32 bit Gentoo machine.

Heh... The only issue you probably have is the fact that if you did the builds on a 64-bit system you wouldn't have issues with doing automated builds, especially if you use something like Scratchbox 2 to manage the Linux side things. (Once you do that, you can actually go beyond X86 related systems pretty effortlessly...)

I should know, I've taken to doing automated builds and I plan on targeting X86, X86-64, and varied ARM based systems with Caster and Cortex Command in the near future. As it stands right now, I've an end-to-end run building both X86 and X86-64 installers from ground zero for the beta on Caster and once I sort out the sound issue with Cortex Command, I'll extend the 64-bit toolchain to auto build that game as well. Once that is done, the Pandora/Beagleboard and other ARM related chains will start to get finished so I can put a wrap on the first ARM versions of Caster and Cortex Command.

It's all in how you go about doing it.

Now, is running a 32 bit application under a 64 bit system such a big deal? Because honestly, in my own experience it isn't at all. The performance is basically identical, and we're at a transition stage right now. Even on Windows my "Program Files (x86)" folder contains significantly more apps/games than my "Program Files" folder. Is there something for other distributions that makes it complicated to run 32 bit apps, or is it pure idealism? At least for me 32 and 64 bit Conquest run equally good.

Perhaps for your application there is no real performance advantage- but that is not the case for all applications. My current 64-bit build box is performance rated to be roughly a Q6600 (AMD Phenom...) but is roughly just below a Q9500 CPU machine's performance in 32-bit mode.

Now, the main reason's not the game's speed in many indie cases but for installation experience for the users. I've had to periodically field install issues with 64-bit systems and most distributions don't install the multilib config by default and it can cause odd issues if you're doing dev work as it can grab the wrong things at times- and worse, not all of them have meta-packages to force the install of the 32-bit compatibility mode, you've got to guess at it for some people. Making people use multilib when you don't have to makes it obnoxious enough for some people to pass on your game. You've witnessed it here.

If it's not an issue (and it shouldn't be...) it's just good customer service to provide it if you can- less issues in install for your users.

[Svartalf]

Alright, I'll check out why managing the 64 bit build is so troublesome / what's the problem with it.

It's probably because you're not set up ON a 64-bit machine.

It's pretty big pain (at least until I figure out how to extend the 32-bit versions of my toolchain I'm refining right now to do it...) to do 64-bit code without a machine in 64-bits. Cross-compilers don't seem to be about for that specific path through the mix.

However, if you're on a 64-bit multilib machine, you should be able to, so long as you are careful in framing in your build scripts, build 32-bit Linux, 32-bit Windows, and 64-bit Linux.

[SephiRok]

The 64-bit build gets built just fine on our build box. The annoying part are dependencies, since it's non-trivial to emerge 64-bit packages on 32-bit (an example I can remember is unable to execute 64-bit bjam in the process of emerging boost). Switching the build box to 64-bit at this point would be quite some effort, partially because it's not only used as a build box.

So, we have to use pre-compiled packages. In the past we manually downloaded them from Debian's repos, but Gentoo's binary packages could be an option as well. What all this drags on though is packages with more dependencies, packages with different versions than their 32-bit counterparts (which could mean we can't use a feature unless we build it from source), and most of all, another build to manage (keep updating required packages and make sure everything is in order) and compile, which is time we could spend improving the game.

I have to say, I really dislike Linux in this aspect and can understand why a lot of developers don't support it. On Windows and Mac OS X there are no 32, 64 issues, and users (and devs) have to pay a lot less attention to library issues as those systems differ less between each other. By far the biggest percentage of issues our users have had were on Linux, and even if we remove the portion that might have not happened with a 64-bit build, there's still the time consumed by providing another build and deal with that build's special issues.

Anyhow, since it appears to be such a huge issue, we'll work on the 64-bit build when we get some spare time -- meaning it should be out in the upcoming weeks.

I just wanted to give the demo a try, but it fails to start, apparently because there's no libcrypto.so. The game doesn't ship one, and my distribution (OpenSuse 11.3) apparently also doesn't ship a 32bit libcrypto-build. So at least for me the lack of a 64bit-build means I can't play the game.

The new package up has libcrypto included.

[snuwoods]

Thank you for the consideration. I'll be sure to buy the game when the 64-bit build is released.

[Svartalf]

The 64-bit build gets built just fine on our build box. The annoying part are dependencies, since it's non-trivial to emerge 64-bit packages on 32-bit (an example I can remember is unable to execute 64-bit bjam in the process of emerging boost). Switching the build box to 64-bit at this point would be quite some effort, partially because it's not only used as a build box.

Ever given consideration to doing the builds isolated within Scratchbox2 sandboxes? Works wonders for the classes of problems you're describing.

So, we have to use pre-compiled packages. In the past we manually downloaded them from Debian's repos, but Gentoo's binary packages could be an option as well. What all this drags on though is packages with more dependencies, packages with different versions than their 32-bit counterparts (which could mean we can't use a feature unless we build it from source), and most of all, another build to manage (keep updating required packages and make sure everything is in order) and compile, which is time we could spend improving the game.

There's a better way...I can help out there, if you're interested.

I have to say, I really dislike Linux in this aspect and can understand why a lot of developers don't support it. On Windows and Mac OS X there are no 32, 64 issues, and users (and devs) have to pay a lot less attention to library issues as those systems differ less between each other. By far the biggest percentage of issues our users have had were on Linux, and even if we remove the portion that might have not happened with a 64-bit build, there's still the time consumed by providing another build and deal with that build's special issues.

Really... You might think that the case, but after being at working on computers and all for over twenty five years- each and every person that states this sort of thing just hasn't gotten bitten by it. The problem is called DLL-Hell on Windows, for example, and it's very real, but often glossed over by the devs because it's what they're used to.

If it is as bad as you remark- how is it that I am able to jam out a 64-bit build and a 32-bit one with no more effort than issuing a shell command?

I do this right now with Caster. As soon as I re-do the sound library I'm about to use for Cortex Command for both platforms and wire in the lua/luabind libs I'm using for it into the 64-bit toolchain set, I'll be doing the same thing for it. Once that's done, I'll be able to as easily produce the titles that understand OpenGL ES 1.1 or 2.0 for the Pandora Handheld, ARM Smartbooks, WebOS handhelds and tablets, MeeGo devices, and Android ones. I'm not THAT good. It's not rocket science, either.

The big problem is that most in the game industry is unfamiliar with the rules that apply for Linux and they're yet again different from the Windows and MacOS ones.

Anyhow, since it appears to be such a huge issue, we'll work on the 64-bit build when we get some spare time -- meaning it should be out in the upcoming weeks.

Kickin'! That sort of effort gets rewarded by myself- always.

[SephiRok]

Ever given consideration to doing the builds isolated within Scratchbox2 sandboxes? Works wonders for the classes of problems you're describing.

Gentoo's crossdev package isolates different build systems as well, I read scratchbox's site description shortly and don't see any advantage in using it.

There's a better way...I can help out there, if you're interested.

I'm interested.

Really... You might think that the case, but after being at working on computers and all for over twenty five years- each and every person that states this sort of thing just hasn't gotten bitten by it. The problem is called DLL-Hell on Windows, for example, and it's very real, but often glossed over by the devs because it's what they're used to.

DLLs are far from perfect, but we've never had issues with dependencies so far.

If it is as bad as you remark- how is it that I am able to jam out a 64-bit build and a 32-bit one with no more effort than issuing a shell command?

I can build for 32-bit Linux, 64-bit Linux, 32-bit Windows and Mac OS X with one command, generate an update for each with another and then publish these updates with a last one. Unless you mean your command checks for required dependencies and installs them appropriately.