On 5 April 2011 03:51, James Paige <[email protected]> wrote:
> On Mon, Apr 04, 2011 at 08:29:14AM -0700, 
> [email protected] wrote:
>> http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=886
>>
>> Ralph Versteegen <[email protected]> changed:
>>
>>            What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>              Status|NEW                         |RESOLVED
>>          Resolution|                            |FIXED
>>             Summary|Random high CPU usage which |Nightmare on Elmo Street is
>>                    |persists until you quit the |slooooooow
>>                    |game                        |
>>
>> --- Comment #1 from Ralph Versteegen <[email protected]> 2011-04-04 
>> 08:29:14 PDT ---
>> Opps, looks like I imagined seeing this in Dragon Bustier. It is a NoES bug: 
>> on
>> closer inspection, the script running on a timer is actually loading an enemy
>> sprite over and over! It's really bizarre how the game runs fine and then
>> suddenly the frame rate plummets. And how J_Taylor never noticed this.
>>
>
> It makes sense to me that it takes some time for this to slow things
> down. Every time a new copy of the sprite is loaded, the old slice
> is effectively leaked, so sooner or later there are too many of them,
> and the swapping starts.

No swapping takes place; the memory usage wasn't increasing
significantly. The lag must have been just due to drawing thousands of
identical sprites on the screen, at the same spot.

> It seems to be a fairly common mistake for new scripters who are
> cycle of a
> loop.
>
> I think some documentation improvements could help this... But it is
> hard for me to know exactly what to say.

Maybe it could also be automatically detected. Such as: at a couple
check points, say when 500 and when 2000 slices are loaded for the
first time, run a check to see whether  large numbers of them have
identical position, parent and extra data, and if so raise a warning.
We can add a bit to disable the warning, which it might be wise to
default to on.



> ---
> James
> _______________________________________________
> Ohrrpgce mailing list
> [email protected]
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Reply via email to