Re: How big of a deal are 32-bit builds?
@Nolan: not a stupid question at all. The dll you load depends on what you're compiling for. If you compile for 64-bit then load the 64-bit dll.
In managed languages like .NET where you have an "Any CPU" option, you need to write indirection into your code whose logic is like this:
If I'm running on 32-bit then load the 32-bit dll, else load the 64-bit dllBefore TDV had this logic, I was using only the 32-bit dll of NVDA and it worked fine on my 64-bit system. Now, TDV loads the 64-bit dll on my 64-bit processor although it could very well use the 32-bit dll if I compiled my application for 32-bit only.
So, just load appropriate to the architecture you're compiling for and you'll be fine. As Ethin said NVDA doesn't come with 64-bit binaries so it doesn't care, it's your application that cares because you're doing the right thing and compiling natively for the architecture. For example, the 64-bit version of your application won't run the 32-bit NVDA dll properly.
@ogomez92: This is fine if you want to maintain compatibility with the widest range of users running legacy software. But as developers we eventually have to take responsibility and force an upgrade. We're held back by users' choice to run outdated software. It's a lot like the switch to Python 3. Many people, including myself, were resistant to Python 3 (for me up until recently.) But sooner or later you have to realize that the upgrades offer new features and improvements that the old software doesn't have.
To the point about memory consumption, yup I've heard that argument too and it does have its truth, since pointers are 8 bytes on 64-bit processors. So if you allocate an array of four pointers, you'll end up using 32 bytes on a 64-bit processor and only 16 bytes on a 32-bit processor. But this is hardly a reason for not switching to 64-bit. We have more RAM nowadays so we have a lot more room for expansion.
Plus, consider Ethin's example of MK. I imagine they do a lot of work with double-precision numbers because of graphics. Although, DirectX natively uses single-precision numbers in its APIs for efficiency and memory consumption (not sure about their graphics API though.)
On a 32-bit processor since a double is 8 bytes it has to store it into two places (called registers) since a register is only as wide as the word size of the CPU. On a 64-bit processor it can store the double number in a single register and call it a day.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
