Snow!

[Gleeok]

Edit, RE PutPixel vs Circle:

I just did some testing. Although I got slow down for flake quantities > 500 (or so), I discovered something else in favour of using Circle. Although I have absolutely no idea how the primitive drawing system works in ZC, I can make a guess based on this experiment.

Essentially, I built in a way to switch between 5 PutPixels and 1 Circle. At 500 flakes (thats 500 circles vs 2500 PutPixels), half the PutPixel flakes didn't show up! I would switch between the two, and watch half the snow flakes blink in and out of existence. I am of the opinion that I used up all the Primitive drawing command buffer (or something to that effect).

So. I'm sticking with Screen->Circle for now.

Hmm, that's an interesting one....


Wow, there's a bug or something in there. I couldn't even profile putpixel because of it. This is what I used:

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();
		}
	}
}

It completely crippled the engine. I wonder why?

[lucas92]

Nice script. :)

But wouldn't it be simple to just draw falling snow combos on layer 5 instead?

[pkmnfrk]

If you count finding and setting up a separate screen, and then setting it as layer 5, and oops, it's the wrong Palette/CSet as easier than plopping down an FFC, then yes.

However, try getting dynamic looking snow out of a combo...

[pkmnfrk]

Like I alluded to, I believe that the engine does not simply draw to the given layer when you issue a command. I think it stores the command somewhere, and then executes it when it then draws the layer.

That way, drawing to layer 2 after drawing to layer 6 works "properly".

Obviously, it can only store so many commands before it pukes.

The other thing is that ZScript is orders of magnitude slower than, say, running Allegro's code directly. The overhead of drawing individual pixels way outweighs the actual drawing time. We would get similar results drawing 256x178 rectangles.

So... In other words, draw as little as possible.

Edit: The way I would solve to "drawing to layers in the wrong order" problem would be to have 6 canvasses, onto which I draw things. Then, just before showing the frame, I would blit them all together onto the back buffer.

I don't know if this would be slower, though. It would definitely use more memory...

[Gleeok]

You may be right but I remember around build 400 or so testing drawing functions by the thousands. I posted a bug thread in case there is something bottle necking the pixel rendering. Shoot first and sort out the details later is what pappy used to say.

For the meantime I'd continue to use circles and lines. lol.

[Joe123]

Seeing as all of your scripts have to be in the same file, it's not a good idea to include it at the top of every script incase it creeps into someone's file twice.

Then you're declaring all the variables in std.zh twice and obviously at that point it won't compile.

[pkmnfrk]

As an old coworker used to say, "It's six of one, and a half-dozen of the other".

If I include it, someone's going to say "I get an error: Redefinition of LW_BOMB"
If I don't, someone's going to say "I get an error: Variable not declared: LW_BOMB"

I think that std.zh should have #ifdef guards, as in C

#ifndef STD_ZH
#define STD_ZH

//...

#endif

(that's a joke)

(partially)

[Joe123]

It could be defined in the ~init script maybe

[ShadowTiger]

I'd do it up.