64bit version of GameCore?

[hikmayan]

We do not currently have any plans for a 64 bit version of the engine.  The biggest issue with this is backwards / downwards compatibility, both from the tools standpoint and from the completed games standpoint.  If you develop your game purely for 64 bit operating systems, then you shut out a significant percentage of the current gaming audience.
We are more interested currently in getting our OSX version out the door - which is also a 64 bit OS, yes, but even so, 64 bit support, on a whole, has been seriously lacking throughout the industry.

It's cleared as stated above...GC_64bit Engine is not ruled out totally.How many users out there really have a 64bit Vs. 32bit?. It is instructive to take a detailed look at the history of specific technologies which once differentiated workstations from personal computers. As a Game developer,you don't want to shut out completely gammers out there who refused to go 64bit oe even wanna upgrade to that "High end PC";yes! a lot of users are sort of swiching but ...really...the percentage of those users is not that high yet. Flexibily in all things is always a way to go. For those of us who want the 64bit Engine,will just have to wait for "GC Team" to implement, untill then 32bit will do for now. it's good to know among other things:
As of June 2008, the number of personal computers in use worldwide hit one billion, while another billion is expected to be reached by 2014. Mature markets like the United States, Western Europe and Japan accounted for 58 percent of the worldwide installed PCs. The emerging markets were expected to double their installed PCs by 2013 and to take 70 percent of the second billion PCs. About 180 million PCs (16 percent of the existing installed base) were expected to be replaced and 35 million to be dumped into landfill in 2008. The whole installed base grew 12 percent annually.These results are just based on Personal PC regardless 32bit/64bit. Game developer must look at the big picture.

[PuckerFactor]

It's cleared as stated above...GC_64bit Engine is not ruled out totally.How many users out there really have a 64bit Vs. 32bit?. It is instructive to take a detailed look at the history of specific technologies which once differentiated workstations from personal computers. As a Game developer,you don't want to shut out completely gammers out there who refused to go 64bit oe even wanna upgrade to that "High end PC";yes! a lot of users are sort of swiching but ...really...the percentage of those users is not that high yet. Flexibily in all things is always a way to go. For those of us who want the 64bit Engine,will just have to wait for "GC Team" to implement, untill then 32bit will do for now. it's good to know among other things:

How many different ways can I re-explain this?

1. Not talking about a 64bit game
2. Not talking about a Client having to run a 64bit OS to run the game (same as point no1)
3. Not talking about a 64bit game engine

Talking about 64BIT DEVELOPMENT (EDITOR) TOOLS!

[Delerna]

apologies to pucker factor. I too, thought we were talking about 64-bit games.
Reread your posts and you are quite right. You have indeed been talking about
tools for game creation. I watched a promo video for 64-bit a while back and
one of the benefits being pushed was the extra power that developers would have
at their finger tips to aid in the development of games for 32-bit.

The example they used was in the generation of cut-scene video for the game.
What took hours to create on a 32-bit computer was reduced to minutes on 64-bit

I also have a 32-bit pc. Don't have the OS yet but will definitely get one as 64-bit tools become available to me.
Also only have 2 gig of ram but will definitely get more as 64-bit tools become available to me.

So, now,  I ask the question also.

[hikmayan]

There is no need to ask the question also and yes!, you were talking about "64BIT DEVELOPMENT (EDITOR) TOOLS!"....the question now is, do you see my point at all??...I don't think so!.In that case,my apology to you or anyone for that matter feel my reply is off-topic. ...no need to re-explain,thank you.

[gekido]

we've discussed this a bit offline, but there are a couple of things that should be explained for users that aren't familiar with the gamecore development environment versus other game development tools / environments.

The gamecore development environment IS the gamecore 'game' environment.  They are literally one and the same - share 100% of the same code base.  there is a few differences in the way that the code is built, but there is no difference between the game editor and the gameshell from a code standpoint.  so asking for a 64 bit version of development tools IS asking for a 64 bit version of the game since they are one and the same.  when you test your game with gamecore (and during the entire production of the game) you are using the same executable as the editor - the editor isn't spawning a seperate instance of an application - it literally IS the same application. 

Everything with gamecore is completely integrated - editor / tools / game - this is one of the biggest benefits of using GameCore - the editing environment is running the identical renderer as the final game - it's not a modified version crammed into a sub-window or something.  the buttons & interface in the editor are using the exact same interface gui widgets & interface layouts as you are in your gamecore game.  The fact that everything is unified gives us significant advantages when developing the tools - we don't have to maintain completely independent codebases - our editor doesn't get out of date or fall behind (which i've seen happen in several engines, including ones that i've been involved with) - everything being unified means that we are able to focus our development effort on the single codebase and maximize our effort as a result.

granted during development, being able to load larger unfinished / production textures does have it's advantages, however the editor (and game) will automatically manage and unload textures if you run out of video textures and automatically downres them to lower mip-levels as necessary.  in this regard you can use larger 'source' textures as desired and the engine should manage them automatically for you.  you don't have granular control over when textures are downrezzed currently, but it does manage them quite effectively - and the texture streaming is done on a seperate thread, so for multi-core / faster machines the texture loading should be fairly smooth.

the other side of the equation is that with gamecore we are releasing a commercial product for general consumption instead of just a source dump of whatever the latest build of our internal game happens to be - this is very different than typical engine licensing, in that we have to assume that the build that we ship to users TODAY is a version that will be used to ship products.

Future proofing is something that we are always juggling, and input from the community here helps narrow our focus - everything that you see in GameCore (versus the prior Beyond Virtual engine) is a result of feedback and input from the community.  The move to 64 bit (and multicore / multiprocessor) editions is inevitable - like everything, it's just a matter of timing.

[DPF]

Nice to hear that this is open ended, something to look forward to.

What do you think of multi threaded processing to start with? How does CG take advantage of X2 and quadcore CPUs atm?

I could use a CG64 with greater capacity to use as a real-time rendering engine for my LW projects.

While working with LW 64 in layout with real-time playback is very nice, OGL 4096 textures, real-time animated procedural textures, alpha transparency, random scale instancing of tree and vegetation objects, large terrain maps, etc , there are things that a dedicated 3D engine could do better, like hardware shaders, for example.

An entire LW scene with textures, objects, terrain, and basic animation is saved as a single FBX file, then loaded into GC to be used as an ambient animated environment, or simply the subject for realtime rendering of the scene for video/AVI  capture.

 

[gekido]

gamecore does have some multi-core support.  sound is done on a seperate thread, texture streaming is done on a seperate thread and a few other things.  I believe we are using ODE as a multithreaded library, but i'm not 100% sure.

frankly, these are the kinds of things that we haven't really focused on up until now - getting all of the features that we want in place is our first goal, optimization and hardware-specific tweaks is a later step.  optimization is always best left for last ;}

as we knock items off of our to-do list, it will free up developer time to look into things like multi-core optimizations etc.

[hikmayan]

That's sounds good. One step at a time will do fine. That's what other developers are doing...taking each feature implemented and stable off the plate then add new;there is no need to keep piling up stuff features on the same plate...as we all know from experience,the results are always deadly.

[flim]

I'd like to know when 64bit version available? 

[An0obis]

I'd like to know when 64bit version available? 

Holy Necro, Batman!!


...I'm going to guess the answer is the same as it was in 2008. I wouldn't expect them to change until it makes real sense to do so.

[flim]

I download UDK and installed tonight, it comes with 64-bit version.

[An0obis]

And?

Here's June 2010 Valve hardware survey numbers...


Windows XP 32 bit
35.28%
-1.53%

Windows 7 64 bit
28.51%
+1.94%

Windows Vista 32 bit
14.98%
-0.86%

Windows 7
12.91%
+0.43%

Windows Vista 64 bit
7.22%
+0.04%

Windows XP 64 bit
0.60%
+0.03%

Windows 2003 64 bit
0.34%
-0.03%

Other
0.15%
-0.03%

[flim]

The tend is 64-bit is growing. And why not offer a 32-bit and 64-bit version for user to choose if the engine can publish both?

Or reserve 64-bit as Pro feature?