World: r3wp

ati always had less than optimal opengl support

but I would have thought that its getting better with all those ati 
cards in macs... anyhow  it could even be an issue specific to win 
7 in 64 bits.

Hey Maxim, just a quick reply...


re 1) IMO that is not good argument. You can use GOB/DATA. It is 
really easy to change R3GUI rather to change GOB datatype.


re 2) Nope. There is no problem to have the current GOB/DRAW dialect 
for 3D commands. The current DRAW is completelz flexible and can 
be enhanced. Also if you are proposing abstracted way for 'renderers' 
then it shouldn't matter if you are rendering 2D or 3D objects so 
no need to have different dialects just because of 2D or 3D behaviour 
(see the OpenGL api, it is also mixed)


re 3) not sure what you are missing on the GOB! datatype..Can you 
clarify?


re 5) I disagree here: the 3D dialect is way to go. It should be 
possible to do a direct commands calls for simple things and use 
vertex arrays and other advanced features for bigger things. I don't 
see any problem why this couldn't be done by command dialect.

re 6) to 12) and the rest:
I'm not trying to make a 

cool" rebol plugin..." - so I hope you won't propose this Carl to 
put into the official HostKit distro :-P

The more you talk about your design the more it looks you are missing 
the point of Rebol need for HW acceleration in more generic sense. 
Don't take it personally, but your approach looks like just yet-another-opengl 
binding extension that every other language have. Until that I thought 
you are planning to do it in a more 'rebolish' way but nevermind, 
at least it is clear now. In any way I wish you good luck with your 
extension! ;)


BTW I think It's time to dust off my OpenGL accelerated R3 prototype 
soon... http://cyphre.mysteria.cz/tests/agg-hw.png(And it will work 
on *all* gfx cards made in the last 5 years ;))

go cyphre, go :-) The more general way is always better. OTOH why 
not add field here or there - but - not for the purpose of one user, 
but once again, upon the well defined purpose ...

I've used this card with a bunch of other 3D demos and with Processing 
(processing.org) and the OpenGL support seemed to be very good - 
must be something specific to the way you set things up, I would 
think

Adrian you are having a very strange problem.  the actual OS and 
opengl code being called is textbox 1.1 OpenGL  I will try to look 
into it, though with the little I've seen the 5xxx series ATI cards 
do come up often has being  "troublemakers" in OpenGL dev, though 
by all accounts the 10.10 drivers seem to cure problems for most 
users.


now I'm not downplaying that its something in my code, its possible 
there is a little something to add explicitely to make your card 
work which is done implicitely on other setups...

if you don't mind I'll use you to test anything I can find.  you 
are at the opposite end of my setup,  mobile nvidia card running 
on 32 bit xp.

I'll try whatever you want me to. As a point of note, it kind of 
looks like the animation is showing 1 in 10 to 30 frames or so. Also, 
I'm not sure that the colour rendering is OK - there seem to be too 
few colours used. Can you take a screen cap showing the torus on 
your end?

its a brown torus:   http://www.pointillistic.com/open-REBOL/moa/files/opengl-torus.png

The colours look OK, comparing to your output. Is there anything 
in your offscreen buffering that could be an issue?

I'm using double buffering, and use swapbuffers at each refresh.

one thing I've been wondering... do you have AA hard-coded in your 
preferences?

%opengl-test.r3 ran fine.

%opengl-simple-test.r3 crashed after a few seconds:

@** Script error: cannot access window in path event/window/data

** Where: all -apply- wake-up loop -apply- wait forever catch either 
either -apply- do
** Near: all [
    obj: event/window/data
    obj: select obj 'handle...

Same error for complex tree.


Happened on torus too, then I figured it out. The error occurs if 
I move the mouse over the animated area. Other than that, it looks 
very cool Max.

gregg, that looks like an older version of the distro... the new 
files are:
opengl-torus.r3
opengl-simple-tree.r3
opengl-complex-tree.r3


also the error looks like something I patched in r3-gui.r3 not handling 
data-less gobs... did you update/change your r3-gui.r3 in the distro?

Just downloaded the release from yesterday and unzipped over the 
old one.

If it's known to be fixed, that good.

could it have been cached in your browser?

(its happened to me before)

The zip is a different size, so I don't think so. Complex and Torus 
are dated yesterday, the others for the 25th and 26th.

Max, the AA settings seem to be the cause of the problem. The card 
was set to "Use application settings" and this resulted in the problem 
- guessing that you're not doing everything you should be to set 
AA up. When I uncheck the option (basically have AA globally set), 
your demo works.

Max, I'm expierencing the same flickering as Adrian does, I'm running 
on a 3/4 year old Sony VAIO with Win7. I can't supply any further 
detail, I'm don't have access to the machine right now. I see a flickering 
torus , a flickering  simple tree and no complex tree at all. When 
I'm back at the machine, I'll try with the AA settings which Adrian 
seems to have identfied as the source of the confusion in just this 
moment.

I was expecting something else to occur, so funny that my guess was 
related.   I'm actually not touching the AA settings.

looks like not doing anything is not always the right thing - is 
it complicated to set the AA level?

I'll look into it, all cards have peculiarities like this.

I actually don't know I haven't played with AA setup yet.

its probably just a simple glCall to do when we settup the viewport.

(simple when we don't want AA... requiring AA probably needs a bit 
more work, since we usually have to chose between what is available)

just tought I'd post this little code snippet for fun....


here is the smallest running opengl application I've ever seen  :-)

rebol []

import %opengl-cgr.dll 

win: make gob! [text: "GL_API TEST" offset: 500x50 size: 300x300 
]
append win box: OpenGL-Gob [size: 300x300]

make-primitive box 'polygon [shape: [vertices [0 1 0  -1 0 0  1 0 
0] faces [ 2 1 0] ] changed: [shape]]
view/as-is win

Good stuff Kaj. Have you posted how you implement server limits when 
serving REBOL up this way? That could be useful information, based 
on first-hand experience.

Thanks. I'm just executing user scripts through a shell script:

ulimit -t 30 -m 20000 -v 10000 -u 10 -n 100 -f 200

/users/try-REBOL/program/r3 -q /users/try-REBOL/program/do-rebol.r 
$1

The ulimit sets standard Linux resource limits for the process and 
its REBOL child process that gets started afterwards

Thanks Kaj.

There should be a more efficient way, for example if you have a REBOL 
binding to the ulimit function, but the detour through the shell 
script is a quick solution

Doc, I don't even know what ldap is, but perhaps we should be using 
github for releasing all unfinished work?

Just for one file of 17Kb? Sounds overkill...

far from it

17,000 bytes ....

If you haven't finished it I presume it is not a trivial task

anyway the ethic we are trying to promote is collaboration

I haven't finished it mainly because I'm not a LDAP user, so I'm 
not familiar with most of the LDAP concepts. The protocol itself 
is quite complex due to ASN.1 encoding.

QED

The license is BSD, anyone can pick it up and improve it.

I wish Frank Sievertsen had put all his code into a repository instead 
of a cd which he then lost!

What source code are you referring to?

his bridge

Java bridge?

yeah ... I had to write my own, would have saved me some time

He had other stuff too .. a shared whiteboard written in Rebol .. 
that was lost

probably based on his tiny paint program :)

Oh, this could probably be easy to build again starting from his 
paint program?