For a tile-based application with a clearly defined grid. Would/could it be more efficient to use a 'cache' of indexes/tiles relative to the source, for a number of given angles?

For example, rather than performing a typical raycasting method as you might see applied in box2D or similar libraries, and then rounding the values to the grid, (or otherwise checking which tiles are hit by the ray), instead have a precalculated cache of tiles that would be hit for a given angle.

In long-range applications, or high precision angles, this would definitely be more work than its worth, or less accurate than it could be. But let's use an 8x8 chessboard as an example.

For a 90° raycast from 4, 7. You know that it will always hit the tile with one less y, until it reaches zero. This could easily be written in as
(Apologies for the shitty pseudocode)

If vectorangle (within range of 'accuracy') to 90
Hittiles = new 2d array.
For (curY = this.Y, curY>0, curY++)
Hittiles += [x,cury]

And similar code for each relevant angle. With a small grid size like 8x8, the number of relevant angles is reasonably small. And when you don't care about long range accuracy, you could round your vector angles to the (I assume faster) angles.

Is this method faster/more efficient processing-wise than your typical raycasting method? Have you used, or seen this method in use before? And if so, is there an actual name for this?

(An example for application would be a characters fov in a tile-based game, where their viewing area is limited to a 15x15 square)
Or for a more reasonable and understandable pseudocode: a cached list of positions for a given angle (using tan), adjusted in position by the source tile, and any out-of bounds tiles discarded.

I guess an optimized version of your thoughts is DDA https://en.wikipedia.org/wiki/Digital_differential_analyzer_(graphics_algorithm)

This is often implemeted with fixed point integer math (no precision problem).

There is no need to precompute anything (a cached lookup table would be much slower),

instead only the division is done once per ray, the rest is just additions.

Also related and similar is Bresenhams line drawing algorithm.

I've done this for a pathfinding algorithm that uses the minimal turn radius. When going through anything that isn't the start or end tiles, I only look at the cardinal directions (N,NW,W, etc), and have all the offsets precalculated for entering neighbor tiles at the given turn radius. Basically all the Dubin's curves to get to the nearest tiles. I'm foggy, I believe I cached dubisn for all the nearest tiles two squares away. Because it's cached, I can also take into account the width and length of the vehicle as well.

Wu's got a line drawing algorithm as well, here's a pretty picture:

As well as a circle algorithm.

Is using a cached lookup table of the possible values given x, for trigonometric functions faster than calling those functions >200k times per update?

No, trigonometric functions are slow, but not as slow as accessing memory. Probably even if the memory is in cache, and you have little control over what is in cache.

If you think those functions are too slow, profile and test if your assumption is correct.

And if so, using an approximization to trigonometric functions should be much faster than a lookup table, but only slightly faster than sin().

L. Spiro posted one few weeks back.

Also, check if you can avoid trigonometric functions completely - mostly it's possible e.g. using dot or cross products.

I agree that profiling is the way to go. That's true for every perf optimization. I suspect that caching will give you a speedup for your situation, but it's hard to say for sure.

Generally this is a non-issue.

You're talking about an 8x8 grid, so you've got a worst case of 64 ray/square intersections or 128 ray/triangle intersections depending on how the boxes are stored. That ought to take a handful of nanoseconds. Not a performance concern at all.

If you've still got too many items, generally the next improvement is to tag items that you frequently search for, such as tagging inventory-able items, tagging UI or touchable items, that sort of thing. After the spatial grid makes its first pass, you make a second pass to only pick up the items that match the tag, then perform the ray-box intersection as above.

You can handle an enormous number this type of ray/triangle intersection even on slow machines, I remember even on machines where we had to constantly remind the designers "You've got 66 MHz processor", we still could perform ray casts without much concern. If you're on a 4GHz multi-core processor this shouldn't be an actual performance issue.