SinusAlpha

A port may also involve additional changes such as different libraries, compiler settings, dependency versions, or modifications to the code. Those changes can have a much larger effect on performance than the 32 bit to 64 bit on x86_64 architecture switch itself.

Hello, in my opinion are minimal performance differences possible but i think they are not particularly significant. Only compilation as a 64 bit application does not automatically mean that the client has been cleanly ported to 64 bit. I think that porting from 32 bit to 64 bit involves more than just linking different libs and recompiling, a proper port also requies checking the code for 32 bit assumptions and adjusting it accordingly.

Yes, technically you can port everything and its possible but in my opinion it offers no advantage. However it is very interesting for modernization purposes. The source code was written for a 32 bit architecture and this affects both the client and server source code. Porting from 32 bit to 64 bit is easier than the other way around but some ABI dependent types still need attention. If you dont want to change anything in the source code then you should compile it on 32bit.

Hello, im a oldschool guy too

Very interesting project, i prefer FreeBSD and Jails but i like it.

I made a few changes to the source code to make it architecture independent, the only issues left are with big endian architectures like PowerPC.

looks great

The server never requires more than 4 GB of RAM and the source code was originally written for an i386 machine, and the old makefiles do contain -m32 flags for a reason. For example, long variables are assumed to be 4 bytes on an i386/i686 machine, but when compiled on a 64 bit machine, a long variable has 8 bytes. If you leave the code unchanged and have a bit of common sense, then you should definitely compile it with 32-bit flags. If you want to compile it to 64-bit, then you should definitely adjust the source code. For example im porting the source files to arm64, more precisely to a RockPro64. The original source code isn't intended for this, so it needs to be adapted and thats why i think that simply doing something without understanding the computer architecture doesn't seem sensible to me.

ARM64 bug in src/game/main.cpp, line 449: char ch; must be changed to: int ch; getopt() in line 457 returns an int and uses -1 to indicate completion. On ARM64, char is unsigned, converting -1 to 255 and causing an infinite loop at 100% CPU. Tested successfully on FreeBSD 15.1/aarch64 on RockPro64.

Is SSE2 even enabled? bool CPU_HAS_SSE2 = false; bool GRAPHICS_CAPS_CAN_NOT_DRAW_LINE = false; bool GRAPHICS_CAPS_CAN_NOT_DRAW_SHADOW = false; bool GRAPHICS_CAPS_HALF_SIZE_IMAGE = false; bool GRAPHICS_CAPS_CAN_NOT_TEXTURE_ADDRESS_BORDER = false; bool GRAPHICS_CAPS_SOFTWARE_TILING = false; I have a problem where the .EXE doesn't respond to configuration changes. For example, music is on even though it's off.

It seems that you have entered an incorrect password for the user in Navicat. it's difficult to help you if i don't have any further information. have you self installed mysql or are you using any ready-made server files in a virtual machine? Normally you configure mysql after installation with mysql_secure_installation (where mysql_secure_installation is not required) and then a user is created. You do this by logging in via mysql -u root -p and assigning a user, for example: CREATE USER 'user'@'localhost' IDENTIFIED BY 'password'; GRANT ALL PRIVILEGES ON *.* TO 'user'@'localhost' WITH GRANT OPTION; then: FLUSH PRIVILEGES; exit; This is just an example! As I said, I don't know exactly where the error lies. I suspect that you have chosen the wrong user and password for Navicat and therefore cannot log in.

mysql version ?

item_attr and item_attr_rare is read only on this vm and i cant fix them

Have you ever tried to compile server files on a 64bit machine? You can do that, but you need a 32bit jail. The server files cannot be compiled on a 64bit machine, so the maximum is 4GB per channel. The problem exists because 32-bit libraries are used that are not compatible with 64-bit.

Even if you have a 64bit machine. The server files are compiled on and for 32bit. So means: Theoretically max 4GB RAM for channel I can't specify any other parameters.