Take on the grinding task of fixing the code for 64bit

[uberlinuxguy]

if you build this in a 64bit environment it will in fact compile however the game will immediately fail on a malloc() issue or a segfault

Changed 11 months ago by sulucnumoh

Needs to remove all assumptions that a pointer is a dword. I tried to reassign dword the better uint32_t from stdint.h but got tons of errors where pointers are cast to void and back again. But anyway I would go in that direction because it that defines the datatype dword to the datatype the original developer thought of. But on the other hand this means removal of all parts where a pointer has been thought of the same size as a dword. This is not true anyway. Should I start with it?

Changed 6 weeks ago by slime73

priority changed from major to minor From my understanding, most of the current blocking issues on this stem from the fact that much of the data that the game loads is saved from and loaded into structs which have pointer members. Some of the pointer-members store offset information on disk, which is converted to a real pointer in the same struct when loaded into the game. Since the size of a pointer is 8 bytes rather than 4 on 64-bit systems, this means that every struct which is filled with info from the disk and has a pointer member will likely have garbled info. It is not a very big deal to only distribute 32 bit executable versions of the game, s

[AbortRetryFail]

Did some digging in to this. The first issues the game runs in to is loading ODT files from the packages. libparsec/obj_odt.cpp in at least these two functions: ODT_CreateObject() InitClassFromODT()

ODT_GenObject's pointer members are reading crap from all over the place.

[tribad]

I started the task to load the old 32 bit packages into a 64 executable. I used a special version of the ODT_GenObject where all pointers are replaced with dword. Yeah, I know it is better to have uint32_t but they cast it anyway back and forth to dword.

The pointers are going to be converted while copied. At this point I introduced the original struct definition with now 64-Bit pointers.

This works well. But now I am on a point where I have to double all ODT structure with pointer and there are a lot. Further on I would need to write some functions that will take a helper-32-bit version of a structure and returns a 64-Bit version.

If no one is working on this issue I would try to complete this part. If the original work is doing the same mechanism at some more points we would have a template how to load them as well.

[tribad]

I did it. But now it must be possible to use 64-Bit assets as well. I extended the code so far that the original source has been changed at some places. but now the function are a bad mix.

So cleanup follows.

[tribad]

I lost it.

[uberlinuxguy]

After a LOT of pain-staking work... the branch https://github.com/OpenParsec/openparsec/tree/uberlinuxguy/64bit has a semi-working client version. The game loads the objects. The game starts. You can even connect to a server.

Remote events don't seem to be firing, not sure why yet. And scrolling through the ships in the menu crashes the game.

Bug hunting time on the 64bit branch people!!!! Open issues as you see them and let's finally squash the 64-bit release!!!

[tribad]

Hi, its late in Germany, or better early. I got a message about your comment and switched on my machine to check if and what is running on my machine. So I have a 64 Bit client version running on a fedora-34 linux and looks like it connects to the servers in the starmap. Only the SpaceCraft list crashes if I try to switch back and force.

I don't know if someone is interested in the code. I may check whats wrong in the space craft list. But first I need a nap.

[uberlinuxguy]

@tribad I opened a few issues for stuff I saw right off the bat. Check out the "64-bit release" milestone and tag any new 64-bit issues there if you create any.