In the debugger there is a variable called cpuusage. It was never documented in newfeatures.txt but its basic function is pretty obvious from the name. Now, it's possible that the command is supposed to work how it does. If so then I have a future improvement, and if not then I have a bug to report
My interpretation was that it is meant to show what percentage of the cpu's max power is being used by the npc. With this in mind, I set out to test how Graal performs when rendering high numbers of polygons. I wanted to see if the size of the polygons had a large effect and if overlapping polygons were all still fully drawn. So, I created the level attached below.
When using it, you can press left/right to change the square sizes and up/down to change the counts. If you play around with it for a while and monitor cpuusage as you do so, you'll probably notice these factors:
- The size of the polygons makes a difference but only a very small one.
- The number of polygons makes a much bigger difference (but is this because of more iterations in the script or more images?)
- It's very difficult to get the cpuusage above a loose maximum. For me this was somewhere around 32. My system was running at a crawl as I ramped up the poly number to 5000 but still Graal insisted it was using only 32%. To balance the test, I loaded up my 3D demo and put it to the highest setting. Immediately the cpuusage rocketed to 70+
Now, I may have drawn false conclusions, but it seems to me that the rendering times aren't included in the calculations for cpu usage. This would explain the results of the 3D test - the transformation/projection/lighting calculations in the 3D application are far more CPU-intensive than the simple drawing algorithm for the poly test, even though the latter draws more polygons.
If this is true then I would argue that it should include the rendering times too. Of all the NPCs that would push the cpu usage to dangerous heights, 90% of them are heavily graphical. Things like fireworks or minigames or suchlike. It's important for scripters of such things to know how much power they're burning so they can scale the number of images they use.
On a similar note, I propose that NPCs should be able to access their own cpuusage variable. That way they can dynamically scale their algorithms to match the situation. If somebody has a slow computer then the firework shouldn't create as many particles as if they have a superfast computer.