Radial / Irregular Menu Implementation

For those who are interested in some of the more 'artistic' possibilities of Rebol/View /Face I have uploaded a basic implementation of radial menues and colour hit mapping to www.mustard.co.nz/rebol/projects.htm . This can be downloaded as just the rebol script: www.mustard.co.nz/rebol/radial.r or, complete with test images: www.mustard.co.nz/rebol/radial.tar.gz In their current incarnation they are too slow for real life work but hopefully with a little tweaking - or with a nice pixel logic module from Reboltech (an inverse key n.n.n.n effect would be nice - clear all pixels NOT the same colour.) things will become a lot faster. The basic implementation is just that, it works but it only scratches the surface of what is possible. James.

Hi James, I notice you could reduce the code in the mask-by-function function: if f/changed? [ menu/image: mask-by-color menu/image-mask menu/image any [ all [f/down? menu/image-down] all [f/hover? menu/image-over] menu/image-away ] f/color which would replace some repetition in the either blocks. For others who might try to run radial.r by itself. It's not ready to go without the images which are in the archive. Anton.

Thanks for that Anton, never really thought to use any/all in if/either replacement scenarios before - too much C/C++ I guess :) The real time-waster unfortunately is the pixel by pixel replacements inside mask-by-color, and not really sure what can be done to speed that up short of using ASM or somehow hooking the effects pipeline for some pixel procesing. James. On Sun, 2003-05-18 at 20:51, Anton wrote:

Yes, you are right. You could speed up that function a bit. Change: for n 1 mask/size/x * mask/size/y 1 [if (pick mask n) = c [poke img n pick src n]] to: repeat n mask/size/x * mask/size/y [if equal? c pick mask n [poke img n pick src n]] 'repeat is definitely faster than 'for. 'equal? is faster than '=. I don't know the speed difference between 'all and 'if, but you could try: all [equal? c pick mask n poke img n pick src n] Gotta test it to see if it's any faster. But I think the way to improve the speed is to take a different approach. I didn't read your code a lot, but I suspect that this function is called everytime a mouse button is clicked? Can't the results be stored in an image? (ie cached?) Cyphre had a collision detection technique on his rebsite that could be worth checking out. Anton Rolls.

Hi James

> The real time-waster unfortunately is the pixel by pixel replacements > inside mask-by-color, and not really sure what can be done to speed that > up short of using ASM or somehow hooking the effects pipeline for some > pixel procesing.

Hi Romano, Some help would be great! Initially I tried using the effects pipeline but due to a lack of an inverse key function masking by multiple images looked to be impossible. Regards, James. On Tue, 2003-05-20 at 04:50, Romano Paolo Tenca wrote:

Hi James This code demonstrates the trick: http://www.rebol.it/~romano/double-key.r to adapt your code to double-key, you must convert our mask in a two colors (black/white) mask, one color for the first image and one color for the second image to merge. You can draw your masks by scratch or calculate them with a rebol program like this, which create a white/black mask: for every color ;transform the color in white m1: make image! layout [ origin 0x0 backcolor white image mask effect compose [key (color)] ] ;luma key: not white pixels become black newmask: make image! layout [ origin 0x0 backcolor black image m1 effect [key 254] ] now you can do: double-key source1 source2 newmask black white ;or black white This works only if the original mask does not contain pure black and pure white points (also this can be esay changed with a key 0.0.0 -> 0.0.1 and 255.255.255 -> 255.255.254) Obviously you should calculate masks only one time at the start of the program. --- Ciao Romano

Ahh, of course! Thanks for that Romano - I'd never though to use the draw dialect portion for compositing either. The only time the double-key code becomes expensive is if there are more than about 8 functions per menu (lots of masks to make..). Ideally I'd still love RT to come up with a reverse key implementation so we dont need slower work-arounds for masking ;) Regards, James.

I notice in radial.r that you have lines like this: image-over: to-image load %radial-over.png It's already an image after you load it, no need to explicitly convert it to an image: image-over: load %radial-over.png Anton.

James Marsden wrote:

>Ahh, of course! Thanks for that Romano - I'd never though to use the >draw dialect portion for compositing either. The only time the >Regards, >James.

> ... sadly as far as View is concernet, none of request of VID 1.3 group

Hi James,

> The only time the > double-key code becomes expensive is if there are more than about 8 > functions per menu (lots of masks to make..).