What is a look up table and what can I use it for?

I'm interested in learning what a lookup table can be used for and after some of the codez that show a basic lookup table in action.

Am I right in saying that i can be used to manipulate the screen in some way?

How does it work?

A lookup table is basically a table of values that are acquired by some algorithm or other. For example, a Sin lookup table would be made by running through 0 to 359 and assigning those values to their appropriate indices in the lookup table, e.g.:

Local SinTable#[359]
For i = 0 To 359
     SinTabe[i] = Sin(i)
Next

In using these you can signifigantly speed up mathematical operations because you do not need to perform intensive CPU algorithms more than once at the beginning of the application's startup (assuming you want to generate the tables there and not during runtime).

In a sense you could use them to manipulate the screen by containing pointers to various positions on the screen in a lookup table, letting you get at the positions without scanning for the pointers. But then that's not a very good idea, since the pointers could change. But otherwise lookup tables have nothing to do with manipulating the screen.

That's how I see lookup tables, anyway. I've actually got a large math book full of sin/cos/etc. lookup tables. Very handy when you don't have a calculator.

Look up tables are basically pre-calced things, for example, if you didn't want to calculate sine values in real time you could use a look up table eg,

dim sinetable#(359)
for n=0 to 359
sinetable(n)=sin(n)
next

Then instead of using sin(n) you could use sinetable(n) in your code.

Obviously this isn't as accuate as using sin as you don't have all the sin(10.3) for example, however, if you only ever used whole numbers for your sin lookups then this would be slightly faster than using sin.

This is a very very basic example. If you had more complex calculations then it would obviously increase speed more dramatically.

Posting at the same time! Sin look ups are popular!

Indeed, that's rather peculiar.

By the way, Rob, is there any means of speaking with you 'directly' (e.g., MSN Messenger, IRC, etc.- can't use AIM though, seems my account was shut down..)? I'd like to have a word with you later if it's of no inconvenience.

Hey, Thx guys. :)

That clears it up for me. :)

Noel, I'm having an evening of TV this evening, The new series of Little Britain is about to start then the Sopranos. Send me an email so we can sort something out.

Yeah, in a way...

Back when Doom and Duke3D were state of the art they used several look-up-tables...one was a sin() table to store precalculated angles and whatnot...but another was a bit different...

Both Doom and Duke3D were developed for VGA 8-bit graphics...they used a 256 color palette in displaying the screen...however for certain effects such as darkening objects in the distance, partialy transparent objects, lighting effects where rooms faded to darkness and such...were done with palette look-up-tables...so instead of putting say color number our on the screen, the look up table was used to find the right color to draw instead for the effect that was trying to be achieved...

Other uses for LUT(look-up-tables) include random number generators (which can be very useful if you want something like a game replay to always work exactly the same)...and in some ways even BSP-trees and Oct-trees can be considered complicated LUTs...basicly anything that can be precomputed inorder to save time, or make things easyer...stats for the monsters in an RPG is another example.

Look up tables ara also very appliable when you want
to use patterns or rails for moving things around.
Let's say you have some aliens moving in a sine-pattern
on the screen. If you use a look-up table they will always
follow the exact same screen coordinates, if you on the
other hand use real-time sine calculations the pattern will
over a little time "slide" to one side as the floats will
be a little bit different rounded each time thay are calculated.
This is why I have used tables mostly anyway,
and it usually is a bit faster than real-time calculations too.