Could anyone give me guidelines on how to program a *smooth* (That is, with the size flexible) multi-tile (square) radar? I've been struggling for hours. The radars I manage to program are nor flexible nor smooth-working(as in, work kinda slow).

note: radar as in, a grid drawing a mini-version of the current map. Mini-map?
I think I have permission to BUMP?
Drawing the radar, i'd imagine, would involve much usage of the drawbox() proc and constantly checking what is around the player, possibly using a double for() loop. I'm just shooting in the dark on this one.

I also believe that there is a demo somewhere that showcases a radar.
In response to Clowd
Drawbox would likely not work here, as the radar is over 32x32 pixels, and it isn't as flexible as icons. A "double for() loop" with no possible direction no help at all, and, sadly enough, I couldn't find demos about radars that are over 32x32 pixels. The radar itself is not a problem at all, but its efficiency and the flexibility are the issue. Sorry, but your post doesn't really help me here. :-/
A mini-map of just tiles within close proximity? It won't be very good because you'll need pixel-by-pixel drawing of it to be accurate at all and the client.screen limits images. Y'know, unless you can figure out a way to save the map as an icon (which shouldn't be too hard, with the use of icon.Blend(), I bet), but then slice them up for use on client.screen like when you move.

A mini-map of the entire map, though much more doable and can be generate at runtime, would probably be slower as a radar (but not as a map) depending on the amount of mobs there are and if you only want to show mobs with clients. If you can keep track of the pixels on the radar, you can wipe them clean and loop through the clients checking for mob.location, and draw them on the radar, where 1 pixel or 2 pixels squared is one turf. That really depends on how large the map it, though.

Now, just a normal radar would be much more doable. You can have a static canvas on the screen that just draws mobs in proximity, or if you want to go that far, on the entire z-level.

My point is you have to be more specific if you want the help. So, what do you really want to do?
In response to CaptFalcon33035
Figures I ain't very good in explaining things to people other than myself. :-/

Perhaps this is a better explanation?
In response to DivineO'peanut
During runtime you need to resize the grid or is compile-time good? Because you're going to have to generate a new grid every time you resize. Now, if you set a range of sizes a person can choose from during runtime, then you can have it all generated at runtime and you'd be able to change it during runtime.

Or, are you saying that you want to be able to scale the grid while the actual canvas remains the same size?
In response to CaptFalcon33035
Change the size during runtime. A 128x128-pixels grid will draw the map twice the size of a 64x64. Problem is, I haven't got a clue on how to do that. :-/
In response to DivineO'peanut
Well, you can create a little prototype grid that you can Blend onto the icon you need. Tell me, are you going to have a certain range, or are you going to have all possible sizes multiples of 32?
In response to CaptFalcon33035
Well, I can't see how specifying a certain range would adhere the general design of the system, but, no, every possible size multiple of 32. My original idea(which almost worked) was to create a 32x32 radar, then chain it together along with other radars of the same type until the specified size is received. Placing would be done in the same manner, in which a radar that could not fulfill a task would move the task to its corresponding radar. Problem is, I've got no clue on how to decide upon the object's location upon the grid, let alone handle the task "moving" in the grid coefficiently.
In response to DivineO'peanut
Should the blits on the radar also scale size?