Yeah I know x32 is compatible with x64 just wondered if we could develop a x64 game. Anyway thanks for answering
|
GatewayRa wrote:
with the software i made you technically can No 64-bit support on BYOND usually means no 64-bit support. I don't think you can magically make it support it with software. |
GatewayRa wrote:
if you made a custom server there can be 64-support No. What you'll have is a waste of space because the compiler won't support 64 bit integers anyway. |
GatewayRa wrote:
ExPixel wrote: What I gathered from your post is that having a 64bit server is still pointless. |
Do you have any links for that? Seen as google isn't throwing up any information about x86 shared memory allocation strategies on WoW64.
|
Thanks for the information. Was good to get a yes/no on that shared pooling bit, as I have heard it a few times but could never find further information on it.
I was aware of the user mode 2 GB thing for x86 applications on Windows, as http://msdn.microsoft.com/en-us/library/wz223b1z.aspx will bring that up to 4 GB on x64 Windows OSes. It does nothing on x86 Windows OSes though, unless /3GB is provided to adjust the user mode/privilege mode divide people are chatting about. Linux x86 ELF just allows for the full range of 32 bit addressing, so they can manage 4 GB allocations as-is for a single process (pointers being unsigned opaque types for ELF, unlike PE). |
GatewayRa wrote:
ExPixel wrote: So in other words you don't even have anything 64-bit related on/in BYOND. Ok. |
GatewayRa wrote:
Blah blah blah blah blah... You'll hit the 65535 object limit long before you can completely populate a map of that size. So yes...it is pointless. |
GatewayRa wrote:
ExPixel wrote: If you think DM is ever going to load a map with more than 11621281 tiles AND the objects, your net dream is as good as dead. |
There's no longer a 64K object limit in compiled maps, and there hasn't been one in runtime code for a lot longer.
x64 is still not really a panacea, though. Ultimately there are scaling issues associated with any game of the kind that would take up that much memory, and with any engine. As far as loading tiles in a more efficient and compact way, I don't think that's likely. BYOND already does quite a lot to compact memory when it comes to turfs. Unlike objs and mobs, turfs are stored as a cell type, and each unique cell type contains a different appearance and area ID. Turf contents/vars (including animation info and overhanging movables) are kept in special hashtables, and kept to a minimum since most turfs as you know are simply left as their defaults. With more memory, of course, compactness isn't an issue and you can simply run wild on all of this, using direct array access and even allowing for some memory-hungry optimizations--but I don't think there would be a significant boost to performance. |
I'm actually running it on a 64-bit version of Windows right now, so it does run just fine.