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?

[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.

[ShadowTiger]

You need to

import "std.zh"

ST =)

Oh come on. Surely that's implied by now...

Pretty much the reason for me asking and wondering, is that it wasn't implied, as if I even have to wonder why it was left out, then it's not obvious. Wouldn't it be better to include the line at the beginning of the script so this sort of conversation wouldn't happen? (lol you're dealing with an idiot here.. *sigh* ) It'd be easier just for the skilled scripter to remove the line as necessary than to leave it out and have people tripping over it because they thought the person who write the script would have included everything necessary in the first place. Non-scripters wouldn't know any better, and isn't the point of writing the scripts and showcasing them that nonscripters could just pick them up and plug them in?


Otherwise, snow looks very cool. :) I don't suppose we can change the value of D1 on the fly, mid-game?

[pkmnfrk]

Just set different FFC's to use different values. So, you can't change it one one screen, but different screens can have different values.

[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.