World: r3wp

On Win7 when starting r3.exe I get "The application has failed to 
start because its side-by-side configuration is incorrect."

Maybe http://buffered.io/2008/05/17/resolving-side-by-side-configuration-issues/
has some hints ...

ahhh... compiled using debug mode.!

ok.... this is going to take a few minutes... since I have to update 
the release mode so it has the same setup as the debug mode.

I got it to work...pretty cool. Maxim!

What's with r2 stuff...does this work under R2 too? I thought this 
was R3 stuff only?

Is this just nice excercise to show the possibilities, or is there 
any feedback from Carl, if he is willing to extend API to support 
such stuff?

no its just that I'm using r2 to build files.

pekr, its not just an exercise.


and yes Carl is interested, it just wasn't obvious what would make 
it easier to hook into, now we have something to look at and discuss.

I am unable to get the external dll working when doing a Release 
level build.  it compiles without any errors... 


but when running the same script which is working in debug mode, 
I get this  error in the console:


** access error: cannot open: %opengl-cgr.dll reason: "not found 
or not valid"

very strange

Perhaps because of the option -s "which strip the symbols from binary"

Some things that might cause it:
- memory alignment
- uninitialized globals that are used
- missing entry points (use something like dump to see it)

might be the struct alignment.... I just found that it wasn't set 
in release level

yep... that was it  :-)

updated R3-CGR with a Release compiled build.  please test, thanks.

http://www.pointillistic.com/open-REBOL/moa/files/r3-cgr.zip

OK, now I get an error that I don't have HW acceleration in virtual 
box, so I guess that's a good sign. :-)

:-) yep...

Crashing on Win7 after printing

... (several lines omitted ..)
1362:polygon  : 1362
--------------------------------------------------
POLYGON PRIMITIVE
...
-->Select_Float_Array()
-->HT_Select()
(crash)

For those interested in a quick overview of the changes in the hostkit, 
here's a diff between CGR-A109 and RT-A109:
https://gist.github.com/9d6d0330b88d6d5419b1

I was out of town, back now... Christian, yes it seems there are 
still one or two compile things to figure out, I'm getting random 
crashes too.

oddly, in debug mode its 100% stable.

Andreas thanks for that.... 


that is exactly why I spent a day re-organizing my code base so that 
the host and the CGR system are now almost separate.  

its now very easy to see what little changes are required for CGRs 
to work.  


though a few tweaks in the host would make CGRs a bit faster and 
simple to use.

one note is that a few of the changes are in fact just added documentation 
in the host, which is scarce at best.


I think it would be nice that as people work on and study the host 
files, more documentation be added, if only to improve its understanding.


many of the view files use short variable names which is ok, but 
the sense of what and most especially *why* things are being done 
is currently very
obscure and I can see it being hard to maintain in the long run.


when you look at all the box region math, sometimes being done more 
than once on the same values, its very hard to positively identify 
what is being calculated and why it even needs to be done at that 
point in the various functions.


when I look at the code, there are many very similar ops being done, 
and it might be that some of that should be reshaped into more re-usable 
code.  maybe if only as multi-line macros, to keep it fast.

christian, if you can send me the full trace of the app it might 
help me track the problem...  either mail it to me or just dump it 
to me privately in altme.


I think its a problem with how VC is optimisizing things to be parralelized 
by SSD type instructions.


on my system its not crashing exactly at the same place but within 
the same source file.  seeing a pattern might help me corner it.

Maxim, the demo crashes for me right when it attempts to open a window..I 
tried it also with the torus.r3d dataset so there must be some other 
problem.

I've had that too, but changing the optimizing on Release mode, I 
have just about the same issue as Christian.


in debug mode I've *never* had a crash yet. even on very small or 
huge datasets.


so AFAICT its a dreary compiler issue, and the worst of it is that 
I can't debug it, cause it *only* crashes when I'm not in Debug.

at this point I've cornered it to the host-tools array code which 
is basically just a loop over the host-code.  so its possible that 
the way the core dll was compiled is part of the problem.


I'll try to compile the A107 version in Release mode.. maybe it was 
built using different switches.

Crashes for me too, under XP x64.

on window open or after a ->> / <-- trace line?

On window open.

Maxim, all demos run fine now.

thanks.  Andreas told me he was reaching 70fps using the simple tree 
demo running wine on linux!

closer to 2-5 fps here, but probably due to software OpenGL

(strange that it runs now, when I was warned before that OpenGL wouldn't 
work)

the heavy tree is quite hard... the torus should be real-time even 
using software mode.

also when first showing the window, the view area is only in about 
the upper left quarter of the window. a resize solves this.

I get between 5-10 fps on the torus. I suppose virtualbox doesn't 
do this stuff very well.

wrt resize, yes that is on purpose.  it allows me to test events 
within and without the opengl.

its possible wine allows some of the rendering to find its way to 
the gfx card.

ok

ok, next step: modeling dialect :-)

and yes it is strange that it works now and didn't work before!  
I didn't change any of OpenGL code, though I had a serious memory 
corruption issue, so its possible that on your system, that translated 
to some bogus system call.

it has been behaving strangely just yesterday (openGL issues) and 
today (network flakey), so I'm not even sure it will keep working. 
:-)

what is the .r3d format like?

hehe.  if you look at the demo files, you will see how to specify 
a polygon primitive... its dead simple... a list of vertex... and 
a list of faces (which are indices to the vertices)

look into the torus... its a rebol loadable data file.

the same as the commented out primitive in the tests.

It would be wonderful with an actual dialect:


view [my-torus: torus scale .2 rotate 45 material [specular: blah]]

yep that is how it will be... its already close to a dialect.  I 
just need to add more attributes.

btw notice that I included your last release of the r3_gui.r3 in 
the cgr-apps to make sure I stay forward complient... though you 
may want to do a diff on the version included and yours in order 
to patch crashing events when they originate from a gob which isn't 
a face.