New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Plasma 64-bit compliant #34

Open
dpogue opened this Issue May 1, 2011 · 7 comments

Comments

Projects
None yet
4 participants
@dpogue
Member

dpogue commented May 1, 2011

This likely requires changing almost every function to verify that it will work properly when compiled in 64-bit.

@Hoikas

This comment has been minimized.

Show comment
Hide comment
@Hoikas

Hoikas May 2, 2011

Member

Lots of 32-bit assumptions in the max plugin are going to make this painful for me <.<

Member

Hoikas commented May 2, 2011

Lots of 32-bit assumptions in the max plugin are going to make this painful for me <.<

@branan

This comment has been minimized.

Show comment
Hide comment
@branan

branan May 2, 2011

Member

This is a must both for future plugin compatibility and for making porting easier - Linux especially much prefers the native architecture.

Member

branan commented May 2, 2011

This is a must both for future plugin compatibility and for making porting easier - Linux especially much prefers the native architecture.

@dpogue

This comment has been minimized.

Show comment
Hide comment
@dpogue

dpogue Oct 29, 2011

Member

The first steps are being taken here as we're working on Linux support. We've already resolved the biggest issue (use of long for 32-bit integers).

Member

dpogue commented Oct 29, 2011

The first steps are being taken here as we're working on Linux support. We've already resolved the biggest issue (use of long for 32-bit integers).

@Deledrius

This comment has been minimized.

Show comment
Hide comment
@Deledrius

Deledrius Feb 3, 2013

Member

What's the break down of what qualifies for 64-bit compliant as it pertains to this codebase?

Member

Deledrius commented Feb 3, 2013

What's the break down of what qualifies for 64-bit compliant as it pertains to this codebase?

@Hoikas

This comment has been minimized.

Show comment
Hide comment
@Hoikas

Hoikas Feb 3, 2013

Member

The issue that sticks out the most to me is that Cyan used 32-bit vector indices everywhere. That's not too terrible but sill not good. @zrax mentioned the other day that parts of the network code will likely explode in 64-bit.

Member

Hoikas commented Feb 3, 2013

The issue that sticks out the most to me is that Cyan used 32-bit vector indices everywhere. That's not too terrible but sill not good. @zrax mentioned the other day that parts of the network code will likely explode in 64-bit.

@branan

This comment has been minimized.

Show comment
Hide comment
@branan

branan Feb 3, 2013

Member

32-bit vector indices won't break, they'll just cause lots of warnings. My biggest concern would be anything that assumes longs are 32-bit (always true on windows64, but not on unix 64), or anything that stores a pointer in an integer.

This issue is "complete" when we can build a 64-bit client without errors, and have it run without crashing.

Member

branan commented Feb 3, 2013

32-bit vector indices won't break, they'll just cause lots of warnings. My biggest concern would be anything that assumes longs are 32-bit (always true on windows64, but not on unix 64), or anything that stores a pointer in an integer.

This issue is "complete" when we can build a 64-bit client without errors, and have it run without crashing.

@Deledrius

This comment has been minimized.

Show comment
Hide comment
@Deledrius

Deledrius Oct 22, 2017

Member

The lack of a 64-bit PhysX is also going to bite us here. With just a few tweaks to update Windows API calls I can get the entire solution (excluding the Max plugin) building for 64-bit except plPhysX. Until we replace that (#4), we can't even build a client.

Member

Deledrius commented Oct 22, 2017

The lack of a 64-bit PhysX is also going to bite us here. With just a few tweaks to update Windows API calls I can get the entire solution (excluding the Max plugin) building for 64-bit except plPhysX. Until we replace that (#4), we can't even build a client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment