Max maxx: 1024 in Feature Requests

ID:116886
 
Aug 7 2011, 10:07 am
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
Please increase the maximum world maxx/maxy values from 1000 to 1024. 1000 may look nice to a human, but it's an arbitrary number to a computer, while 1024 is a nice round number.

When dealing with map-space management on a large scale, you start to curse the number 1000. Having an even power of 2 would make dividing the map into consistent chunks so much easier.
#1 Aug 9 2011, 6:24 pm
I don't understand this. Why does your computer only work with "nice round" numbers?
#2 Aug 10 2011, 11:58 pm
I think he means it'd be easier so he can do something like:
1024 -> 512 -> 256 -> 128 -> 64 -> 32 -> 16 -> 8 -> 4 -> 2 -> 1

If you try to keep dividing 100 by 2, you'll get to 25 - not exactly a good number to stop at if you want to make evenly divided pieces of something.
#3 Aug 11 2011, 8:52 am
Right, but I'm curious why this wouldn't work with non-evenly divided pieces. If you need equal splits, 512 (or 729) are the limits. If its an issue to be limited to 512 or 729, you can make an issue out of being limited to 1024.

Is the issue having a limit? or having a limit that's not a power of 2? Because you can make a 512x512 map, the issue seems to be having a limit, but that'll always be the case, except...

There was discussion elsewhere about creating ways to stitch maps together so that the edge of one map would connect to one edge of the other. This way each component map might be limited to 1000x1000, but you could make four 512x512 maps and stitch them together to make a 1024x1024 map.
#4 Aug 11 2011, 9:19 am
I'm not sure where that discussion is, but I think that would be a great route to go down. Then this problem is essentially gone, and some neat possibilities pop up.
#5 Aug 11 2011, 9:25 am
DivineTraveller wrote:
I'm not sure where that discussion is, but I think that would be a great route to go down. Then this problem is essentially gone, and some neat possibilities pop up.

I think it was here: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=2696

But I also remember the topic coming up somewhere else (probably in another feature request).
#6 Aug 11 2011, 9:30 am
My specific request doesn't cover stitching maps, just wrapping one map onto itself. I'll look around the tracker and see if I can come up with anything.
#7 Aug 14 2011, 8:52 pm
I think the request is pretty easy to understand. If you've got a project that involves halving/doubling sizes, looking at it and realizing that you're stuck at 512 but you're only 24 squares away from another power of 2 is a different matter than not wanting any limits at all.
#8 Aug 16 2011, 6:19 am
AlexandraErin wrote:
I think the request is pretty easy to understand. If you've got a project that involves halving/doubling sizes, looking at it and realizing that you're stuck at 512 but you're only 24 squares away from another power of 2 is a different matter than not wanting any limits at all.

Whatever the limit of the map size is, there will be some reason that the limit is undesirable. We can pick a size limit that lends itself to being split in half repeatedly, but that assumes that being able to repeatedly split the map in half is the only trait people look for in a map size. What about people who want to have the map size be a multiple of 100 or 1000? or people who want to repeatedly split the map into thirds or fifths?

There's still no example of such a project. If there's a limit on map size there's a reason why someone would be unhappy with that limit, but without an example I don't understand why it's better to have people unhappy about the 1024 limit than the 1000 limit.
#9 Aug 16 2011, 6:35 am
No one seems to mention that computers run on binary number systems. (e.g. powers of 2.)
So, if you want to do binary operations of some sort (the most efficient operations) it is far better to have an even power of 2. Otherwise, you're capped at the next lowest power. (512 in this case.)

This is also an advantage over dividing into different fractions (such as 3 or 5), because you can divide by bitshifting (a very efficient bitwise operation). For example, bitshifting a number to the right 1 is a shortcut to dividing by 2.
Actual division is a much slower operation, in comparison. It's slower than multiplication, so it is usually completely avoided when working with floating point numbers, if possible. (For example, dividing by 2 is the same as multiplying by 0.5.)

I think the bigger issue here, is that 1000 was chosen, because it is below 1024, (and in decimal it looks like a nice number). Going up to 1023 doesn't require more bits, but once you hit 1024, you're using another bit. (Which means the new limit would be 2047, if that was done.)
Though, thinking about it, I guess there can't be a map with size 0, so they could just bump the range to be 1-1024. (By adding 1, internally.)