World: r3wp

in R3, replace the code (at tail) by: 
screen: system/view/screen-gob
unless system/view/event-port [
	system/view/event-port: open [scheme: 'event]
]

pixel_size: 1x1
grid_size: 160x100 
img: make image! probe gob-size: (grid_size * pixel_size)

append screen ekran: make gob! [offset: 50x50 size: gob-size draw: 
[image img]]

do [
	boja: pick paleta 15
	change/dup skip img 0x0 boja grid_size * pixel_size
	for i 0 127 1 [
			for yy -50 49 1 [
				for xx -50 49 1 [

     rr: square-root (((xx + 0.5) * (xx + 0.5)) + ((yy + 0.5) * (yy + 
     0.5)))
					if ((rr > 14) and (rr < 50)) [
						zz: (900 / rr)
						pozicija: (pixel_size * (grid_size / 2 + (as-pair xx yy)))
						dubina: :zz - 18 / 46
						red: to-integer dubina * 63 + 1
						red: red + i
						red: to integer! red // 63 / 2 + 1
						either xx = 0
							[ugao: arctangent 999999999999]
							[ugao: arctangent (yy / xx)]
						either xx >= 0
							[ugao: ugao + 360 // 360]
							[ugao: ugao + 180]
						ugao: to-integer ugao / 360 * 63
						ugao: ugao // 32
						ugao: ugao + 1
						p: level/:red/:ugao
						boja: pick paleta p
						change/dup skip img pozicija boja pixel_size
					]
				]
			]
			show ekran
	]
]

and then you can also do bilinear scaling.

i wonder why it's so slow

wow, SHOW is far from the bottleneck.

Uploaded a version with repeat.... speed is still similar to previous 
versions....

yep, with R3 it's slow too

Vladimir, I can't tell from the loop, but are you drawing 1x1 and 
upscaling or 4x4 pixel blocks?

1x1 + upscaling

see that, i do a scaling in R3:

screen: system/view/screen-gob
unless system/view/event-port [
	system/view/event-port: open [scheme: 'event]
]

pixel_size: 1x1
grid_size: 160x100 
img: make image! probe gob-size: (grid_size * pixel_size)

append screen ekran: make gob! compose [offset: 50x50 size: (gob-size 
* 4x4) draw: [scale 4 4 image img]]

do [
	boja: pick paleta 15
	change img boja grid_size
	for i 0 127 1 [
			for yy -50 49 1 [
				for xx -50 49 1 [

     rr: square-root ((xx + 0.5) * (xx + 0.5)) + ((yy + 0.5) * (yy + 0.5))
					if ((rr > 14) and (rr < 50)) [
						zz: 900 / rr
						pozicija: grid_size / 2 + as-pair xx yy
						dubina: zz - 18 / 46
						red: i + to-integer dubina * 63 + 1
						red: to integer! red // 63 / 2 + 1
						either xx = 0
							[ugao: arctangent 999999999999]
							[ugao: arctangent (yy / xx)]
						either xx >= 0
							[ugao: ugao + 360 // 360]
							[ugao: ugao + 180]
						ugao: to-integer ugao / 360 * 63
						ugao: ugao // 32
						ugao: ugao + 1
						p: level/:red/:ugao
						boja: pick paleta p
						change skip img pozicija boja 
					]
				]
			]
			show ekran
	]
]

I draw 4x4 pixels in image for each pixel I calculate.... and thats 
not slow....

I just tried an improvement that halves the drawn pixels and speed 
is the same...

I won't bet on it, but looks to me like show is the limit... its 
not the first time....

But on the other hand, this slowness gives me right speed to see 
whats going on and to check if algorythm is correct...

I dont even have to make some kind of slowdown loop :) less code 
to write.... :)

Yes, but if you want your code to run faster? :-) (which is what 
we usually want)

yes... if Im going to make a game in rebol out of this, then the 
speed is a must :)

ufff.... demo from contest wont run..... Im on Ubuntu right now.... 
it cannot open sound.....

The layout produces a face hierarchy like this:

	window face
		IMAGE face
		BUTTON face


So that's two faces needing buffers refreshed whenever you do SHOW 
window.
It's faster to have just one face (the window face).

	window face

So do as I do in my stargate demo.

vladimir, by replacing SHOW with prin '. the framerate is roughly 
the same, so SHOW is not the limit.

layout [
	backcolor black
	origin 0
	ekran: image
]

also you don't need SHOW on 'window, but only 'ekran.

aha..... I put show on 'ekran and speed is the same.... 

If Henrik's observation about replacing Show with prin... and that 
speed is the same... there is no need to mess with layout :)


Is there some way of time profiling code ? how to find out wich part 
is slowest?

By the way this script I want to use to make lookup tables for maping 
tunnel 3d coordinates onto screen so when I make those tables I can 
see if math is causing the slowdown....


And question for Anton, what did you use in your "Tunnel" demo.? 
show, direct image manipulation? or just effects for image datatype 
?

in R2 you can only do that by making differences between time stamps

but you only have roughly 1-10 ms precision

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! :-)