AltME groups: search

found a way to brute force it. not pretty, though...

With the above code on Linux I see this:

move 77x78 ; Final move of mouse to a stop, then I wait a short time...
down 77x78 ; <- I click.
up 77x78 ; <- I release, and I wait...
move 77x79 ; I begin moving mouse again.

If I remember correctly, Windows also inserts a 'move event before 
the 'down, doesn't it?

but in both cases it shouldn't be a problem IMO. Those events just 
goes thru your handler without any real action and doesn't look like 
a performance hit at all.

By the way, the "no" real handling of rate in window detect  that 
Maxim let me understand why I was unable to slow down the "Splascreen" 
demo as it use the window feel, not a face feel.

is there any known way to make rebol spontaneously quit? I've run 
into a case where it just quits, when I focus a field in the VID 
Extension Kit, but I have no clue what does it, although I can reproduce 
it every time.

under OSX a segfault is produced.

are you using a popup?

Maxim, no a VIEW window

very strange. especially on a focus event.

this is one case of this 'feature':
a: does [if error? try [a][a]]

a print object statement can also cause the interpreter to bust its 
stack.

I think I figured it out... I have created a pane of faces manually 
where one is focused. Then I decide to remove that pane and build 
a new one, and then focus a new face in that new pane. But my focus 
calls unfocus first and wants to perform a focal-face on a face that 
doesn't belong anywhere => crash.

wants to perform a SHOW on a focal-face

IMO Looks more like a View(text related) bug.

well, the face that SHOW is trying to show remains in memory, possibly 
with a reference to a parent-face that no longer exists. what exactly 
makes SHOW go boom, I'm not sure.

There is a strange auto-complete (tab key) problem on View 2.7.7 
console,
connection: context [a: 1 b: 2]
test: context [a: 1 b: 2]
when you type conn then press tab key it writes just "connected?"
but its ok for test. no auto complete for "usage" function also.

there's a built-in function "connected?" which lexicographically 
sorts before "connection", so it's completed first

It's not the fact that it's a user-defined word. It must be something 
else. It looks to me like it's because the word 'Connection (with 
capital 'C') already exists in system/words on startup. Defining 
'connection in the global context doesn't change the capitalisation 
on the existing symbol. So I think the completion function is case-sensitive 
Try in the console:
>> Abacus: 1
>> abalone: 2
>> aba
and press Tab Tab.

Also, I thought there was a Draw group, but no longer see it.  If 
it was made private, can I be re-added?

There is no private grouop for Draw (unless it has an obscure name 
that I do not recognise).
Perhaps time to start a Draw group?

file a bug report for linux

i think that 2.7.7 crashes for most DRAW commands on Linux. at this 
point we have enough reports, it's worth making a ticket.

is there a programmtically solution to 're-center' the toplevel-face 
on the os-desktop after a face reseize?

There is an AGG group, but there may be cause for a new "Draw dialect" 
group.

how to detect  - which face - is envoking an event within a global 
insert-event-func?

windows are passed in the event/face, that is sure... so if resize 
events occur only for windows, you should be pretty safe in assuming 
that in this case the event/face is always a window.

one thing though.  I've discovered that at low-level (view port wake 
event) resizing generates one event per mouse move.   


it sends all of them AFTER you finished resizing (pretty dumb) so 
you may end up with up to a 100 resizing events which are all, basically 
useless except for the last one.


I do not know if they are filtered out within the do-events (and 
thus within the event-func) but you should print out something to 
see if this is the case.

yes, a probe looks like a data dump here. not like a standard face 
spec.

/text seems like another identifier. 0is there a unique identifier 
I can set for each face? (e.g. a hidden tag field)

so at least I can use the /text so make a simple switch identifier...

ahh...ok. just found /data wihich is user-defined. will use this 
to store a simple windows-indicator there.

you don't have to.   the event/face IS a window... everytime.

I'm building a little working example... give me 2 minutes

there are MANY ways to do this, and depending on the surrounding 
code you have this may or may not be optimal, but this should give 
you an idea of what is going on.

rebol [
	title: "resizing example"
]


insert-event-func 	[
    switch event/type [
        resize      	[
			if in event/face 'on-resize [
				event/face/on-resize
			]
		]
		down 		[
			; always a window title, even if clicking on a button.
			probe event/face/text
		]  
    ]
    event
]


view/new/options layout [button "nope"] 'resize

win: layout [
	button "ok"
]

win: make win [
	on-resize: func [
		/local subface
	][
		; window size is already set at this point.
		subface: pane/1
		subface/offset: (size / 2) - (subface/size / 2)
		show self
	]
	offset/x: 200
]

view/new/options win 'resize


do-events

I have a weird question, decode-url function uses parse-url function. 
But there is no parse-url at all?? even if I copy & paste decode-url 
function and create another function it gives error "** Script Error: 
parse-url has no value". any idea?

Endo, decode-url uses parse-url from a different context. That's 
why you can't see the parse-url function.

Ohh. I see. Thanks a lot.

yes right.

oh god, there is url-rules block in parse-url function which is also 
hidden :) I think I should write a function to get the source of 
a word! inside the context of the word.

ok seems I missed a detail in reading the thread.

A simple alternative
editor form    system

a letter on the screen. Should it be accessible as a gob? Having 
a size, offset, color, etc...

It's probably a stupid idea, but I remember that gobs were intended 
to be used in the thousands on the screen for games and the like.

that depends on what you need it for. in principle you can treat 
a single letter as a gob, by having one char in the text body.

I don't think it's a stupid idea.

Would a character per gob simplify things?

only with a single gob, though. if you really need to edit across 
multiple gobs, I don't see why the gob text bodies can't be chained 
together somehow.

It would be a draw block wouldn't it?

One char per gob: that is simple, but maybe you can increase rendering 
speed by creating one gob per section of text which has a consistent 
font-size and style etc.

I control-c'd a bit of rebol source from a web page ... which I wanted 
to edit before I pasted it into the console

Normally I would open up the rebol editor, and paste code into it, 
save it to a disk file and then run it.  And wondering why I always 
need rebol [ ] in the header ...

With R3 you can do clipboard:// even if the code doesn't have a header 
:)

btw, I'm working on getting this kind of collision detection code 
working under REBOL  :-) 


in fact, I also want to support rotated shapes, which makes it quite 
a bit more complex to handle generically, but I've done enough research 
on the subject to have a good feel on how to get it to work.


I'm hashing out all the maths to do it, and will integrate this into 
my little game engine.

I think I just found an interesting way to optimise AGG on R2  :-D 


I'm doing Animation tests with some complex vector & projection math 
(rotating/translating/projecting shapes using floating point math 
exclusively).


using AGG and a non-standard manual management of the window, I'm 
acheiving 0% CPU at 30fps FULL SCREEN (1440x900)

on a crappy 1.5GHz core2 duo.

Sounds like a great achievement Max, keep up the great work and post 
some samples or animations or something so we can see your work.

when the collision stuff is finished, later this evening, I'll prebol 
a little script for you guys to test and have fun with.  :-D

the raster being a pre-allocated image! which I use with the  'draw 
  function.

cool thing is that if we don't blank the bg manually, we actually 
get a persistent buffer, and can do things like winamp visualizers 
easily.

image processing requires a lot of CPU juice.


 we have to render the AGG, use the bitmap in a face, apply an effect 
 on it, and then re-create a new bitmap out of it.  we aren't just 
 drawing/effecting over and over the same image memory area but creating 
 a new image at every refresh.


it would be nice if there was a complement to the 'draw function 
called 'effect.  maybe its in R3, or maybe it should be.

sure it's slow - especially at today's fullscreen resolutions - that's 
a lot of pixels to process per second - maybe a view extension for 
offloading some of that on the GPU is in the works

wrt console I/O killing gfx speed.... with my new high-performance 
chrono lib, here are the results for printing... compared to a single 
(average) call to sine. 

[print ""]
0:00:00.000792139

[prin "."]
0:00:00.000168666

[sine 45]
0:00:00.000001014

updated the animated vector projection tests script:

-uses the chrono library for more precise time management.

-now has option to prevent clearing the image at each refresh (feedback), 
press enter

-you can also manually increase and decrease max frame-rate on mouse 
drag using arrows.


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

on my system, I can easily go up to a 100fps before feeling lag.

I also see current rate typically of 32fps/ current (max) rate shows 
as 40.00000000001 (plus or minus a zero)

hmm, I'm guessing it's not a system dependent limit - hard to believe 
that we have exactly the same specs

Not sure if I am doing something wrong, but I simply get a black 
screen when trying the latest update.  I was able to view the initial 
demo.  Tried view 2.7.6.3.1 and 2.7.7.3.1.

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 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.

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.

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 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...

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"
]

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]
		]
	]

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).

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.

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.

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.

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.

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.

Max - so far, all AGG functions are mapped just like commands, nothing 
more. Cyphre is working on a dialect right now, but it is not in-there. 
Each dialect keyword then maps to such a function - or how do you 
think the REBOL to AGG mapping is done?

for some reason, the text command was exported, and when I tried 
to use it, it just crashed R3.


the whole system requires you to tell it where to draw stuff. all 
the C code  expects either a gob! or a low level AGG graphics object.

ah, I understand now ... I thought that each low level function is 
directly mapped via a command ...

so either there is a little magic trick to set a gob! as the current 
default rendering target, or there isn't any way to do this yet.

my use cases tend to be on the fringes  ;-)


but I don't want to impede their plan right now.  i can actually 
do (some/all?) of this work myself, since it would effectively be 
a completely separate rendering process than /view, I woudn't be 
competing with their efforts, it could just be an additional extension 
which uses the same AGG code, but with a different REBOL interface

Would you need a vector! type for your work? IIRC vectors are still 
not finished in R3, no? Dunno if extensions support them ....

MAJOR milestone for Game kit.


test app updated and includes multiple shape collisions and propagation. 
 quite fun  :-)

also: press g to view spatial sorting grid, its a bit mesmerizing 
to see


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

I also want to try adding rotational collision response... i.e. push 
a polygon, and it twists as well as moves.

if you do a quick drag-move, it can jump over the element, instead 
of pushing it forward .... is that a bug, or na intention?

I can see a way nicer (well, if performance won't be an issue) alternative 
to Processing being built on top of something like this. With dialecting 
and extensions to interface to external hardware, it could be a killer 
app for the interactive/performance art community.

http://www.processing.org/

yep, this is all built as a set of generic libs you can use in any 
app.


 the actual application-specific code part of this test (if you exclude 
 the event loop, which would be part of a generic toolkit) is 1kb 
 of code (~ 50 lines).

Hi!


Is there a good way to draw an image with an alpha channel? In the 
example below, I would expect a green outlined circle with a transparent 
background so I could composite it over the red box in the layout 
(for instance). However, I get solid (and very un-transparent) black.


    x: draw 512x512 [pen green line-width 3 fill-pen blue circle 256x256 
    200]
    view layout/tight [box 512x512 red  at 0x0 image x]

Any ideas? Thanks very much!