World: r3wp

and alpha? :-)

rgba-to-int: rebcode[r g b a][
	to-dec r r
	to-dec g g
	to-dec b b
	to-dec a a
	muld g 256.0
	muld r 65536.0
	muld a 16777216.0
	addd b g
	addd b r
	addd b a
	to-int b b
	return b
]

Thanks Ladislav! Been a while since I learned about the math. I can 
cope with it using those 3 operations instead of exponent or root.

Oldes, I think this is a bit faster ;)
rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	add a r
	add a g
	add a b
	return a
]

Cyphre, use OR instead of ADD and there will be no troubles with 
arithmetic overflow. It'll be faster too.

I think there shouldn't be aritmetic overflows as the passed arguments 
are meant within range 0-255 but you are right that OR should be 
even faster!

so probably final version:
rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	or a r
	or a g
	or a b
	return a
]

There might be a problem with arithmetic overflow if a < 127, as 
lsl a 24 would result in a negative integer, but I may be wrong here. 
Still, why risk it?

>> rgba-to-int 255 255 255 255
== -1

Kru, which version did you use?

last one

Cool, it works the way I thought it would :)

BTW negative integer doesn't  matter when changing pixels in IMAGE!

>> to-integer to-binary  255.255.255.255
== -1

but to integer! to binary! [issue!] is not same as rgba-to-int

OTOH the pixelformat of accesing IMAGE! in RebCode id ARGB

>> rgba-to-int 255 255 255 1
== 33554431
>> to-integer to binary! 255.255.255.1
== -255

>> to-integer to-binary  1.255.255.255
== 33554431

ALPHA is the first component

(in Rebcode)

Really?

rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	or a r
	or a g
	or a b
	return a
]

draw-pix: rebcode [r g b a][
	apply a rgba-to-int [r g b a]
	poke img 1 a
]

update-pixel: does [
	do draw-pix col/1 col/2 col/3 col/4
	probe img
	show i
]

col: 0.0.0.0
img: make image! 1x1

view layout [
	backcolor black
	i: image img 100x100
	scroller 200x16 [
		col/1: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/2: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/3: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/4: to-integer face/data * 255
		update-pixel
	]
]

not if you do PICK on image!

I mean in regular REBOL code.

I guess Cyphre has a good qualification for such statements ;)

I REBOL the pixelformat is RGBA due to tuple! behaviour (you can 
left the last value of tupple == opaque pixel)

So another coversion needed :)

In REBCODE you are accessing image! internally so the pixelformat 
is ARGB.

Kru: yes, in Rebol there is conversion done. In Rebcode you are at 
full speed ;)

Cypher, have you looked at the apply problem?

not yet

There's an apply problem?

trying to reproduce the problem I've just crashed REBOL with CRASH 
Should not happen

Maybe not a problem, but overhead?

And REBOL ate all memory

can you post the code?

yes, show us!

two testing functions:

>> mulr: rebcode [a][mul a 2 return a]
>> mull: rebcode [a][loop 10000000 [apply a mulr [a]] return a]

From my tests calling a REBCODE function (or subroutine) using APPLY 
is by 100% slower than reusing the same code.

first test: xt: now/time/precise loop 10000000 [mulr 2] now/time/precise 
- xt

Is that neccessary?

second test: xt: now/time/precise mull 2 now/time/precise - xt

ssecond does has some problem

does=test

Is it neccessary to tune that, or would macro-expansion do? faster 
anyway. How big may rebcode-parts be?

hunderts lines of rebcode in my case :)

Not much memory then! But much work :)

1GB is not enough for ten milions multiplications? :)

It looks like APPLY inside a LOOP is causing those problems.