On 8/12/2012 4:12 PM, Walter Bright wrote:
> On 8/12/2012 1:38 AM, Alex Rønne Petersen wrote:
>> One question: Will the 32-bit tool chain also be able to use the MSVC
>> runtime
>> and linker eventually?
>
> It's not the current plan. Frankly, I think 32 bits is rapidly becoming
> irrelevant on the desktop.

Post windows 8 launch we should start seeing mainstream games shipping 32 and 64 bit binaries together in the same box.  We already have moved off of 32 bit in house for our editors and tools.  The biggest hangup is Microsoft keeps shipping 32 bit OSes, and we still have to support XP at least through the end of the year.  With a little luck Win8 will be the last 32 bit one.

On 12.08.2012 23:21, Sean Cavanaugh wrote:
>
> Post windows 8 launch we should start seeing mainstream games shipping
> 32 and 64 bit binaries together in the same box.  We already have moved
> off of 32 bit in house for our editors and tools.  The biggest hangup is
> Microsoft keeps shipping 32 bit OSes, and we still have to support XP at
> least through the end of the year.  With a little luck Win8 will be the
> last 32 bit one.
>

Can I ask, what are the reasons you want to move to 64 bits on the Windows platform?  Is it higher memory requirements or something else? The game with the highest memory use I've got installed is AFAIK Starcraft II, still at only about one GB.  And as you know, 64 bit apps can have lower performance than 32 bits in some cases. So I'm curious to know what the reasons are in your case.

On 8/12/2012 6:43 PM, torhu wrote:
> On 12.08.2012 23:21, Sean Cavanaugh wrote:
>>
>> Post windows 8 launch we should start seeing mainstream games shipping
>> 32 and 64 bit binaries together in the same box. We already have moved
>> off of 32 bit in house for our editors and tools. The biggest hangup is
>> Microsoft keeps shipping 32 bit OSes, and we still have to support XP at
>> least through the end of the year. With a little luck Win8 will be the
>> last 32 bit one.
>>
>
> Can I ask, what are the reasons you want to move to 64 bits on the
> Windows platform? Is it higher memory requirements or something else?
> The game with the highest memory use I've got installed is AFAIK
> Starcraft II, still at only about one GB. And as you know, 64 bit apps
> can have lower performance than 32 bits in some cases. So I'm curious to
> know what the reasons are in your case.

  32 bit Windows games are capped at around 1.3 GB due to WinXP support.  You can get closer to 1.7 GB of address space out of your 32 bit apps when run under 64 bit windows, but thats about it, without playing with /3GB LARGEADDRESSAWARE flags etc.  Games that push 1.3 GB or more run the risk of crashing due to both address space fragmentation and running out of memory from the heap.

  In XP, you also run the risk of crashing when alt-tabing out of the game and back.  The video card's address space gets unmapped while you are away, and the app might have fragmented your nice 512 MB of contiguous while processing in the background, which causes the driver to fail to map the device back into your address space when you alt-tab crash, in a pretty much unrecoverable error.  Vista fixed this by mapping the resources to the address space when you lock the resources, instead of a huge chunk of the video card when the app had an open and valid (not-lost) device context.

  Also, having the full address space opens up the ability to store game data into memory mapped files, which can greatly simplify loading data.  Halo was designed this way for the XBOX, though for the PC version we had to modify the code to handle loading to alternate addresses with patched fixups if some random dll had taken the prefered load address at startup.  Since it was done in 32 bits each level had the same load address, but in 64 bits you could give each environment its own address range, which makes it very nice for getting a new area loaded while you are playing in the previous one (run a separate thread to touch all the new pages etc).

On 8/13/12, Sean Cavanaugh <WorksOnMyMachine@gmail.com> wrote:
> we had to modify the code

Sure enough I've found your name: http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx

I noticed you before here but never realized you worked on Halo. It's cool to see people of your caliber having interest in D! :)

On 8/12/2012 8:15 PM, Andrej Mitrovic wrote:
> On 8/13/12, Sean Cavanaugh<WorksOnMyMachine@gmail.com>  wrote:
>> we had to modify the code
>
> Sure enough I've found your name:
> http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx
>
> I noticed you before here but never realized you worked on Halo. It's
> cool to see people of your caliber having interest in D! :)

I have a theory that game development accelerates the rate at which you learn to hate C++

On 13.08.2012 02:59, Sean Cavanaugh wrote:
> On 8/12/2012 6:43 PM, torhu wrote:
>> On 12.08.2012 23:21, Sean Cavanaugh wrote:
>>>
>>> Post windows 8 launch we should start seeing mainstream games shipping
>>> 32 and 64 bit binaries together in the same box. We already have moved
>>> off of 32 bit in house for our editors and tools. The biggest hangup is
>>> Microsoft keeps shipping 32 bit OSes, and we still have to support XP at
>>> least through the end of the year. With a little luck Win8 will be the
>>> last 32 bit one.
>>>
>>
>> Can I ask, what are the reasons you want to move to 64 bits on the
>> Windows platform? Is it higher memory requirements or something else?
>> The game with the highest memory use I've got installed is AFAIK
>> Starcraft II, still at only about one GB. And as you know, 64 bit apps
>> can have lower performance than 32 bits in some cases. So I'm curious to
>> know what the reasons are in your case.
>
>     32 bit Windows games are capped at around 1.3 GB due to WinXP
> support.  You can get closer to 1.7 GB of address space out of your 32
> bit apps when run under 64 bit windows, but thats about it, without
> playing with /3GB LARGEADDRESSAWARE flags etc.  Games that push 1.3 GB
> or more run the risk of crashing due to both address space fragmentation
> and running out of memory from the heap.

Ok, so using LARGEADDRESSAWARE doesn't improve the situation on XP 64? What about on Vista 64?

On 8/12/2012 8:22 PM, torhu wrote:
>
> Ok, so using LARGEADDRESSAWARE doesn't improve the situation on XP 64?
> What about on Vista 64?

On XP64 it would help some, but the video adapter is still mapped to a huge contiguous range due to the XP driver model.  Basically you get 1 extra GB (2.3GB effective usable instead of 1.3).

Under 64 bit Vista/7 32 bit LAA apps get almost a full 4 GB to play with, and if they change their textures to default pool or use D3D10 or newer can get their texture data out of the app's address space as well, which is a huge percentage of a game's memory usage.

On Sun, 12 Aug 2012 14:12:43 -0700
Walter Bright <newshound2@digitalmars.com> wrote:

> On 8/12/2012 1:38 AM, Alex Rønne Petersen wrote:
> > One question: Will the 32-bit tool chain also be able to use the MSVC runtime and linker eventually?
> 
> It's not the current plan. Frankly, I think 32 bits is rapidly becoming irrelevant on the desktop.

Bullshit. There will always be plenty of things that don't need 64-bits and/or will only incur unnecessary bloat with 64-bit.

On 8/12/2012 9:44 PM, Nick Sabalausky wrote:
> Walter Bright <newshound2@digitalmars.com> wrote:
>> Frankly, I think 32 bits is rapidly
>> becoming irrelevant on the desktop.
>
> Bullshit. There will always be plenty of things that don't need 64-bits
> and/or will only incur unnecessary bloat with 64-bit.

You could say the same about 16 bit code. 16 bit programs are tiny relative to their 32 bit equivalents.

On Sun, 12 Aug 2012 21:54:07 -0700
Walter Bright <newshound2@digitalmars.com> wrote:

> On 8/12/2012 9:44 PM, Nick Sabalausky wrote:
> > Walter Bright <newshound2@digitalmars.com> wrote:
> >> Frankly, I think 32 bits is rapidly
> >> becoming irrelevant on the desktop.
> >
> > Bullshit. There will always be plenty of things that don't need 64-bits and/or will only incur unnecessary bloat with 64-bit.
> 
> You could say the same about 16 bit code. 16 bit programs are tiny relative to their 32 bit equivalents.
> 

Even still, it's a far cry to compare ditching 16-bit with (effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more important, and yes, 32-bit is becoming less and less important, but I still think you're very much jumping the gun here.