World: r3wp

was too busy looking for region / viewport / zone..

what is the viewport? I do remember it from Amiga, but don't remember 
what it was about..... kind of separate gfx space/bitmap to draw 
on?

viewport was for virtual bounded regions of the drawing screen

exactly what clip does now :) except clip doesnt set an origin

so I guess after all that I still do want a viewport ;P

altho i can be munged with a translate after teh clip i suppose

i/it

re clipping non rectangular that would be too expensive in processing 
terms.

i think AGG can probably handle non-rect clipping too.

it would be a nice effect

however... what you need is done best by just using multiple gobs. 
feel free to use hundreds of them ;)

yeah - but im worried about event hit detection - or is it a pre-composited?

events - how events are detected depends completely on you in R3

eg one face in micro vid has many gobs... and all the events for 
those gobs go to that face.

so you can have hundreds of gobs all sharing the same feel functions.

hmm, how are events tied to gobs then? With face, we had 'feel for 
that ...

or even have a single event function as event awake (you can do this 
in R2 too)

petr: by mezz code :)

and, it's fast, don't worry :)

mezz code? slow :-)

no it isn't ;)

ah, you were faster, so actually it might be fast :-)

well, if mezz code can be rebcoded :-)

basically... the event gives you the window gob and the offset in 
it. then there's a native that can map an offset inside the window 
to the gob it belongs too. so the mezz code just uses that, then 
maps the gob to the feel, eg via gob/data (user data field)

so it's not much different from what R2 does, except that you have 
full control over it.

well, how is feel tied to gob? Is it automatically done, according 
to gob offset, and even offset? What if there is many gobs under 
the event offset? Hierarchy applies? Can we have event-transparent 
gobs?

if you had a game that was operated by keys only, for example, you 
would not need to do any of this, so it's even faster than R2

event > window + offset > gob at that offset > use gob/data to get 
to face object > face/feel/on-click etc.

since gob/data can be whatever... you can map any gob to any feel, 
gob b inside gob a may map to gob c which is elsewhere.

(map to same feel as gob c)

or you put an id in gob/data and then use that to do whatever you 
want

or you don't map the offset to the gob at all, but use a bitmap to 
map the offset to something else, like max does in elixir etc.

gob being elsewhere - I remember one cool thing about QNX, back in 
1998, when they were supposed to be new AmigaOS - their Photon environment 
allowed you to insert "face" (gob) across the network - two machines 
were linked via some nodes, so for the GUI it was transparent. Window 
received the event, and that event in fact was transfered to another 
PC's window ...  was cool :-)

since you can make event! in R3... you could get event on one PC 
and then send it over to another PC and handle it there. :)

yes, but rebservices will be slow :-)

it was a joke ;-)

:P

great ingo on the events Gabriele - that will make networked games 
much more viable

event > window + offset > gob at that offset > use gob/data to get 
to face object > face/feel/on-click etc.

 - that sentence might actually help me to better understand the concept. 
 So gob is not necessarily child of face. It is completly separate 
 concept - kind of gfx node. And that node points to higher concept 
 - your face, or whatever you want, so you can do anything ....

info..

exactly.

gobs are just... graphic objects :)

that seems to be nicely flexible ... most of the time, at least for 
static things, you maybe will not need higher level complex structures, 
so it will save resources ...

at present I am re-writing all controls in draw only mode so that 
when we eventually get access to OpenGL surfaces I have less pain 
:)

faces are higher level... they have a feel, other info needed for 
eg for vid, etc.

but you don't need to use "faces" at all, you can just use gobs in 
a game for eg. and handle events your own way... maybe gob/data maps 
to the player object :)

good to know

how that gob/data points to face/feel/on-click? is there a mezz code 
in gob/data?

hmm, it would be coold, if you could post any simple actual code 
as a spoiler - we can already learn from studying :-)

wait a month (less actually... it's 4 already)