ID:1700147
 
Keywords: game, os, x64
Can we develop a x64 game with byond??
BYOND is 32-bit, however computers running 64-bit operating systems are backwards compatible with 32-bit programs.

I'm actually running it on a 64-bit version of Windows right now, so it does run just fine.
Yeah I know x32 is compatible with x64 just wondered if we could develop a x64 game. Anyway thanks for answering
Short answer; No.

Long answer; No..
GatewayRa wrote:
with the software i made you technically can
kind of...

i dont think x64 will ever be official though

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:
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.

im talking about a custom server, like a custom dream daemon alternative
what are you talking about, for 64-bit integers? a lot of 64-bit applications don't even use "64-bit integers" outside of the size of the pointer

if anything, the numeric data type would remain float by default, if not, then a double
64-bit is particularly useful for backwards-incompatible linux distributions (not that many of them) and when the initial 4 gigabyte of space reserved for 32-bit programs is occupied

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:
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.

im talking about a custom server, like a custom dream daemon alternative

So in other words you don't even have anything 64-bit related on/in BYOND. Ok.
GatewayRa wrote:
Blah blah blah blah blah...
Want a game with more tiles than 3409x3409, ExPixel? Well, too bad. It's pointless, remember? .-. Have fun with your less than overly overly massive net dreams.

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:
GatewayRa wrote:
Blah blah blah blah blah...
Want a game with more tiles than 3409x3409, ExPixel? Well, too bad. It's pointless, remember? .-. Have fun with your less than overly overly massive net dreams.

You'll hit the 65535 object limit long before you can completely populate a map of that size. So yes...it is pointless.

That's not the limit for dynamically loaded maps.

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.