There seems to be something wrong with single pixel rendering. It also just quits after about 950 calls or so, not too mention it is agonizingly sloooooow. The test code:
const int LOOPS = 1;global script slot2
{
void run()
{
while(true)
{
for(int i = 0; i < LOOPS ; i++)
for(int x = 0; x < 256; x++)
for(int y = 0; y < 176; y++)
Screen->PutPixel(6, x , y, 2, 0, 0, 0, 64);
Waitframe();
}
}
}
I've been getting random lag for a bit and now that I think about it, it's about the same time as I put in pixel particles.
So, you're attempting to cover the entire screen using putpixels? Unfortunately, that's going to be slow. That's 45,056 calls right there. And it's attempting to be called 60 times every second. It's going to add some lag unless you are on a very fast system. If you are just trying to cover the screen with a solid color, use Rect instead.
Well yeah, only an idiot would try and cover the screen with a single color using single pixels. ...for non benchmarking reasons that is. :P
But I've discovered some fun facts in the process:
#1: The frame rate drop is the same as if (most likely) it has drawn every pixel to the screen, yet only draws 900 or so.
#2: All the primitive drawing functions in ZC costs about the same amount of overhead.
#3: I did apply the same script to lines, circles, etc and they all performed more or less the same. So that rules out putpixels. (I had assumed single pixel rendering would/should be faster, and quite erroneously at that.)
So not really a bug if you are a sane person, because who's going to be crazy enough to actually try to use more than one thousand calls to a putpixel.
EDIT: Ahhh, I just realized that this is the ZC implementation of a particle system, and that it's probably capped at around a thousand or so.
So even though the Zscript draws are processed the engine has no choice but to cut them. I should have realized this. >_<
Well, now that you mention it, I do believe that the drawing queue is capped around 1000 drawing operations per frame or so.