World: r3wp

still works here

with 2.7.7.3.1

worked fine on my work laptop, but not my older desktop PC.

Same as brock : just a black screen. WinXP 32 SP2 / Rebol 2.7.7.3.1

interesting - I'm guessing it's the offscreen buffer - maybe can't 
be alocated or flipped to properly - maybe a video card/video driver 
issue. Brock/Didec, are the video cards you're using of the onboard 
type with shared memory?

The desktop is not an on-board graphics card, the laptop would be. 
 In both cases I'm not certain about the memory.

Hi! Hope this is the right place to ask... I'm using 2.7.7.3.1 (not 
that it should matter for this question)...

I would like to use and re-use vid "panel" gui elements. Something 
like: view layout [style gint panel [text "label:" field 100 "0"] 
 x: gint (x) y: gint (y)]

The idea is that somehow (magically?) the panel could specify an 
aggregate UI element so I could reuse just a few styles that have 
their formats baked in. Any ideas? Or should I come up with a better 
example?

Preferably, this would be done at view definition time as shown above.

set-face

 seems to show a way to handle it, but it's clumsier than I would 
 like and doesn't handle the text labels.

Does stylize provide what you need?
   http://www.rebol.com/docs/words/wstylize.html

Hi JoshF, do you want a style (eg. your 'gint') that is simply replaced 
by two other styles (eg. a TEXT and a FIELD) as if you had simply 
specified them individually yourself, or do you want a panel each 
time (which contains the other faces) ?

A simple approach that might work for you is to build your layout 
spec block before passing to LAYOUT.

make-gint: func [label int][compose [label (label) field 100 (mold 
int)]]

window-spec: compose [title "Food calculator" (make-gint "Elephants 
to invite" 65536)]
append window-spec make-gint "Peanuts/elephant" 5000
view layout window-spec

Check out this doc from 2007 as well.
http://anton.wildit.net.au/rebol/doc/flatten-panel.txt

Hi! Thanks for the replies!


Sunanda, I am using stylize (as shown in the example below). Anton, 
I don't mind having a panel because I need to keep the data grouped 
to access it generically after the user has set values. Here is a 
better example showing what I'm trying to do. Essentially, I want 
to create an "aggregate" widget using a styled panel, then initialize 
its elements the same way as is done for the built-in VID styles:

    REBOL [Title: "Node Property Sheet" Author: oofoe] 
    ; This example will not actually work as intended.
    
    s: stylize [
    	title: vtext red 256
    	label: text 64
    	gpath: panel [

      across  label "Path:"  field 150 "Unspecified"  button "..." 30]
    	gint: panel [across  label "Integer:"  field 50 "0"]
    	gnumber: panel [across  label "Number:"  field 75 "0.0"]
    ]
    
    view layout/size [
    	styles s
    	
    	title "Project Settings"

     gpath "main" %. ; <-- I want to just specify the label text and value.
    	gint "width" 1024
    	gint "height" 768
    	gnumber "fps" 23.97
    ] 384x256


The nice thing about this (from my perspective) is that I can iterate 
through the property panel fields, find any recongized styles and 
pickup their values (that have been set by the user) using a hacked 
version of get-face. 


Am I making sense? I just feel that there should be a way to set 
relevant panel values when you're using the style. Thanks!

It definitely makes sense, and I wanted to do this many times myself, 
but I just never got around to doing it.

It seems like the "do-facets" section in the "layout" source is the 
key (or close to the key) for doing this. There *is* a generic system 
for handling this, but it's not documented (!) and the layout source 
is far too clever for me to easily figure it out... ; - )

Possibly a style should define a function that is used by layout 
to set it's values. If so, I can do that with "with" and the problem 
is solved...

Yep, LAYOUT style-specific sub-dialects are possible by messing with 
the MULTI facet, or with the WORDS facet.

or better, with the FACETS facet.

Try this:

stylize/master [
	gint: panel [across label 200 field] with [
		multi: make multi [
			text: func [face blk][ ; <- strings
				if pick blk 1 [
					print ["Text:" mold blk/1]

     ; Do nothing (prevents the default PANEL/MULTI/TEXT from setting 
     the panel's face text).
					;  print mold get in svv/vid-styles/PANEL/multi 'text
				]
			]
			size: func [face blk][ ; <- pairs and integers
				if pick blk 1 [
					if integer? pick blk 1 [
						print ["Integer:" blk/1]
						; Do nothing.

      ; I was going to set the integer field's text to this number directly, 
      but the panel's

      ; subfaces haven't been created (in its PANE) at the time the MULTI 
      functions are processed.

      ; So then I thought I'd use FACE/DATA to store this value and then 
      set the field's text

      ; later in INIT, but thought better of it, since I found it's easier 
      to parse FACETS,

      ; and I don't feel comfortable using the panel's DATA facet to store 
      a value of only
						; one of its subfaces.
						;face/data: blk/1
					]
				]
			]
		]
		append init [
			;?? texts
			;?? facets
			context [
				lbl: pane/1
				fld: pane/2
				foreach val facets [
					case [
						string? val [lbl/text: val]
						integer? val [fld/text: form val]
					]
				]
			]
		]
	]
]
view window: layout [
	gint "Elephants to invite" 481
	gint "Peanuts / elephant" 5000
	btn "Calc"
]

OK... Hang on, I'm just trying to figure understand all this...

So the "facets" value inside the init/context is just the arguments 
to the style in the original layout?

Thank for the example, Anton! Mind: Blown. I know Kung-f... I mean, 
how VID initialization works!


Here's my cleaned up (and working!) test program. It should be a 
little more generic than your example, since it will set values until 
it runs out of facets or pane items. Label styles are treated specially 
though, as you can see. Maybe now I can fix their set-face method...

    REBOL [Title: "Node Property Sheet" Author: oofoe] 
    ; Special thanks to Anton on altme/Rebol/View! 
    
    s: stylize [
    	title: vtext red 256
    	label: text 64
    	agg: panel with [
    		multi: make multi [
    			text: func [face blk][]
    			size: func [face blk][]
    			decimal: func [face blk][]
    		]
    		append init [
    			context [
    				p: pane  f: facets
    				while [all [not tail? p  not tail? f]] [
    					either 'label = p/1/style [
    						p/1/text: f/1
    					] [
    						set-face p/1 f/1
    					]
    					p: next p  f: next f
    				]
    			]
    		]
    	]
    	gpath: agg [

      across  label "Path:"  field 150 "Unspecified"  button "..." 30]
    	gint: agg [across  label "Integer:"  field 50 "0"]
    	gnumber: agg [across  label "Number:"  field 75 "0.0"]
    ]
    
    view layout [
    	styles s
    	
    	title "Project Settings"
    	gpath "main" %. 
    	w: gint "width" 1024
    	h: gint "height" 768
    	gnumber "fps" 23.97
    ]

This is so cool! I am excited!

Here's the agg style with get-face doing what I want (returning the 
field name with everything else in a list, suitable for dropping 
into a key/value list):

	agg: panel with [
		multi: make multi [
			text: func [face blk][]
			size: func [face blk][]
			decimal: func [face blk][]
		]
		append init [
			context [
				p: pane  f: facets
				while [all [not tail? p  not tail? f]] [
					either 'label = p/1/style [
						p/1/text: f/1
					] [
						set-face p/1 f/1
					]
					p: next p  f: next f
				]
			]
		]
		access/get-face*: func [face /local p label x] [
			p: face/pane
			label: to-word p/1/text  

			p: next p
			x: copy []
			while [not tail? p] [append x get-face p/1  p: next p]

			return reduce [label x]
		]
	]

Well, thankyou for asking the question. It's nice to see your working 
result, too.

shape collisions  :-D
a little milestone  in my rebol game development kit... 

The first version of an SAT-based collisions lib for arbitrary convex 
polygon  is now fully functional:

test it in action in this test script:


do http://www.pointillistic.com/open-REBOL/moa/files/ctest-preboled.r


note that it handles shape rotation which isn't always supported 
in implementations of this algorithm on other platforms.

the SAT (Separating Axis Theorem) algorithm is even optimised so 
it only manages the edges facing each other.

the result will be several times faster since we end up only comparing 
(at a maximum) half the edges of each polygon ( for two boxes this 
ends up being 2^2+2^2 (8) as opposed to 4^2+4^2 (32)comparisons. 
 for a triangle and a box, it could even end up being as little as 
1^2+2^2 (5)  instead of 3^2+4^2 (25).


the advantage of the SAT algorithm is that its reasonably fast and 
is an early opt-out loop, so the moment we find a single comparison 
which is negative, we can positively ignore all the rest.   this 
means that it scales pretty well, when polygons aren't close to each 
other or when they are small.

next step is implementation of the gross-level polygon proximity 
test (a fast algorythm ignoring polygons which are too far away). 
 


this allows many polygons to live in the same scene without requiring 
collision tests for them.


I'll probably use a double linked-list for X and Y sorting of polygons. 
 this allows us to start at our position directly and spread the 
search on each side of the list (in both directions).

has anyone played around with SAT systems before?  or with spatial 
sorting algorithms?

I have questions about the most adapted spatial sort algorithm to 
use in REBOL

Nice work.. it would be even more interesting if Cyphre's JIT could 
be used to speed up some of your functions one day.

yes I was thinking about it, especially since most of the CPU intensive 
code is highly compilable.

one thing which is nice in the current system is that I'm not using 
pairs, but blocks of two float values, so a part from the actual 
AGG coordinates, everything is floating point and quite precise.

Nice work Max.

Yeah, looks good - do you have any guess how this would compare with 
Algodoo (speed-wise) once you're done? It does use OpenGL, but I 
guess you could too.

http://www.algodoo.com/

right now, I'm still flushing out the raw maths, but somehow, AGG 
always seems to squash any speed gains I get out of better interpreter 
speed.

sometimes doubling the number of elements makes the refresh 10 times 
slower, sometimes, there is no noticeable difference. I'm still trying 
to find the best way to render things.  my guess is the GC is constantly 
interfering since the draw blocks have to be rebuilt over and over. 
 which is still my main issue wrt using draw in R2 and even R3.


if i forego of rendering, there seems to be no noticeable effect 
of processing the collisions, so I hope, its not just "a trick of 
the light" and that my current wip (handling collisions between many 
polys) is going to work well.

Using R3 with stuff compiled and sidestepping draw in order to use 
AGG directly would probably allow several hundred frames per second 
for this simple test.

algodoo is cool  :-)

do you have any idea why your demo limits itself to 32 fps? It does 
this on my system and Sunanda's so it makes me think that it's an 
internally imposed limit.

its the maximum timer resolution possible in R2 view.

it might be possible to use a callback and allocate our own OS timer 
via library calls, but I think it not worth the hassle.  going past 
32 fps didn't produce noticeably smoother animation, and it allows 
much more time for (slow) math and AGG rendering in REBOL.

(staying at 32 fps, that is)

its already an issue that AGG or the GC seems to be generating a 
steady memory leak at each refresh, which I will have to investigate 
further.

Max - interesting achievements. Do you really think, that the draw 
dialect interpretation is the culprit and performance killer? IIRC 
Cyphre said, that time to interpret the draw block dialect is really 
negligible ...

right now, one thing is sure, the fact that I have to go thru rendering 
"passes" for each part of the rendering slows down the rendering 
a lot.


the actual number of strokes doesn't affect the rendering as much.


trying to compile all the dynamic graphics into a big block is also 
affecting performance.  but each individual group of elements is 
rendering at under 1% cpu.  rendering three passes jumps the cpu 
to 20%!!!


reducing/composing the passes together is almost as slow as seperate 
passes, sometimes even more.  i am rendering at least 32 fps.  If 
I have to rebuild a 50kb draw block at each render, the interpreter 
is "spinning air" redoing things over and over, allocating intermediate 
blocks for not much real reason, because in this case... the shapes 
actually change even comming into/out of existence dynamically.  
I can't just use static binding, the actual drawing is changing.

allocating intermediate blocks for not much real reason ...

 - so how would you do it? If I understand it correctly - if you want 
 to use a dialect, you have to go via its interpretation, so I wonder 
 if it can be improved ...

from a normal REBOLer's perspective I don't see any different way. 
 Don't get me wrong, draw and gobs are usefull and cool.
plus, in R3 there is some optimisations by using GOBs afaik.


but for fast Gaming, I'd completely forget about gobs, and draw and 
just allow access to the AGG  C functions as commands in REBOL.
 rasterized and displayed in a window's bitmap directly.