Why is view() range limited to 40?

ID:1516982
 
Mar 13 2014, 4:40 am
So, why?

Any chance of getting this uncapped?

Or, does anyone know a library for a custom view proc that goes further than 40?
Mar 13 2014, 4:43 am
Because anything above that causes excess CPU and bandwidth usage, at a certain point procs like view() start losing their efficiency at an exponential rate.
Mar 13 2014, 4:47 am
How does the internal workings of view() work? Does it loop everything in the world and return a list of things within the range?
Mar 13 2014, 4:53 am (Edited on Mar 13 2014, 5:15 am)
A view range of 40 is 81 tiles in radius. That's effectively 6561 tiles square. Not only does view() simply grab those tiles, it also happens to do view calculations from the center, accounting for opacity. Going larger is not only going to be incredibly unreasonable, it's probably going to bog down your world.

I can't think of a single situation where a view() size of greater than 10 is even reasonable to use for regular AI, or attacks. For boss monsters, or global events, though, it's probably better to contain them in a specific area, and then use a special handler to determine what targets are nearby.

In addition, you should be aware that client.view is limited to a total area of approximately 5000 tiles, which is an area of approximately 70x70 on each side.

If you need a variable size for a viewport that can go above this limit, check this out:

//some defines:

#define TILE_WIDTH 32
#define TILE_HEIGHT 32

#define ceil(x) ((x) == round((x)) ? round((x)) : round((x)) + 1)

#define floor(x) (round((x)))



var/vpx = 1920 //or whatever you need your area to be.
var/vpy = 1080

var/tx = ceil(1920 / TILE_WIDTH)
var/ty = ceil(1080 / TILE_HEIGHT)

//ensure that we don't surpass the limit
if(tx * ty > 5000)
    var/ratio = sqrt(5000 / (tx * ty))
    tx = floor(vpx * ratio / TILE_WIDTH)
    ty = floor(vpy * ratio / TILE_HEIGHT)

vpx = tx * TILE_WIDTH
vpy = ty * TILE_HEIGHT


The above function will allow you to dynamically adjust your map viewport to any size you want, and calculate the total area that will fit inside of the map. It roughly preserves the ratio of the map element, while matching it to your tile size.

You can decrease the total area cap as well to allow only a specific tile area. For instance, let's say I want to have a 320x240 viewport (roughly). That's 20x15 with a 16x16 tile size. But if the user is playing on a larger resolution, we want to increase the scale to roughly match that:

We change our upper bound area to 300 tiles, so we swap that in for 5000 in the above snippet.

Then... We do some math after we've constrained it to fill as much of that area as possible:

var/vpx = 1920 //or whatever you need your area to be.
var/vpy = 1080

var/tx = ceil(1920 / TILE_WIDTH)
var/ty = ceil(1080 / TILE_HEIGHT)

//ensure that we don't surpass the limit
if(tx * ty > 300)
    var/ratio = sqrt(300 / (tx * ty))
    tx = floor(vpx * ratio / TILE_WIDTH)
    ty = floor(vpy * ratio / TILE_HEIGHT)

var/opx = vpx
var/opy = vpy

vpx = tx * TILE_WIDTH
vpy = ty * TILE_HEIGHT

var/scale = min(floor(opx / vpx),floor(opy/vpy))


Notice that we choose the smallest value of the ratio of the final area's size by the original pixel size available? This allows us to calculate a smooth pixel scale for the map.

So if I were playing with 1920x1080, my final viewport size would look something like this:

120 x 68 = 8160
v = 368 x 207
t = 23x12
s = 5

Meaning we have a 23x12 viewport with a 5x pixel scale. This means our map element's inner dimensions will now be: 1840 x 960, leaving a letterbox area of 80x120.
Mar 13 2014, 9:37 am
In response to Ter13
Also, if you have a view size of 40 with icon sizes of 32x32, that's basically 2592x2592 pixels.

Unless you have two monitors, or pay like $1000+ for an insanely expensive monitor, that is way bigger than any monitor can display that anyone here has.
Mar 13 2014, 9:39 am
In response to The Magic Man
Downscaling, my friend.
Mar 13 2014, 9:40 am
With view(), remember you're already working with an O(N^2) algorithm. I did some massive improvements on it a while back to improve its performance because it used to be O(N^3) (no really!), but larger view sizes are going to hinder you for sure. Use of luminosity still has some minor O(N^3) effects, I think, but since that's capped I don't consider that a huge problem.

All things being equal, I'd very much prefer it if the view() system were replaced with some simpler LOS calculations like shadowcasting, which can be very fast--especially if you're just doing a spot check on whether A sees B. That'd be hard to mix in with luminosity though, and I can see a lot of downsides to this approach.

Bottom line is that if you want to check line of sight on something that far away, you're way better off rolling your own. (Bear in mind since it's soft-coded, you do have to deal with the potential that it'll be slow anyway.) As a general rule, I don't see why any game would need LOS calculations that far out.
Mar 13 2014, 9:41 am
@ TMM:

I usually work at 16x16, so the concerns crossed my mind. A 1920x1080 resolution equates to roughly 120x67.5 (ceil 68 for full coverage at inset), so I wound up thinking about how I'd solve the problem, and then applied the above properties of rectangles to find the maximal axis span of a given ratio with a set area.

But yeah, you have a fair point about the size of the viewport. It's insane that anybody would NEED something that large, unless you start talking about some very advanced client-side applications, like the ones I build.

I also happen to have 3 26" widescreen monitors... So... There's that...