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
>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-
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted