World: r3wp

if you can do one thing to help me.... make a style which doesn't 
allocate any of the gob type data.  (color, text, draw etc) so that 
when you print the gob its basically a none gob.

ok, cool

I use the none type gob as an indicator that it *might* be a cgr, 
this allows me to quickly check any face without it being to slow 
to retrieve the CGR internal data.

I hope Carl and I will agree on some definite way to allow some kind 
of custom data extension.

I need an extra pointer in the C gob structure.  cause basically, 
all the renderer data is gob-centric... right now I'm allocating 
an array and iterating through it which isn't very optimal, though 
this makes it 100% safe in the current host-kit.

Two consecutive runs cause following:

>> do %opengl-complex-tree.r3
Script: "Untitled" Version: none Date: none
Script: "Untitled" Version: none Date: none
IMPORTING LIBS
CANNOT SET CGR LIB MORE THAN ONCE (cgr_opengl.dll)
====================================
OpenGL CGR initialization:
registering polygon primitive
register-primitive() [
        valid-prim?() [
        ]
        cgr-name() [
                OpenGL
        ]
]
====================================
Script: "Untitled" Version: none Date: none


then it stops for a while, then it shows window, and outputs other 
stuff to console ....

Pekr, profesional way is to use tool like: http://www.fraps.com/faq.php
I have 60fps for torus example

which is the max allowed by wait 0.01

yes pekr... as noted in the help message, you can only import the 
cgr lib once... if you do a script which already imports the cgr 
lib it will complain.

if you are showing the tree-heavy, its a 170000 vertice model which 
ways 15mb on disk and 50mb in ram !

on my system tree-heavy averages 8fps at any window size. 


the reason its this slow is that I'm not using any kind of smart 
opengl video ram caching atm.  this will obviously be done in time... 
for now I still need to implement things like a real camera primitive, 
lights and materials.

I suppose the file format could use some compression. Or you could 
make an .obj importer, which I think already exists for R2.

With the heavy tree I have 20fps but I can hear strange sound from 
my notebook.

max - why don't you use more precise wait?

oh... if there is an .obj importer I'll use it.

yes oldes,  I am hearing it too... I have NO CLUE what that is.

possibly the gpu fan is getting a little hit at every frame.

your CPU is crunching :-)

in games, it won't be as obvious cause its not doing an exact same 
cycle at each refresh.

I don't think it's caused by fan and I'm sure it's not good for hotebook's 
health:)

pekr... wrt wait, cause I didn't have time to add MM timers to the 
host yet.

ech.. hotbook.. good name for mine:)

Oldes, the other thing I am thinking is that it might be the disk 
paging some stuff.

why you should do it? IIRC, we already have more precise timers ...

not timers... counter... not the same thing.   precise counters use 
the Clock frequency to measure time differences.

they don't trigger events.

MM timers use more precise interrupts so allow sub ms event timing.

though they are deprecated starting in vista, in preference to queued 
events, which I think aren't as precise.

seems like the .obj importer/viewer script is gone, but the script 
may have been done by a Jan Skibinski. I clearly remember seeing 
a script that displayed a green model of R2D2 in a regular R2/View 
window.

btw - http://www.rebol.net/r3blogs/0088.html

Max - scrap the MM thing. We don't need another non supported timers. 
Queued timers is the way to go then ...

that is only true on linux.

Windows... the OS doesn't allow sub 15ms timing. using standard window 
events... its hard-coded in the event engine.

it doesn't really matter from the r3 script's point of view.   but 
MM timers are a bit more precise since they even allow for audio 
frequency precise timing.

the issue is that in vista/win 7 there are new multi-media libraries 
which aren't accessible by WinAPI which sucks.

http://www.codeproject.com/KB/system/timers_intro.aspx

Queue timers is the only way to go ...

yep, I read the whole MSDN section on the differences between queue 
and MM timers, they both have advantages.

MM timers where replaced by new stuff in the new interface system 
which is part of silverlight/net  I can't remember the name of it.

Does deprecated means - still awailable, but not suggested to be 
used? I mean - what if Win 8 in 2 years removes them?

the way I see it, win8 will remove a lot more than MM timers.

but really, its not a big deal what is used as long as the r3 API 
doesn't change from one OS to the other.

Cyphre and I prefer to use timer setup funcs rather than merge them 
within the gob infrastructure.

timers are rarely needed for a control specifically.  usually you 
want the timer to handle things like network pings, fps controled 
redraws, etc.

so its probably going to be something like:

timer/cycle 'my-func-timer 0:01:01 my-func
and to stop it just use timer/stop 'my-func-timer

uh - what's that? Too complicated - timer/cycle 'my-func-timer 0:01:01 
my-func

That should be discussed elsewhere, as well as discussed with Carl, 
along the lines of tasking and IPC model, etc. I think that timers 
could be usefull outside the GUI too ...

ah... what complicated... 

timer/mode label delay or time function.

honestly, I know carl doesn't care about such a trivial issue... 
if we build it and it works why would he argue?  he does listen to 
our ideas when we have tests and code to show.

Maxim, it works for me now, cool. Some notes:

-The usage/interface seems to me too clunky. Better would be something 
like:
append win make gob! [
	offset: ...
	size: ...
	data: context [
		renderer: 'opengl
	]
	draw: [trinagle ... sphere ... whatever] ;your 3d dialect here
]
And that's it IMO there is no need for other 'bloat' around.

-Since you are proposing the CGR philosophy:

1.is it possible to use more than one gl-gob ? I tried just a quick 
attempt but it failed for me.

2. is it possible to compose normal gobs together with the gl? I 
had no luck with this either.

Regarding the performance:

I don't think there is anything to comment at the moment because 
you are just using the raw/built-in OpenGL abilities (same stuff 
we did with Ladislav and Cal 5 years ago in R2). So talking here 
about FPS or number of polygons has the same information as saying: 
"I have older/newer gfx card" The fps is not related to the current 
code...everything is just direct HW executed calls.