05-21-2014, 08:59 AM
05-21-2014, 10:24 AM
(05-21-2014, 12:24 AM)Tuco Benedicto Wrote: [ -> ]Virtually any single CPU on the market has been a 64 bit one for the last 10 years, at this point.[nitpick]Core Duo/Solo ('06) and some Atoms('08) say hi.[/nitpick]
People who keep clinging to a 32 bit OS need to move on.
05-21-2014, 10:42 AM
Don't forget the first consumer grade 64-bit CPU - the Athlon 64. 2003 says hi.
05-21-2014, 11:46 AM
B-b-but my Prescott Pentium 4 Extreme Edition! Is it not extreme enough for you guys? :'(
RIP 8fps Wind Waker. /salute
RIP 8fps Wind Waker. /salute
05-21-2014, 01:14 PM
Why keep the Android 32-bit version around if 32-bit causes such maintenance headaches? The first ARM processors that are fast enough to emulate Gamecube at full speed are going to be 64-bit anyway, and within two years probably almost all high end smart phones and tablets will be 64 bit.
05-21-2014, 01:40 PM
The problem isn't 32-bit in and of itself. The problem is 32-bit x86. 32-bit arm is so radically different that it is entirely separate from x86_32 anyway.
05-21-2014, 05:22 PM
Streeter Wrote:B-b-but my Prescott Pentium 4 Extreme Edition! Is it not extreme enough for you guys? :'(
It is. P4E has supported 64 bit since the second generation (prescott), in 2004.
05-21-2014, 05:46 PM
Here on my office PC I can see the effect mentioned. It's a Lenovo with Windows 7 32-bit. I installed alongside it Linux Mint 64 bit, because it's actually a 64bit cpu.
05-22-2014, 02:56 PM
Do they make fruit free ARMv8 CPUs? Kinda hard to drop 32bit Android without them.
05-22-2014, 03:12 PM
If you are going to drop major features, I think you should try to do it after a major release, after you have a nicely working final 32-bit version you can be proud of. I thought your timing with dropping D3D9 was terrible in that regard.
The other thing that was handled badly last time was that you immediately changed a whole lot of other things for no reason (paths, constant names, etc.) that made it needlessly difficult for other forks, or to port features.
Also, warnings would be good.
The other thing that was handled badly last time was that you immediately changed a whole lot of other things for no reason (paths, constant names, etc.) that made it needlessly difficult for other forks, or to port features.
Also, warnings would be good.