World: r3wp

As I'm interested only in pure vectors, REBOL speed is succifient 
for me :)) But yes, REBOL can probably be linked to some external 
library (as Cyphre did with OpenGL) or SDL maybe? But I don't think 
it should be high on priority list, other things are more important.

Cool: IMHO the priority should be on moving camera now. And some 
support for collisions, maybe only in 2d-space. Idea: some kind of 
3d-icons. I can live with colored pyramids and some text, but i need 
to move.

Volker: there's camera code, but there's probably bug in invert matrix 
function so the camera does not work right now. I'm trying to find 
some informations on that topic and to fix it.

And then we do a 3d-desktop? :)

distributed 3d desktop nased on rebservices? :)

nased=based

Yes. Something like this atomic modells. Each ball is a site and 
you can move along the connections :)

Just a small update: I've fixed matrix inversion so it's possible 
to move camera now. It's not possible to rotate camera but I'm working 
on it.

nice demo, it's eating almost no CPU on my computer. But if I click 
and move cursor, everything is stoped.

that's because mouse events have higher priority than time events 
and the scene is refreshed only when time event occur. If you move 
your mouse, no time-events are generated.

Every event has a time (event/time), so this could be worked around.

Is there someone interested in making dialect form making rebcodes? 
Or someone already doing it?

form = for

I think Gabriele has work on that IIRC

work=worked

Maybe it would be goot to have some registers in rebcode to store 
temporary values which are needed for more cmplex calculations (no 
need to set named variables)

Yeah, I was thinking about that, too. Maybe someone with more experience 
in this area can comment.

Added to Rambo (with bug in the example:( http://www.rebol.net/cgi-bin/rambo.r?id=-505&

and with bug in my english as well: goot = good :(

Fast atan2 function: do http://box.lebeda.ws/~hmm/rebol/rebcode/latest/rc_atan2.r

Based on this C code: http://www.dspguru.com/comp.dsp/tricks/alg/fxdatan2.htm

How accurate is it ?

just do the usage block to see

It could be more accurate, but I don't know how to do [ r^3 ] in 
rebcode (where r is decimal)

But I think the accuracy is fine if you are doing animations and 
effects based on atan2 function - where speed is more important than 
precision

sorry, wrong link, should be: do http://box.lebeda.ws/~hmm/rebol/projects/rebcode/latest/rc_atan2.r

Mmm.. It looks slower than ARCTANGENT

Can you put the rebol equivalent (non-rebcode) alongside the atan2 
examples, in the Usage ?

(about 20% slower, by the way. But I'm not confident of my quick 
tests.)

How can I access values in objects from rebcode? (when rebcode is 
not in the same context)

Anton: it's logical, Arctangent is one opcode in the rebcode

Kru: I don't know, write it to Rambo as a wish if you wish:)

Yes, I wish :) I think something like: pick x object value

But maybe it's possible now, I just don't know how.

Oldes, what's the advantage to your rebcode algorithm then ?

atan2 <> atan

atan2 is not very well chosen name, it's pretty confusing. but that's 
not Oldes' fault

Oh I see now. :)

To access objects, you need to escape out of rebcode. Remember (everyone), 
use rebcode only when you need it.

As I work with sound synthesis and 3d graphics I use lot of maths 
so I need rebcode imost of the time :) I had data structures using 
objects, so I rearanged them for now. I wrote it as wish to RAMBO.

You can use 'third, 'get and 'set to turn objects into blocks. only 
from the rebol-side, but maybe it helps a bit.

Kru, you can use apply in or apply bind to get a word bound to the 
object field, and then use setw and getw to get at the values.

Continuing from SDK group: I noticed that cyphre thinks pixel writing 
and reading can be a bottleneck in the current rebcode implementation, 
which is why the native convolve functions in rebol/view 1.3.2 are 
much faster than the rebcode version demonstrated earlier.

By providing ways to read and write RGBA information directly without 
needing to extract and combine them first, rebcode could be faster 
at per-pixel operations.

Any thoughts on how to do this?

allow tuples for rebcode?

I got an email from Carl at one point regarding this issue. I asked 
to have poking of tuples in rebcode. Carl wrote:

Regarding below, tuple poke not supported on images.
But, perhaps 
it makes sense to add that, eh?


As I also see it, adding support for tuple datatype from within rebcode 
is a good solution. Carl is aware of it, it seems, so just *poke* 
him once more and ask for that. It should also work with PICK of 
course (reading pixels).

So, has anyone the idea of possible syntax to work with pixels in 
rebcode, so that we could submit an enhancement?

For writing:
poke img 1 255.255.255
or with alpha:
poke img 1 255.255.255.255

I'm a bit in two minds about this. Reading is done with PICK, but 
it'll return an integer. So how to make it return a tuple? Something 
like:
pick.tuple result img 1

Not so good, eh? Maybe we need a TO-TUPLE command in rebcode. And 
how will it influence performance? Maybe it isn't such a great idea 
to add support for tuples to rebcode!?

hmm, 'to-tuple is not bad. it's just a graphical interpretation of 
bytes in memory. there's no difference between 16777215 and 255.255.255 
. It's just parser's job.

shouldn't it be an op-code? like TUPLE-PICK, only a slightly less 
goofy name :-)