problems with RATE ( what do you think Carl )
[1/3] from: rebol-list2::seznam::cz at: 10-Jan-2003 1:07
Hello rebol-list,
as I'm now finishing one simple game in Rebol, I've found that there
is probably something strange with the RATE property in faces.
Normal is that the script is idle and is waiting for a message from
sever. The CPU usage is almost 0. but after about 13 explosions
where there is only inserted face with rate 10 which is after 5
frames stoped by setting rate: none the CPU is almost on 50% and
increases with each explosion!
It looks that the rate events if faces are still being somehow processed
in the background! I think it must be bug in Rebol itself.
The explosion style I'm using is:
water-explosion: image with [
size: 26x25
effect: [key 6.255.0]
user-data: 1
init: [
image: first imgs-water-explosion
rate: 10
]
feel: make feel [
engage: func [f a e] [
switch a [
time [
either f/user-data < 5 [
f/user-data: f/user-data + 1
f/image: pick imgs-water-explosion f/user-data
][
rate: none
]
show f
]
down [f/user-data: 0 f/rate: 10]
]
]
]
]
The new faces are made using:
make-explosion: func[where ofs type][
insert tail where/pane make-face/styles/offset type ships-ss ofs
]
When I use just an image without rate, everything is working fine.
I've noticed this behaviour when I was making R-Box2 but the source
was too complicated to show :( and I had to stop using the RATE ):
=( Oliva David )=======================( [oliva--david--seznam--cz] )==
=( Earth/Europe/Czech_Republic/Brno )=============================
=( coords: [lat: 49.22 long: 16.67] )=============================
[2/3] from: anton:lexicon at: 10-Jan-2003 18:01
Hi Oldes,
either f/user-data < 5 [
f/user-data: f/user-data + 1
f/image: pick imgs-water-explosion f/user-data
][
rate: none
]
Shouldn't that be:
f/rate: none
?
Anton.
[3/3] from: petr:krenzelok:trz:cz at: 10-Jan-2003 8:31
Anton wrote:
>Hi Oldes,
> either f/user-data < 5 [
<<quoted lines omitted: 6>>
> f/rate: none
>?
I am not sure. Maybe it is exactly the same case as Cyphre described
almost two years ago. He wanted to have faces displayed, but events
freezed. Here's the excerpt of Cyphre's and Holger's message exchange:
---- Cyphre explains:-------
We need command which might be derived from 'hide. For example 'freeze.
This
command will behave simmilar like 'hide but without feature to hide face(s)
i.e. when you "freeze my-face" all subfaces of my-face will recursively stop
receiving of time events but will remain shown on the screen. Command with
reversed behavior would be 'unfreeze or something like that.
I know, we can recursively search the whole face-tree and
set rate to 0 or so(this would be sloow when searching more complex faces)
but why not use the part of code from 'hide command and make similar one for
example 'freeze.
Maybe this could be solved differently when creating/changing of events
will
be implemented. Then we could for example filter all time events containing
destination my-face using own functions inserted on the top of the event
tree...for example: func [face event][if all [event/type = 'time event/dest
= my-face] [return none] return event]
-------------------
What Holger replied:
Cyphre: For removing timeouts without hiding a face ? The solution is
probably something like "face/changes: 'timeout show face" in the next
version. We are already using face/changes in some other places to limit
the work show has to do, and to avoid flickering. Seems like a natural
addition.
-------------------
Of course I am not sure Oldes refers to the same problem ...
-pekr-
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted