# Isaac s fast beamcasting LOS

Jump to navigation
Jump to search

See also Isaac Kuo's java applet demo of this algorithm.

Isaac's fast beamcasting LOS - Isaac Kuo [mechdan@yahoo.com] Here I present pseudocode for a fast LOS calculator. This pseudocode calculates visibility in the first quadrant by casting beams at 32 different slopes. Despite the low number of casting angles, the fact that wide beams are thrown instead of thin lines ensures adequate coverage. Conceptually, the beam's source is the diagonal from (-.5,.5) to (.5,-.5). Each step of throwing the beam increments its position from the current diagonal line to the next. It is sufficient to check against collisions with squares along the diagonals because that is where their greatest extents will always be present. This pseudocode uses a skewed coordinate system to assist the calculations. The transformed coordinate system is: x=u-v/32 u=x+y y=v/32 v=y*32 ...initialize trans[x][y] to be the transparency map... ...initialize visible[x][y] to false... // Build a circular border of opaque blocks so later // there won\'t be any need for extra code to check // against maximum range. // // Note that there are obvious optimizations to make // this step MUCH faster. for(x=0;x<=MAXRANGE;x++) for(y=0;y<=MAXRANGE;y++) if (distance(x,y)>=MAXRANGE) trans[x][y]=false; // Set 0,0 to be visible even if the player is // standing on something opaque visible[0][0]=true; // Check the orthogonal directions for(x=1; trans[x][0]; x++) visible[x][0]=true; for(y=1; trans[0][y]; y++) visible[0][y]=true; // Now loop on the diagonal directions for(slope=1; slope<=31; slope++) { // initialize the v coordinate and set the beam size // to maximum--mini and maxi store the beam's current // top and bottom positions. // As long as mini<maxi, the beam has some width. // When mini=maxi, the beam is a thin line. // When mini>maxi, the beam has been blocked. v=slope; mini=0; maxi=31; for(u=1; mini<=maxi; u++) { //loop on the u coordinate y=v>>5; x=u-y; //Do the transform cor=32 - (v&31); //calculate the position of block corner within beam if(mini<cor) { //beam is low enough to hit (x,y) block visible[x][y]=true; if(!trans[x][y]) mini=cor; //beam was partially blocked } if(maxi<cor) { //beam is high enough to hit (x-1,y+1) block visible[x-1][y+1]=true; if(!trans[x-1][y+1]) maxi=cor; //beam was partially blocked } v+=slope; //increment the beam's v coordinate } } The general picture of what's happening is: | | | | \32 | | \ | | \maxi | \| | ------\cor------+---- |\ | | \ | | \ | | \mini | | \ | Y | \0 | ^ | | | | | | |X,Y BLOCK| +-->X ------+---------+ The position of the beam is between the points designated "mini" and "maxi". The parts below "mini" and above "maxi" have already been obscured by shadow. If "cor" is between them, then this beam hits two blocks (the one at X,Y and the one at X-1,Y+1). Otherwise, only one of those blocks will be hit. This algorithm should be pretty fast as it is--certainly faster than the typical raycasting algorithm because this one throws essentially a bundle of rays at a time for roughly the same computational cost of two of the traditional rays. It's also more elegant than traditional raycasting. No additional hacks are required to fill in wall gaps or beautify corners. If an exact LOS path is required (i.e. for displaying ranged weapon animation and/or determining the area of effect of a linear attack spell), then a beam which hits the target can be narrowed down the ray at either (mini+cor)/2 or (maxi+cor)/2, depending on whether the target was in the (X,Y) or the (X-1,Y+1) block. This ray's path will look something like: @###### ***.... ..***.. ....**T This can lead to near diagonal shots intersecting almost twice as many blocks as you'd expect. As such, I would only consider the blocks where the ray segment covers at least 1/2 in either the X or Y dimension. This will reduce the ray's path to something like: @###### .**.... ...**.. .....*T -- _____ Isaac Kuo mechdan@yahoo.com __|_>o<_|__ /___________\ The most important way to defend one's nation \=\>-----</=/ is to make it worth defending. - a true patriot

Variant algorithm:

Just to let you know--I'm pondering a new approach to my beamcasting LOS concept which visits each block exactly once. My original algorithm visits blocks multiple times, which is efficient with my assumed data structures--a simple fast arrays for visibility and opaqueness. However, a lot of people like to use a more complex or object oriented data structure, where each access involves a lot of overhead. My basic idea is to cast all slopes in a quadrant at once, keeping a small fast array of mini[slope] and maxi[slope]. In the original algorithm, the slope is the outer loop, and the radius is the inner loop. In my new algorithm, the radius is the outer loop while the slope is the inner loop. Roughly: //initialize all mini and maxi mini[1...slopes-1] = 1 maxi[1...slopes-1] = slopes-1 for u = 1 to maxradius //loop on radius //initialize at slope=0 x = u+ox y = 0+oy cor = 0 opaqueA = opaque(x,y) opaqueB = opaque(x-1,y+1) for slope = 1 to slopes-1 //loop on slope cor += u //increment cor if cor>=slopes //check for overflow into next block cor -= slopes x-- y++ opaqueA = opaqueB opaqueB = opaque(x-1,y+1) //Now do the visibility stuff if maxi[slope]>cor visible[x,y] = true if opaqueA maxi[slope]=cor if mini[slope]<cor visible[x-1,y+1] = true if opaqueB mini[slope]=cor next slope next u Note that I've swapped the roles of "mini" and "maxi", and replaced "cor" with num_slopes-cor. The above is a rough idea, but it has some problems. For one thing, it always visits every block within the maximum radius, even if there are nearby blocking walls. This can be a major performance hit if much of the terrain is made up of twisting narrow corridors. Isaac Kuo