User talk:Jofur
Welcome to Rosetta Code! I'm Mike, and I noticed you created an account.
Some quick things you should be aware of:
| Template:Mylang | Helps you show what languages you're familiar with, and helps us become aware of skills with languages we haven't seen. |
| Category:Unimplemented tasks by language | A place to find tasks missing solutions in various languages. |
| Blogs, twitter, facebook... | We have them, and are interested in yours. |
| Special:Webchat | Logs you into #rosettacode on the Freenode IRC channel. Not usually the most active communications medium, but occasionally helpful. It's logged at http://irclog.perlgeek.de/rosettacode/today. |
| Rosetta Code:Village Pump | A general Q/A and discussion area. |
| Rosetta Code:Finances | For most of Rosetta Code's history, expenses have been paid out of my pocket. I can't afford that much longer, and so you can see the state of Rosetta Code's finances, and how you may help. If you enjoy or are excited about the site, please consider reading through it. |
Sorry for the boilerplate; it can be a bit difficult giving an individual greeting to each person. If you post information about your technical interests and background, I'll probably read it. If you already have put that kind of information on your user page, I probably already have; I'm always interested in how people do and can benefit from Rosetta Code. --Michael Mol 04:51, 27 February 2010 (UTC)
Note about Forest fire
Hello Jofur,
last night I happened to test your code for Forest fire on Linux but it wouldn't compile (with pb 4.50) because of two reasons:
1. all 3 color constants not found
- -> so I declared them with fixed values at the top
2. forbidden devision by sero
- -> DesktopFrequency(0) returns 0 as it is the 'default' setting
- (you only get real values, if the user had set up a differing frequency)
- -> so I manually set it to 60
Afterwards the program started well, but immediately the CPU encreased to over 90% ( 50% used by the windowprocess and 40% for the comp-exe). I searched very long and tested various delay statements in the main loop and/or the procedures but without success. Setting the WaitWindowEvent to 120 lowered the CPU usage down to 15% but only until the 'fire' started to show and encreased again like before.
Well - maybe you know a way to lower this strain reasonably - that would be nice. :)
Please take this as hints, 'cos I very much appreciate your and Demivecs continuous engagement supporting PureBasic on RosettaCode. best regards ~ --Vera 11:52, 14 July 2010 (UTC)
Thank you for the feed-back, I've updated the code to reduce tle CPU-load, made the tre age, and also put the constants internally. I hope that this will make it run better on Linux. --<Jofur> 14:37, 14 July 2010 (UTC)
- Thanks for the changes. It starts fine, except for #Black declaration is missing at the moment.
- Unfortunatly the CPU-load is as high as before (seems it even encreased by another 5%). Also uncommenting the delay(15) didn't change it. And testing different timeouts didn't seem to have any effect until I tried to hard-set them:
- AddWindowTimer(0,0,2000) - lowered it down to 60-70%
- AddWindowTimer(0,0,3000) - lowered it down to 40-45%
- (which is ok for me to let it run a longer time and enjoy the spreading burning)
- btw: to track the time frames is interesting to know :) ~ --Vera 17:00, 14 July 2010 (UTC)
Thank you Vera, I'm not so skilled on Linux & your feedback is very valuable. I think it is most likely the graphic drivers you use that make the Plot() demanding on your CPU, I would first recommend that you reused the With/Height secondary increased the WindowTimer or activate the Delay() with 1-2 frames delay. Could you try to run it minimized, e.g. without drawing to the screen? The only function that may use larger amounts of CPU power would be the Random() which is demanded on each object. --<Jofur> 20:33, 14 July 2010 (UTC)
- Hi Jofur,
- 1. major significant difference is to use an ImageGadget
- -> that reduced nearly all CPU-load (40%) of the windowprocess (to 3%) without increasing the exe value
- -> the framerate becomes significantly faster
- -> the colors become more intense
- 2. reducing With/Height makes about -10% per 50px/50px
- 3. increasing WindowTimer is what helps a lot (see workaround)
- 4. minimizing never made any difference to the CPU-load
- 5. activating a frame-delay in UpdateMap seems essentially effective: reduces CPU-load down to 10-20% constantly on Win (35% on Linux), indepenant of what image dimension or timeout is set to
- This time I also checked running it on WIN XP (same PC). There I had the same CPU-values - so it's not due to the graphic driver, but maybe the graphic card ... (I don't know much about grafic concerns).
- Though the achieved workaround may be fine, there is a kind of flickering (quickly showing black shadowed sections/bars on redrawing - like TV in old days) on WIN, which didn't react on any changes I made while testing. So it's another concern but much less important than the CPU question ☺