World: r3wp

beer for me, please

probably get rid of FOR. it's a heavy mezzanine.

BTW, there are bugs in image! in R3, so colors might be wrong.

vladimir, GOBs are graphical objects blocks, light weight constructs 
that are the foundations of all graphics in R3.

a FACE in R2 would almost be the equivalent, although faces are more 
complex and heavier.

Another way to make tunnel effects.
do http://anton.wildit.net.au/rebol/demo/rebol-stargate1.0.2.r

I knew about gobs, I just thought you need vid for them.... :)

Vladimir - actually no - gob! is very low level, structure. Demos 
of former alpha, e.g. 1000cows, proved that R3 engine is much faster. 
Sometimes 10-20 times. Whole rendering back-end was switched to AGG 
renderer. So - still not HW accelerated, but decently fast.

Anton, impressive!

In theory, it would be easier to hardware accellerate AGG than the 
old View.

I'll wait to see what will Steeve write and than it will be clearer 
:)

I think the point of GOBs was both to be lightweight and fast and 
also to be hardware acceleratable (if that's a word :-))

accelerable

hmm :-)

guys, can you check that in R3, it's crashing here:
>>make image! 640x400

All the heavy work is done using face/effect/draw dialect.

That's a known bug, in CureCode already.

*hmmm...

sorry Vlad, i'm afraid, i can't port your demo in R3 with this bug

image! is broken in multiple places

It crashes for me when image height is > ~175

Btw, here are the reasons there won't be a compatible rebcode forr 
R3:

- R3 function parameter and local word references are 28% slower 
because of new function word model.

- R3 function calls are much faster because of typesets and the new 
function word model.

- There's a *lot* more natives, including all of the loop functions, 
iirc.

That first one would slow down rebcode even more than functions because 
even more of its overhead is word references. The last two mean that 
REBOL code will be a *lot* faster, so the relative speedup of rebcode 
is less.

Vladimir - I wonder if you checked demos in Desktop section of Viewtop? 
Go to rebol.com and then Contest folder. Look e.g. at Cyphre's demo 
called Quick Hack ...

Those reasons are why R2-style rebcode isn't worth the trouble to 
make in R3. What *would* be worth making would be a *different* rebcode 
that would be even faster :)

Anton, it crashes under R2?

no no, under R3, of course.

ah, good. I mean, bad. :-)

We can still play with R2 graphics until R3 stabilizes.

BrianH: could that work as a plug-in for e.g.? Or - do you think 
it is possible to have even several VMs that way? Simply a compiler? 
Maybe we could even find some small C compiler to be included with 
REBOL? (if that would make sense)

Right. Wait, it's up to 175? When last I checkede it was 89.

Maybe it is an easy fix? Well, I think that Cyphre is back to project, 
after Carl syncs his sources with him ....

last I checked, I needed only about 5x5 pixels.

Pekr, with plugins and utype! you should be able to use TCC to complile 
functions :)

I have my coffe and code now runs twice smoothly than first version 
:)
www.visaprom.com/tunel.r

And I tried that size trick:   view layout [image img (img/size * 
8)]
and speed is the same.....

what is TCC?

Tiny C Compiler. I don't have the link handy on this computer, but 
google it.

vladimir, try to use REPEAT instead of FOR. REPEAT is native.

http://en.wikipedia.org/wiki/Tiny_C_Compiler

Thanks. I found original site. Well, 100KB to have cross-platform 
compiler? Nice. It will not prevent devs to write cross-platform 
code, but those who would like to do so, could do so, and that is 
important ... Licence - LGPL, so it might work OK as an extension 
...

Plus you could use C as an intermediate language for a REBOL dialect 
if you like.

I think change/dup is pretty fast at setting blocks of pixels. The 
bottleneck must be somewhere else.

yes, got the same prob in R3, it's slow

making some of those calculations more rebolish might help a tiny 
bit. ultimately SHOW will be the factor.

you could remove the show and see how much faster it gets by printing 
a value to the console.

It would be nice, if we would have direct access to datatypes from 
C level. Dunno if plug-ins or rebin can provide us with such functionality. 
E.g. manipulating images was rather easy, as its structure is just 
RGBA pixels (bytes), but access to something like Block would be 
probably rather tricky :-)

Henrik - are you talking about R3 show?

no, R2 SHOW.

We'll see, Pekr. That is still being decided.

I think you could gain some speedup by not multiplying the image 
by 4, but let DRAW scale the image on SHOW.

this requires some changes in the layout.