64 bit client

[XaronTN]

bump bump bump bioware when 64 bit client ?!?

 

bump bump..never:)

[RaschRune]

Are you telling me that my major lag in playing this game is because bioware is too lazy to make a 64 bit game available for download and use. I have been screaming at people because the lag is interfering with my game play. My laptop that is out of Date **** on it ran faster than this new computer does. The lag is not on my end. I can barely move, I get logged out of warzones because of the stupid gosh darn video which never lags except for when it comes back to control for me. kicked when i have not gotten through the load screen and it is worst when there is more people around. You know these problems I have been having and it could have been fixed by having a 64 bit client running.

 

how about before you start acting like idiots and change moves and crap, why not address the fact that some people use 64bit and some use a 32 bit and you make a client download that suits them both. That way I don't have to sit in game feeling depressed because I can't play when there is nothing wrong with my computer. oh and when I tick skip scene, that means i want to skip them all not be trapped in them because you think it is amusing to have warzone kicks after a minute and everyone has to put up with esc from clips and suffer lag from it and being frozen in place and not able to move.

 

When I make App's in Visual Studio, I can build for both x86 and x64. Doesn't need to code all over again.

For the client part I will guess it should be possible to build it for x64 bits platform.

[SteveTheCynic]

When I make App's in Visual Studio, I can build for both x86 and x64. Doesn't need to code all over again.

For the client part I will guess it should be possible to build it for x64 bits platform.

Maybe, maybe not, but that doesn't mean it would work correctly afterwards. How many times does the code have "4" somewhere instead of "sizeof(Blahdiblah *)" ? What about the code that uses unsigned instead of uintptr to shoehorn a pointer? etc. etc. etc.

 

No, none of those things are the right way to do it, but "that's the wrong way to do it" has never been known to stop programmers from doing this or that wrongheaded thing. I've seen so many chunks of code where it seemed like people went out of their way to the wrongestheadedest things they could find that you'd think that there's nothing left that could surprise me, and yet I trip over things (sometimes even things *I* wrote) that leave me shaking my head.

 

So no, it's not just a matter of recompiling the code with 64-bit turned on.

[MadDutchman]

When I make App's in Visual Studio, I can build for both x86 and x64. Doesn't need to code all over again.

For the client part I will guess it should be possible to build it for x64 bits platform.

 

There is a lot wrong with this thought process. Besides what Steve said (which, as always, is spot on), what you are probably doing is high level application development. Also probably in C#, not C++, which protects your *** a whole lot more.

 

Game development (and engine development in particular) often requires low level code, with lots of bitmashing and pointer shenanigans to eeck out every bit of performance. This can go very wrong very fast if even one developer at some point in time, 10 years ago, was just a bit lazy, or did something a bit bad to meet a deadline.

[RaschRune]

Thanks guys.

Let them release the client code and you guys can fix it.

That will give you a silver star.

[Tofu_Shark]

I don't see that happening short of an action by a rogue staff member. I know one of the devs at Obsidian got heat for leaving in the assets from KOTOR II that were supposed to be in the game if it wasn't rushed out for Christmas that year. Obviously it was worth it to us players, because a team of passionate gamers restored the content, but these types of actions have real world consequences.

[SteveTheCynic]

Thanks guys.

Let them release the client code and you guys can fix it.

That will give you a silver star.

If I'm going to do a big chunk of work for a company, I expect to get paid in actual money, not stars of any colour.

[Nassik]

My understanding (based on something I read previously) is that the hodgepodge Hero Englne used to run SWTOR simply can't handle a 64 bit client. The engine was pretty lousy to begin with and it's only gotten harder to maintain and work with as the game has grown and been modified.

 

To give SWTOR a proper 64-bit client would involve porting the game to an entirely new engine and then developing a 64-bit client. The cost in both time and resources to do so would be huge. And that sort of expense would never get approved by EA. SWTOR is running on something of a skeleton crew now (it's revenue used to fund other EA projects).

 

I suspect that SWTOR is on a sort of life support. And that once it's generated revenue drops below a certain pre-determined amount, the servers will be shut down permanently. I think that EA has no interest in growing and improving SWTOR. If they did, SWTOR's resources wouldn't have been cut to the point they are now.

 

And so while I would love to see SWTOR revitalized with a new engine and 64-bit client, I don't see it happening now that the game is nearly a decade old.

[lightningseven]

My understanding (based on something I read previously) is that the hodgepodge Hero Englne used to run SWTOR simply can't handle a 64 bit client. The engine was pretty lousy to begin with and it's only gotten harder to maintain and work with as the game has grown and been modified.

 

To give SWTOR a proper 64-bit client would involve porting the game to an entirely new engine and then developing a 64-bit client. The cost in both time and resources to do so would be huge. And that sort of expense would never get approved by EA. SWTOR is running on something of a skeleton crew now (it's revenue used to fund other EA projects).

 

I suspect that SWTOR is on a sort of life support. And that once it's generated revenue drops below a certain pre-determined amount, the servers will be shut down permanently. I think that EA has no interest in growing and improving SWTOR. If they did, SWTOR's resources wouldn't have been cut to the point they are now.

 

And so while I would love to see SWTOR revitalized with a new engine and 64-bit client, I don't see it happening now that the game is nearly a decade old.

 

Nassik,

 

Don't be ridiculous. NONE of that would be needed. ALL that would be needed is a simple RE-COMPILE of the client SOURCE code. That's IT!! The Hero Engine LICENSE comes with IT'S SOURCE CODE!!!

Any bugs that crawl out of that spaghetti code mess would be secondary.

Edited July 6, 2020 by lightningseven

[SteveTheCynic]

Nassik,

 

Don't be ridiculous. NONE of that would be needed. ALL that would be needed is a simple RE-COMPILE of the client SOURCE code. That's IT!! The Hero Engine LICENSE comes with IT'S SOURCE CODE!!!

Any bugs that crawl out of that spaghetti code mess would be secondary.

My professional experience as a developer over the last thirty plus years makes me doubt that it would be as simple as that, for reasons like:

* Direct assumptions about the size of variables in memory that are invalidated by the change in bitness. (e;g. pointers change from four bytes to eight).

* Indirect assumptions about the size of variables in memory (e.g. assuming that all the interesting bits of a pointer will fit into an integer of type "unsigned int", which is true on 32-bit but not on 64-bit).

* Encoding information into unused bits of pointers (on "classic" 32-bit Windows, the top bit of a pointer is always zero, but the bit in the same position in a 64-bit pointer might or might not be zero, depending on ... stuff).

* A variable containing the size of something is passed around, and goes through a "uint32_t" somewhere - an integer that is forced to be *exactly* 32 bits, and the size emerges 4GB less than expected.(1)

 

That's four simple examples of bad things that can happen if badly coded stuff (has anyone in the audience ever audited the Hero Engine's source - in the version that SWTOR took in all those years ago - for this junk?) is just blindly recompiled for a different bitness.

 

Add to that the small point that they aren't using the Hero Engine. They are using a much modified derivation of an ancient (probably from before 2010) pre-release version of the Hero Engine, to the extent that updating to the modern versions of the engine is infeasibly expensive. (Indications are that the current versions are 64-bit clean, but that doesn't help SWTOR.)

 

And no, any bitness bugs in there are far from "secondary", whatever that means. A crashy client is not "secondary" (any of the noted pointer-related bugs would cause crashed and/or random - or at least unpredictable - memory corruption faults), and those crashes might lurk in *any* part of the code, even the ones that are only rarely used.

 

So, overall, I'd rather they left that dragon to continue sleeping, thanks.

 

EDIT: added a relevant footnote.

(1) I've actually seen this one in the codebase of my current job during a 32-bit to 64-bit port.

Edited July 6, 2020 by SteveTheCynic

[DrewTheGeek]

While I'm not a professional programmer, I read way more about computing technologies than I should and I believe a 64bit client has to be specifically designed to take care of the extra memory space. Even if you converted a 32bit client into a 64bit client, the end result from this conversion, I suspect, would have little to no performance gain as it would still be designed to function in a 32bit environment. I suppose it's possible the conversion process itself could re-write some lines of code but It seems to me it's the same as taking 16ounces of liquid and pouring it into a 32ounce container. You might have a bigger container but you still only have 16ounces of liquid. So if we are talking about some kind of automated conversion process, I'm not sure it's that straight forward.

 

Almost every single gaming computer out there (if not all of em.. don't know any single core gaming systems in use) is multi-core/multi-processor. So having more than one process shouldn't cause that much of a performance hit as long as those processes are spread across cores. Each CPU core should have access to it's own memory space. Even when I eliminate my swap file, I've never used more than 16gigs of total RAM on my system. Windows, however, isn't the best at handling memory. There are programs out there like process lasso that can help with better processor scheduling and ram management.

 

I think the real truth here is that gaming has progressed far beyond what the current SWTOR engine can provide. If there was to be a renewed interest, I think an overhaul would be a better path. Do things like optimize for 64bit computing along with RTX and physics improvements. Newer technologies carry better graphics and processor scheduling along with better methods for network communication. These newer technologies are designed to be better optimized but many of those optimizations are only supported by newer hardware. This also means a re-write of base code and if they are gonna go that far, might as well bug fix.

 

This then also introduces the idea that these enhanced technologies also can require better gaming systems and many that play now may find a new client such as this, now, unplayable.

 

I think I read once that it's best to think of the SWTOR engine as a group of mismatched parts held together by duct-tape and labeled with incoherent messages that only the original author truly understands. The developers can't seem to introduce anything new without breaking something. A 64bit client is likely to tear a hole in the SWTOR universe. At that point, if we are lucky, the answer and the question will exist at the same time and the entire universe will be obliterated and replaced with something completely different and even more bizarre.

 

Or I could be wrong and all it takes is for some dev to press a button and "boom" 64bit client. *grin*

[SteveTheCynic]

While I'm not a professional programmer, I read way more about computing technologies than I should and I believe a 64bit client has to be specifically designed to take care of the extra memory space. Even if you converted a 32bit client into a 64bit client, the end result from this conversion, I suspect, would have little to no performance gain as it would still be designed to function in a 32bit environment. I suppose it's possible the conversion process itself could re-write some lines of code but It seems to me it's the same as taking 16ounces of liquid and pouring it into a 32ounce container. You might have a bigger container but you still only have 16ounces of liquid. So if we are talking about some kind of automated conversion process, I'm not sure it's that straight forward.

I have been a professional programmer ever since 1989, or slightly more than thirty years now, and no, what you wrote above is not remotely correct. I have done several 32-to-64 conversions, and if your program has been written to avoid certain jolly tricks and traps(1), then when you compile it for 64-bit instead of 32-bit, it will *naturally* use the extra memory space without you doing anything special. There's no "conversion process" - you just tell the compiler you want a 64-bit build instead of a 32-bit build, and it chews through the source code and spits out a 64-bit .EXE.

 

Of course, you might have fallen into one of those tricks and traps, and in such a case, it won't work, but that's just an exercise in debugging and (manual) repair.

 

(1) Stupid things like assuming that pointers (variables that tell where in memory other variables are) have a free bit in position 31 that you can jam an extra bit of storage into. In a 64-bit build, they don't.

Almost every single gaming computer out there (if not all of em.. don't know any single core gaming systems in use) is multi-core/multi-processor. So having more than one process shouldn't cause that much of a performance hit as long as those processes are spread across cores. Each CPU core should have access to it's own memory space.

No. All the cores access the *same* physical memory. That's why our PCs can do what's called SMP = Symmetric Multi-Processing. Individual *processes* have their own mappings of "linear" address space to physical memory, of course.

 

The performance hit from having two processes rather than two threads in one process comes from what the two processes must do to communicate with each other.

Even when I eliminate my swap file, I've never used more than 16gigs of total RAM on my system.

The page file(2) is neither here nor there in all this. And I've definitely used more than 16 GB of RAM at one time - Microsoft Flight Simulator (the new one) is quite capable of going beyond 17 GB all by itself.

 

(2) It's a page file because it's where pages of memory get stored when they aren't being used and there's a need to free up some *physical* memory for something else. A swap file is where you swap whole processes out to, and nobody's build operating systems that do that in decades. And yes, that means that when your Linux system mounts a "swap partition", it's mis-named. Historical names for things are a blessing and a curse.

Windows, however, isn't the best at handling memory. There are programs out there like process lasso that can help with better processor scheduling and ram management.

My reading of Process Lasso's feature set implies that it has exactly nothing to do with memory management. In general, Windows does a competent job of managing memory. Nothing special, but not especially bad either.

I think the real truth here is that gaming has progressed far beyond what the current SWTOR engine can provide.

"gaming" in there is a hopelessly vague term that is of essentially no importance in this discussion. That said, what matters is whether the current engine can do what's needed in its current form *for*SWTOR*. There are clearly problems with the engine, and it's clearly not capable of exploiting the capabilities of recent PC hardware trends.

If there was to be a renewed interest, I think an overhaul would be a better path. Do things like optimize for 64bit computing along with RTX and physics improvements. Newer technologies carry better graphics and processor scheduling along with better methods for network communication.

"better methods for network communication"? What are you thinking of here?

These newer technologies are designed to be better optimized but many of those optimizations are only supported by newer hardware. This also means a re-write of base code and if they are gonna go that far, might as well bug fix.

I think you have that backwards. Bug fixing takes priority, and in any event it isn't something you do as an "oh well, might as well fix some bugs" thing.

This then also introduces the idea that these enhanced technologies also can require better gaming systems and many that play now may find a new client such as this, now, unplayable.

That's definitely something to bear in mind, although there are ways to detect what the hardware is capable of and adjust what the (new) engine does as a result. (In fact, the *existing* engine does some of that, and allows us to have some input into the process as well.)

I think I read once that it's best to think of the SWTOR engine as a group of mismatched parts held together by duct-tape and labeled with incoherent messages that only the original author truly understands.

A common failing of old software, whether we're talking about games or word processors or web browsers or anything else, so it doesn't really *add* anything to the discussion.

The developers can't seem to introduce anything new without breaking something. A 64bit client is likely to tear a hole in the SWTOR universe. At that point, if we are lucky, the answer and the question will exist at the same time and the entire universe will be obliterated and replaced with something completely different and even more bizarre.

 

Or I could be wrong and all it takes is for some dev to press a button and "boom" 64bit client. *grin*

Unlikely. As I said above, I've done some 32-64 ports (and even, many years ago, some 16-32 ports, which were significantly hairier), and while in general, especially for larger chunks of code, it's not *just* a matter of flicking a switch.

 

A very simple example, taken from my job. A few years ago, we introduced a new set of hardware that had enough RAM that we could tell ===> that module (actually a loadable module for the kernel, but whatever) to allocate a 4.7GB chunk for itself. It allocated only 700MB. Why? Well, somewhere in a chain of function calls, the 64-bit block size got truncated to 32 bits (via a variable that was declared to be *specifically* 32 bits) and then expanded again, and of course in the process, the 4GB part was eliminated, leaving only 700MB (0.7GB). It was easy to fix (change the variable to be something that's automatically big enough to hold the size of memory blocks regardless of the system bitness), but the compilers couldn't fix it for us - we said that thing should be 32 bits, so the compiler did what we said.

[OlBuzzard]

I have been a professional programmer ever since 1989, or slightly more than thirty years now, and no, what you wrote above is not remotely correct. I have done several 32-to-64 conversions, and if your program has been written to avoid certain jolly tricks and traps(1), then when you compile it for 64-bit instead of 32-bit, it will *naturally* use the extra memory space without you doing anything special. There's no "conversion process" - you just tell the compiler you want a 64-bit build instead of a 32-bit build, and it chews through the source code and spits out a 64-bit .EXE.

 

Of course, you might have fallen into one of those tricks and traps, and in such a case, it won't work, but that's just an exercise in debugging and (manual) repair.

 

(1) Stupid things like assuming that pointers (variables that tell where in memory other variables are) have a free bit in position 31 that you can jam an extra bit of storage into. In a 64-bit build, they don't.

 

No. All the cores access the *same* physical memory. That's why our PCs can do what's called SMP = Symmetric Multi-Processing. Individual *processes* have their own mappings of "linear" address space to physical memory, of course.

 

The performance hit from having two processes rather than two threads in one process comes from what the two processes must do to communicate with each other.

 

The page file(2) is neither here nor there in all this. And I've definitely used more than 16 GB of RAM at one time - Microsoft Flight Simulator (the new one) is quite capable of going beyond 17 GB all by itself.

 

(2) It's a page file because it's where pages of memory get stored when they aren't being used and there's a need to free up some *physical* memory for something else. A swap file is where you swap whole processes out to, and nobody's build operating systems that do that in decades. And yes, that means that when your Linux system mounts a "swap partition", it's mis-named. Historical names for things are a blessing and a curse.

 

My reading of Process Lasso's feature set implies that it has exactly nothing to do with memory management. In general, Windows does a competent job of managing memory. Nothing special, but not especially bad either.

 

"gaming" in there is a hopelessly vague term that is of essentially no importance in this discussion. That said, what matters is whether the current engine can do what's needed in its current form *for*SWTOR*. There are clearly problems with the engine, and it's clearly not capable of exploiting the capabilities of recent PC hardware trends.

 

"better methods for network communication"? What are you thinking of here?

 

I think you have that backwards. Bug fixing takes priority, and in any event it isn't something you do as an "oh well, might as well fix some bugs" thing.

 

That's definitely something to bear in mind, although there are ways to detect what the hardware is capable of and adjust what the (new) engine does as a result. (In fact, the *existing* engine does some of that, and allows us to have some input into the process as well.)

 

A common failing of old software, whether we're talking about games or word processors or web browsers or anything else, so it doesn't really *add* anything to the discussion.

 

Unlikely. As I said above, I've done some 32-64 ports (and even, many years ago, some 16-32 ports, which were significantly hairier), and while in general, especially for larger chunks of code, it's not *just* a matter of flicking a switch.

 

A very simple example, taken from my job. A few years ago, we introduced a new set of hardware that had enough RAM that we could tell ===> that module (actually a loadable module for the kernel, but whatever) to allocate a 4.7GB chunk for itself. It allocated only 700MB. Why? Well, somewhere in a chain of function calls, the 64-bit block size got truncated to 32 bits (via a variable that was declared to be *specifically* 32 bits) and then expanded again, and of course in the process, the 4GB part was eliminated, leaving only 700MB (0.7GB). It was easy to fix (change the variable to be something that's automatically big enough to hold the size of memory blocks regardless of the system bitness), but the compilers couldn't fix it for us - we said that thing should be 32 bits, so the compiler did what we said.

 

Steve: respectfully...

 

After sifting through the technobabble ... my conclusion is this ( though somewhat overly simplified)

 

** converting to the 64 bit client is not overly simplified as some might think

** Said conversion is not impossible ... but rather more complex than some might think (thus more time consuming)

** Another variable to consider (though not mentioned) might be the bugs that are now scattered liberally throughout the game. Those would need to be cleared up as well.

 

That said: I do wish the newer client were utilized. The real question (AKA bottom line) ... would it be worth the investment at this point in time (considering the age of the game).

[Kaveat]

Steve: respectfully...

 

After sifting through the technobabble ... my conclusion is this ( though somewhat overly simplified)

 

1. converting to the 64 bit client is not overly simplified as some might think
   
2. Said conversion is not impossible ... but rather more complex than some might think (thus more time consuming)
   
3. Another variable to consider (though not mentioned) might be the bugs that are now scattered liberally throughout the game. Those would need to be cleared up as well.
   

That said: I do wish the newer client were utilized. The real question (AKA bottom line) ... would it be worth the investment at this point in time (considering the age of the game).

 

True, Also True, and here is where the laws of unintended consequences come in. "Need" is too weak of a word here. Since you prefer simplified analogizes (which may or may not retain their accuracy to the content being simplified):

 

Think of "pet" fish, most of which grow to fit their environment. In a small tank, they remain manageable, in a larger space, not only do they get relatively larger, they can suddenly become hazardous to their cohabitants.

 

In this perspective, and given the number of bugs that exist (many still persist from as far back as beta), a conversion to 64bit is starkly terrifying.

[JediQuaker]

I don't think 'converting' the current SWTOR engine to 64-bits is even a realistic option. At this point you'd need a totally new 64-bit engine and then you'd need to convert the various audio, graphic, etc assets to work with the new engine.

Also you'd need to convert and/or rewrite the overlying game code to work with the new engine.

Edited October 14, 2020 by JediQuaker

[OlBuzzard]

I don't think 'converting' the current SWTOR engine to 64-bits is even a realistic option. At this point you'd need a totally new 64-bit engine and then you'd need to convert the various audio, graphic, etc assets to work with the new engine.

Also you'd need to convert and/or rewrite the overlying game code to work with the new engine.

 

Had the conversion taken place pre- KotFE / ET release then ... yes IMO it would have been VERY doable and still warranted.

 

But those days are long gone.

[Kaveat]

Had the conversion taken place pre- KotFE / ET release then ... yes IMO it would have been VERY doable and still warranted.

 

But those days are long gone.

 

Win7 was released July 2009, with the following months showing a steady increase in the number of systems running x64. The option existed while SWTOR was still in development to do a x64 release, let alone at any other point in the following years. Obviously, they opted not to, and still maintain that stance for their own undisclosed reasons to this day.

 

All other considerations and options being equal (especially considering that EA certainly has the resources to do it at any point, if they wanted to), the only driving reason not to take this step that makes any sense is that they know (or at least have tangible suspicions) that there will be stability issues on x64 that exceed their ability to even marginally support the platform.

 

Now, all that said, the only potential saving grace (which in itself will be a double edged blade) that may force the issue is the end of MS 32bit OS line, and the (eventual) end of 32bit support (note: active support, not functionality) on existing 64bit platforms. Might take another couple years, but it will be coming. The real downer is what will happen if they fail to produce a sustainable 64bit system by that point... and even that is making other assumptions on the favorable side between now and then, but time will tell.

[DarkTergon]

Win7 was released July 2009, with the following months showing a steady increase in the number of systems running x64. The option existed while SWTOR was still in development to do a x64 release, let alone at any other point in the following years. Obviously, they opted not to, and still maintain that stance for their own undisclosed reasons to this day.

 

All other considerations and options being equal (especially considering that EA certainly has the resources to do it at any point, if they wanted to), the only driving reason not to take this step that makes any sense is that they know (or at least have tangible suspicions) that there will be stability issues on x64 that exceed their ability to even marginally support the platform.

 

Now, all that said, the only potential saving grace (which in itself will be a double edged blade) that may force the issue is the end of MS 32bit OS line, and the (eventual) end of 32bit support (note: active support, not functionality) on existing 64bit platforms. Might take another couple years, but it will be coming. The real downer is what will happen if they fail to produce a sustainable 64bit system by that point... and even that is making other assumptions on the favorable side between now and then, but time will tell.

 

you have to remember at the time they bought an alpha version of the hero engine (so people have said here)

They probably had theirs hands full getting it sorted, plus, in the end, they were pressured to release it quickly.

We don't know what sort of pressure the studio was under, they might not have had the time to convert it. In the last few years, they've lost most of their staff, so chances are, it'll be a no.

BUT if the contract gets renewed for another 10 years, they might then decide or get a kick in the *** to actually do something better.

[Kaveat]

you have to remember at the time they bought an alpha version of the hero engine

 

With most things, I would not consider something that started somewhen in the late 90's to still being in 'alpha' by 2008-2011.

 

That said, if this time scale is possible, then maybe it's finally reaching beta status?

Edited October 15, 2020 by Kaveat

[DarkTergon]

With most things, I would not consider something that started somewhen in the late 90's to still being in 'alpha' by 2008-2011.

 

That said, if this time scale is possible, then maybe it's finally reaching beta status?

 

Maybe it was that particular version of the hero engine that was an alpha...lol. I've no idea. It's been mentioned here quite a bit...lol

[OlBuzzard]

Win7 was released July 2009, with the following months showing a steady increase in the number of systems running x64. The option existed while SWTOR was still in development to do a x64 release, let alone at any other point in the following years. Obviously, they opted not to, and still maintain that stance for their own undisclosed reasons to this day.

 

All other considerations and options being equal (especially considering that EA certainly has the resources to do it at any point, if they wanted to), the only driving reason not to take this step that makes any sense is that they know (or at least have tangible suspicions) that there will be stability issues on x64 that exceed their ability to even marginally support the platform.

 

Now, all that said, the only potential saving grace (which in itself will be a double edged blade) that may force the issue is the end of MS 32bit OS line, and the (eventual) end of 32bit support (note: active support, not functionality) on existing 64bit platforms. Might take another couple years, but it will be coming. The real downer is what will happen if they fail to produce a sustainable 64bit system by that point... and even that is making other assumptions on the favorable side between now and then, but time will tell.

 

2 to 3 years ??? SWTOR life span ??? 10th anniversary ??

 

There are so many "X" quantity variables in that one line ... And never believed in Ouija boards !

 

The next few months should be really interesting.

[lightningseven]

AS OF THIS POINT RIGHT NOW, SWTOR (if it continues to remain 32-bit ONLY) can only survive for 18 more years before we have to GIVE UP THE WHOLE GAME ALTOGETHER ... or at least, the online official-server version.

 

Why?

 

I THINK because of the approaching Y2K38 problem when all 32-bit computers can no longer process date and time functions reliably. (see: https://en.wikipedia.org/wiki/Year_2038_problem )

 

Now i know that is mainly a reference to hardware issues .... BUT WOULD NOT THE SWTOR CODE (which is 32-bit ONLY) be also HAMSTRUNG by this Y2K38 issue since the CODE ITSELF IS ONLY 32-bit??

[lusskat]

Technology and communications in the last four decades has taken on an exponential growth and era of complete changes, to the point some technology in the majority of the world has become absolutely obsolete; cannot function.

 

You're speaking of things near 2 decades in the future. Bits and bytes may be considered by that time as vintage and obsolete as the telegraph or phonograph. It may well function, to a point, and yet now we have satellite communications, digital media. These are devices that still were once cutting edge, and astounded the world, but are now mostly just tools for enthusiasts. IBM and Apple grew out of a race similar to those technologies and won where many others fell through the cracks. Tesla succumbed to Edison.

 

The era we are in, who's to say digital electronics aren't being phased out as quickly as analogue got it's, "Thanks for coming, we've appreciated what you've done, you're no longer needed here". Big moments. Predicting a future that seems so far away(in this era of changes) atm to me just seems rediculous. Your(and mine) 64 bit machines may be as useful as a fun antique to show your kids by that time, or as useless as an overgrown paperweight. Being generous; more likely landfill.

 

NOW... can we drop the rediculousness and focus back on NOW.

[SteveTheCynic]

Now i know that is mainly a reference to hardware issues .... BUT WOULD NOT THE SWTOR CODE (which is 32-bit ONLY) be also HAMSTRUNG by this Y2K38 issue since the CODE ITSELF IS ONLY 32-bit??

Maybe. It depends on how it obtains the date and time. If it asks Windows using functions in the C or C++ standard libraries, it will have problems with Y2038.

 

If it asks Windows using direct calls to the Windows API, then it won't have problems until ... er ... a long time in the future. The "Windows NT epoch" is 1 January 1601 (Gregorian calendar), and Windows system time is expressed as a 64-bit number of ten-millionths of a second since then, so its equivalent of the Y2038 won't expire for another 58000 years.

 

EDIT: and the Y2038 problem is a *software* problem rather than a hardware problem.

Edited October 19, 2020 by SteveTheCynic

[DarkTergon]

won't expire for another 58000 years.

 

They might have eventually updated the game by then