Dev Tracker - Discussion

It wouldn't surprise me if they used asm stubs for arithmetic just out of habit. Most of them in the late 90s would've learned in environments where that sort of thing mattered and would've trusted the compiler to manage it for them a lot less. The compiler might've handled it for them fine but they still did it out of habit, like how a lot of C developers use macros when inline functions would be just as or more suitable (guilty) for no particular reason. Sometimes developers just do things out of habit and being used to seeing it, but they might also have done it out of a desire to avoid any weird compiler behavior. ***was wild in the late 90s.

Bit shifts are still used by allocators or anything doing aligned arithmetic on pointers. I'd define that as pretty rare but mostly because most modern C code is hot garbage 99% of the time unless it came from Microsoft, Google, or Apple where all the old crusty nerds work who complain about how some functions are slower than others because they have one added instruction.

Those theories always sound sensible, but damage calculations take place on the server where SE is far less resource constrained.

Sure, but sometimes they mix in IEEE standard float math because the server isn't actually resource constrained

That is all FFXI PC Client, which is not the original client, much less the server. FFXI original coding was done back in 2000~2002 by a team that specialized in SNES and PSX console games.

Bit shifting isn't something frequently done in C, or any other language as it's an arcane technique that's not needed much anymore. Where it is useful is when your compute is a 1.8 to 3.5Mhz CPU or if your really rocking then 33Mhz. Then every cycle, every byte of memory count and every IO operation count.

The math of bit shifting is to ensure every multiplication is done on whole integers, which are computationally much easier to handle inside Arithmetic Logic Units (ALUs).

For example lets do a simple C = A * B, where A is 4837 and B is 3.85.

Since ALU's have to operate on whole integers we have to break B into two separate values, B1 which is 3, B2 which is shifted to 85. Then multiply A by B1 and B2 separately, then shift A2 while storing the decimal place into A3. Finally all three are added together into a packed fixed decimal value. This is what the C compiler is doing for you because it's assuming you care about the decimal results as you started off with a decimal value to begin with.

Now instead lets just add two decimal places to B by shifting it to 385. We then multiply it once by A, shift again to drop the decimal places to get 18622. Much faster because we don't care about the decimal place.

Now for why it's 1024 and not 1000, because this is all being done on processors that only speak binary and in binary each number place is a value of 2 not 10.

That means a weapon skill with a fTP value of "3.85" would not be stored as a fixed decimal value 3.85, but instead as a shifted binary value of 3942, or 0000111101100110.

If a weapons base damage after WSC / fSTR was 894 (0000001101111110), and the fTP was "3.85", it would really be 001101111110 * 111101100110 = 01101011100011000110100. We then remove the ten decimal places that 1024 represents to get 0110101110001, which is 3441.

894 * 3.85 = 3441.9

That right there is what FFXI's server is doing and why every percentage seems to be /1024. They are shifting ever percentage value by ten binary digits to get rid of the decimal place and turn it into a pure integer multiplication, then shifting it back which drops those digits resulting it looking like it's "flooring", which it isn't. Because the values were never stored in any form of fixed decimal value there was never a remainder to drop.

Agner does a good job of breaking down instruction cycle time and latency, though it's only on x86 CPUs and there is no guaranteed that SE is running this game on an x86 CPU as there were many popular 64-bit RISC designs during that time.

https://www.agner.org/optimize/#manual_instr_tab

Bit shifting can be done in a single clock cycle, multiplication takes 2~4 depending if you are referencing a register or memory location. Reading or writing memory, MOV, costs 1 cycle. By using bit shifting we can shave a bunch of cycles off our computation time, at the cost of losing accuracy and having to ensure everything is an integer.

Nobody does this anymore because it's simply not needed in the age of super scalar out of order execution CPUs with large L1 instruction and data caches. It wouldn't really give much of a benefit nowadays, but back in the 90's and early 2000's these optimizations were critical to squeezing every drop of performance out of consoles.