[BAILOPAN]

In the style of my late strategy of rapid-fire-news-posts, here's an important update to the AMD64 folks.

PM OnoTo has scratched out a plan-of-concept to making an End-All Everything-Works AMD64 port. However, the compiler version that's anywhere near 64bit safe, 2.5.1, is still heavily broken (our crash test is compiling WC3).

This means we have two options: Wait for Thiadmer of ITB Compuphase to release 2.6.0, or backport the necessary changes into the 2.1.0 compiler.

2.5.x has a number of improvements that we'd all like, however, it doesn't seem useable at this point. We've decided to wait for 2.6.0. If 2.6.0 doesn't work, we'll backport everything into 2.1.0 (which will probably be more work).

The end result is, we'll be checking Small's Site regularly for updates, but we're not going to waste time working what we don't have. Consider the 64bit port a development fork for now - it is something we're branching off and will come back to, hopefully by 1.0.

The technical details:
What PM and I are currently discussing has been an ongoing issue for months now, and we eventually decided we would need to make some low level changes to the AMX file structure. The first issue is the cell size difference, on AMD64 a cell would be 8 bytes instead of 4, because of the size of a void pointer. Since a void pointer obviously can't be casted, reading a 32bit plugin on a 64bit machine results in assertion failures and garbage pointer to functions.

There are a number of solutions to this, one is simply releasing 64bit plugins and 32bit plugins. Support nightmare, no thanks.
The second solution is to interactively cast the cells to the appropriate size as the 32bit plugin is being read. This is much cleaner, except for the fact that it makes differentiating between floats/doubles and normal cells impossible. This is where we have to also modify the file format to internally tag data types - which is an area we're still debating about.

PM, feel free to correct anything I've said here. Hope this clears up the issue.

[Girthesniper]

We really don't need it bailo. Its just an optimozation. Don't stress about it.

[Mannekino]

Well, you're not speaking for all of us. I am anxiously waiting for the AMD64 release for Win32. I am running my Counter-Strike server on a Windows 2003 box with dual Opteron processors. Yes I am aware of the fact that Microsoft hasn't released their 64-bit version yet but I hope it they will in the near future. So far all I can do is wait on 64-bit enabled game server software.

But keep up the good work BAILOPAN, I can't wait untill you release the Meta Mod X and AMX Mod X 64-bit versions .

[QwertyAccess]

i might get a 64 bit proccessor and check it out someday.

[CheesyPeteza]

Big improvement or not, it'd be a nice "selling feature" of AMXModX. Being the first Admin Mod to become 64 bit compatible sounds good.

[kingpin]

would love to work with a 64 bit version, but whats important is to improve/fix what we have now so whatever you guys decide is fine whether to tackle this now or in 1.0. keep up the good work.

[PM]

ok, it seems like i managed to fix the new compiler. It compiled Warcraft3 to a .amx file. We will make some tests on whether it works correctly. So a 64 bit port seems realistic again

[ThantiK]

So what exactly do we gain by making a 64bit version?

Does it make any TRUE difference? -- AMD64's natively support 32 bit processing, and since it seems you guys are going to have to code a lot just to get 64 bit working, wouldn't that defeat the purpose?

I've got an amd64 machine thats running a server for a couple of people right now, and I truthfully, could care less. It runs. It runs well. It runs with VERY LITTLE CPU POWER...so why would we need 64 bits anyhow? -- I mean seriously. a HL server is basically just memory consumption and very little cpu usage. 64 bit isn't going to make much of a difference, and if it slows down 32 bit development, then what is the point?

Yea, I'm glad for 64 bit processors coming about, but I'm starting not to see the logic behind it. I can understand developing a 64 bit operating system, because the OS is a BIG PROGRAM, and does a lot of things that 64 bit processes could help. But, were talking about throwing a 64bit addon, to a 32bit process...it will be a complete nightmare.

HLDS is a 32bit process, why are we even trying to make a 64bit addon. Its something that would help a VERY small bit in terms of processing power, speed, etc...but would create SO MANY PROBLEMS as we can see by your post, that its not worth it!

*edit*
p.s. Figures PM would get it working as I'm typing this freakin rant.

[Uresu]

hlds is anow a 64 bit process and beleive me, there are LOADS of us waiting for the amx 64 bit release

[ThantiK]

Sorry, hlds is a 32 bit process...always has been.