World: r3wp

Actually, in my stargate demo (now that I look at it again more closely), 
I layout a window face with a single IMAGE face in it. I did this 
for some technical reason I can't remember, but I tried very hard 
not to make extra faces unnecessarily.

Anyway, I use a combination of techniques. I use DRAW and face/effect/DRAW 
dialect heavily, COPY image!, image datatype "bulk-set alpha", some 
face/EFFECT dialect, and finally SHOW face.

I just tried to separate math functions like square root and arctan 
with simpler constant values and speed seams to go up a bit, but 
not to much....

Ill try to make lookup tables for all visible coordinates and see 
what will happen....

profiling:
	time0: now/precise
	(your code...)
	print difference now/precise time0

changing CHANGE/DUP to POKE gives a slight speed up, but then you 
need to scale in a different way.

I tried that..... doesn't matter to much.... making lookup tables....

i made optimizations in R3, removed change/dup , parents, temp vars, 
etc...

I also replaced repeat or for structures by loops (to avoid bind/copy 
)
It changes nothing. It remains slow.
The reason is that the script does (10000 * i) iterations

in R3, by just doing iterations and a show (no computations) it takes 
4 seconds.

Then, by just adding the square-root calcul, it takes 8 seconds (2 
times slower).

i a case like that, using rebcode for math calculus in big loops 
will be really faster

Yes, I was just remembering my efforts to squeeze performance out 
of such per-pixel frame drawing and I think Rebol interpreter is 
not fast enough for such tasks. I would use the external DLL interface 
to pass your image to a C DLL function.

We need rebcode in R3.  I understand the fact that it can cause problems 
with other parts of code but if we specifically use it where it works 
it can add a tremendous boost to performance.

agree

Read BrianH's post above (1 hour 22 minutes ago) about why rebcode 
will not be in R3.

But talk of a new "different" rebcode...

Exactly,  why not just create an updated rebcode then.

Brian's answer was more like an excuse than a reason.

:)

Sleepy time for me. I think I might try make the C DLL tomorrow.

Thanks Anton!

Ch is a good candidate, it allows to build c code dynamicly

There.... lookup table done...... speed difference obvious :)
pause after click on button is rendering first frame....

do http://www.visaprom.com/tunel.r

do you have a little gain with this ?

	repeat i 256 [
		foreach pixel lookup [
			set [pozicija red ugao] pixel
			red: red + i - 1 // 63 / 2 + 1
			p: pick pick level red ugao
			if (p > 0) [
				boja: pick paleta p
				change/dup skip ekran/image pozicija boja pixel_size
			]
		]
		show ekran
	]

its a nice refinment of code :)

maybe its faster but my pc i to fast for me to notice.... Earlier 
today I tested script on three years old laptop.... Now I tried it 
on my home pc.. (amd 5000) and its to fast.... :)

Hi. I've got a local variable "level" inside an object, defined has 
follow : "level: length? t".

If I try to print it, no problem. But  if I use "build-markup {<%level%>}", 
REBOL raises a "ERROR no-value in: level". Any idea ?

Is your build-markup call outside the object? If yes, then you have 
to refer to level as object/level (where object is the name of your 
object).

o: make object! [t: "abc" level: length? t]
build-markup {<%o/level%>}

Geomol: no build-markup is called within my object. But I forget 
to say that I use "return build-markup {<%level%>}"
I don't know if I can "return" local vars ?

return is normally used from within a function. So you have a function 
within your object, that returns what you say?

2 secs, I post the snippet

>> o: make object! [t: "abc" level: length? t f: func [] [return 
build-markup {<%level%>}]]
>> o/f
== "***ERROR no-value in: level"

heh, funny! :-)

http://clojurepastebin.appspot.com/2005

Seems like a binding problem.

This works:


>> o: make object! [t: "abc" level: length? t f: func [] [return 
build-markup {<%o/level%>}]]
>> o/f
== "3"

In fact, my html-handler instance is within another object.

Geomol: So, I have to refer to the object:/level as you told me before, 
that's it ?

The difference is, you have level as a local to your function, I 
have level as a member of the object. What do you give to build-markup? 
It's a string, right? So build-markup don't know, what you mean by 
level, I think.

Yes, I give it a string. But changing to "return build-markup {<%html-handler/level%>}" 
raises the same error.

Look at it from build-markup's viewpoint. How should it know, what 
level mean? This is a bit tricky part of REBOL, but it's also one 
of REBOL forces.

level can mean anything depending on the context.

If you write you return like this, it will work:

return build-markup rejoin ["<%" level "%>"]

Geomol: No, sorry I can't understand. level is defined one line before 
I use build-markup ( forget the print statement).

Now we force the value of level inside the string, before the string 
is giving to build-markup

You're right, it works well. But I still don't understand the behaviour.

In my last example, the string become something like {<%3%>}

In your example, the string is {<%level%>}. This is what build-markup 
see, and it has to figure out, what level mean. It can't figure that 
out, because level is a local of your function.

Geomol: you mean that build-markup is sort of blind on locals ?

All functions are in a situation like this. {<%level%>} is just a 
string giving to a function.

I've never seen such a behavior in whatever langage I've used, but 
I'm starting to understand it : thanks for the clarification.

Maybe you can think of it as two persons, one giving the other a 
string. The person receiving the string read "<%level%>". That person 
now have to figure out, what level mean. The person live in a context 
(the global context in this situation, because everybody can call 
build-markup). So it look up level in the global context and find 
nothing, so it gives an error.

If you instead write: rejoin ["<%" level "%>"]

then level is replaced by the value of level and a string is made, 
and this new string is sent to build-markup.

Yes, nice comparison Geomol, we see that you live in the stars :)