Status of Win64 as a demo platform
category: offtopic [glöplog]
I was browsing through the Farbrausch demotool source code that was released today and saw quite a lot of 32-bit ASM code (Viruz II, for example). As the 64-bit ISA is different from the 32-bit one, it would be quite a task to port the source to the 64-bit environment.
This leads me to the following: do we need to ditch ASM in favour of C (or whatever) for new tools/demos while we slowly migrate into the 64-bit world. And, perhaps more importantly, how mature is Win64 as a demo platform?
This leads me to the following: do we need to ditch ASM in favour of C (or whatever) for new tools/demos while we slowly migrate into the 64-bit world. And, perhaps more importantly, how mature is Win64 as a demo platform?
What do you mean by "mature"?
isn't 32 mature already, 64 is like granny stuff.
Mature = developed, as in .. no major problems with drivers, devtools and support.
what's 64 bit got to offer? breaking 2G limit. some more registers to math.
the latter is cool. but the memory is not needed these days.
the latter is cool. but the memory is not needed these days.
640kb is enough for everyone, right?
To answer the question: There are no packers that I know of that generate 64-bit executables, with the intention of aiding in creating 4kb or 64kb intros. But nothing prevents anyone to make 64 bit pc-demos. It'll only fail to run on MANY PCs, since there's enough x86-only spread around the world. And in the end the demomaker pays the price, when most of the audience can't run it.
To answer the question: There are no packers that I know of that generate 64-bit executables, with the intention of aiding in creating 4kb or 64kb intros. But nothing prevents anyone to make 64 bit pc-demos. It'll only fail to run on MANY PCs, since there's enough x86-only spread around the world. And in the end the demomaker pays the price, when most of the audience can't run it.
trc_wm: for the most part porting to 64-bit isn't that difficult as long as you don't do the wrong kind of pointer arithmetic.
our more recent stuff is 64-bit clean (and works with 64 bits), which is pretty much a requirement on the editor side once you cross a certain amount of content. we're still sticking with 32 bits on the player side though because it's more compatible.
our more recent stuff is 64-bit clean (and works with 64 bits), which is pretty much a requirement on the editor side once you cross a certain amount of content. we're still sticking with 32 bits on the player side though because it's more compatible.
64 bit isn't only about a bigger address space, especially on x86. x86_64 offers double the general-purpose registers, guarantees availability of SSE2, adds some instructions, and more.
The current situation with both architectures coexisting is quite messy. We might as well switch as quickly as possible to 64 bits, it's inevitable anyway. Some people cling to the old 32 bit architecture and I can't understand that, really.
The current situation with both architectures coexisting is quite messy. We might as well switch as quickly as possible to 64 bits, it's inevitable anyway. Some people cling to the old 32 bit architecture and I can't understand that, really.
Most demos are limited by GPU and not CPU, and as such it's almost irrelevant to use 64bits code. Although if it's available one should use it.
from my experience, 64 bit code tends to be noticeably bigger, than 32 bit one. and then you have all the exe (elf, whatever) headers stuff, that is twice as large. so, for the first approximation, you lose. for 1/4/64k at least.
however, there might be some other yet undiscovered stuff that could shift this balance to the other side. like having twice as much continuous space in headers that you could take advantage of and pollute, or having more registers available for all temporaries to fit in, to name a few.
however, there might be some other yet undiscovered stuff that could shift this balance to the other side. like having twice as much continuous space in headers that you could take advantage of and pollute, or having more registers available for all temporaries to fit in, to name a few.
In terms of running demos, I've been using Windows 7 64bit for two years now. I think in that time maybe one or two prods have refused to run.
Quote:
It'll only fail to run on MANY PCs, since there's enough x86-only spread around the world.
If you need more than 2GB you'll probably also require a somewhat recent machine, and 75% of the dx10/11 compatible machines are also 64 bit. And if doing a highend demo anyway I guess the percentage is even higher.
I don't think I will be able to make win64 exe with my pretty old Visual C++ 6.0 :D
Indeed, I don't see an advantage of running in 64-bit mode just to get more memory, but I like the idea of having twice the number of registers available. It should help reduce the number of load/stores, although I'm sure the folks at Intel/AMD have clever tricks that attempt to do this already on the limited 32-bit register set.
Then there is the (unlikely?) chance that Microsoft will kill 32-bit DX support in the near future.
Then there is the (unlikely?) chance that Microsoft will kill 32-bit DX support in the near future.
Also, Visual Studio Express still doesn't do 64bit (at least out of the box) - I think that's another good reason. :)
it doesnt matter if the demos run or not, people watch them on youtubes anyway
win64 is oldschool before it becomes mature, javascript is the future ;-)
Quote:
A terrible truth. Can anyone tell me, why on earth does such a flawed launguage 1) get standardized, 2) still be the only one supported for website scripting and 3) remain flawed?javascript is the future
And I don't think that win64 will be oldschool anytime soon. That'll be the day when 4TB of RAM isn't enough...
compiling C/C++ for win64 with cmake + mingw-w64 is pretty simple...
it's not that complicated to install platform sdk and create a new platform, on vc express.
dunno about windows, but I recompiled my synth on 64 bit linux, and it came out about 10% bigger than the 32 bit one.
@xTr1m this is completely in accordance with the general trend of humanity degradation.
@MeteoriK just 10%? usually it gets a lot bigger, like 50% or so.
@MeteoriK just 10%? usually it gets a lot bigger, like 50% or so.
It might also compress better than 32-bit code. Has anyone done a x86_64 code compressor?
C++ programmers complaining about JavaScript being a "flawed language"? That's a funny one.
@w23
50% bigger? Not in my experience. Maybe 10-20%.
@w23
50% bigger? Not in my experience. Maybe 10-20%.
there's UPX, but it's way behind kkrunchy. our final will have a lniux port, but don't expect it to be 64k :-)