ID:158668
 Jul 21 2009, 11:09 am
|
|
Everyone has one of those procs that will return a straight line of turfs in list format from point A to point B, right? I want one of those that will return a line of turfs that is multiple tiles wide, preferably being done in a more efficient fashion than just using the original get-line function on all tiles around the original tile. Anyone have anything like that?
| |
|
Jul 21 2009, 11:15 am
|
|
Kaioken
 |
Couldn't you do this (or a 'regular' get_line() for that matter) with just a call to the block() proc?
|
I'd suggest just getting the getline() function from AbyssDragon's BasicMath library and modifying it to get the tiles in proximity. I know that's exactly what you said you didn't want, but to be honest it's probably the most efficient way of doing it.
| |
Probably the easiest thing to do is determine which cardinal direction is the most perpendicular to the line (1,1 to 4,3 would have NORTH/SOUTH the most perpendicular) and add some number of tiles in those directions, using get_step(). You could apply this to any other algorithm after you have the line, by looping through it afterward to add the extra turfs.
Note that this won't produce perfect lines, but it should be fast and good enough. | |
My goal is to create a rough way of determining what kind of sound environment to play back to the player.
Suppose You have the player at A and the origin of the sound at B. The sound wants to know how it should be played, so it creates lines from point A to B to see if there is anything blocking sound. If there is nothing there, then the sound must be either Direct or Exclusion. If there is something blocking, then it must be either Obstruction or Occlusion. So either way it has two options, so to determine which of the two options is correct, it would create, parallel to the direct line, two more lines on each side to see if those lines are obstructed at all. If the direct path is clear and the parallel paths are clear, then the sound type is most likely Direct. If the direct path is clear and the parallel paths are obstructed, then the sound is most likely Exclusion. If the direct path is obstructed and the parallel paths are clear, then the sound is most likely Obstruction, while if the parallel paths are also obstructed, then the sound is Occlusion. So in that sense, what you suggested should work fine, I just don't have any good way to determine whether to use NORTH/SOUTH or EAST/WEST. | |
It's simply an approximation of perpendicular. So, if |dx| > |dy|, NORTH/SOUTH, otherwise, EAST/WEST.
As for determining the sound environment... this is something you're REALLY going to want to pre-calculate. But that is a HUGE can of worms. Start with Binary Space Partitions (BSPs) and work from there. | |
Well, I suppose we could go with something a little simpler, assuming the developer has divided each "room" into a separate area. In that case, you could draw a direct line from the player to the sound origin and check:
1) How many different areas there are. 2) Whether there is a clear path or not. If there is one or more area changes between the two points, then if the path between is clear it will be Exclusion, otherwise it will be Occlusion - the levels of which depend on the number of area changes. If there are no area changes and the path is clear, it will be Direct, but if the path is not clear it will be Obstruction. Thing is, how well this would work totally depends on how well the mapper sets up the areas with sound in mind, and not all games are going to want to use areas this way making it somewhat of an unfriendly library. | |
My suggestion was that you would have to precalculate all the areas... but you'd use your own data structure instead of areas, ideally. A weighted network would likely be ideal... where each node is a room and the weights describe how much sound gets through.
From there, you can try to figure out how to set up sound... I believe there are a number of books written on this topic, but I can't find any purely online source. It's not a trivial problem. | |