Duration arguments for drawing primitives.

[ZoriaRPG]

I suggest adding int dur to all drawing primitives, so that it's possible to draw them at a desired position, with a duration, without a for loop that puts extra waitframes in a global active script.

[Tamamo]

I'll take a look first, but I'm not even sure if that is even needed if you use bitmaps. Hang on.

edit: Yeah, if you draw everything to a bitmap first and use a counter for your duration argument in a if statement you'll be fine.

[Gleeok]

I think he means to draw primitives similar to a particle engine (which zc does not have). Closest thing right now would be to create a weapon with a DeadState and without collision so it disappears after so many frames.

[ZoriaRPG]

I think he means to draw primitives similar to a particle engine (which zc does not have). Closest thing right now would be to create a weapon with a DeadState and without collision so it disappears after so many frames.

That would also be interesting, but nay, I was requesting that drawing command be expanded to run for as many frames as specified in dur, without needing to give them separate waitframes. I know there are ways to circumvent that, they're just un-tidy. A basic example, would be to render a rect for 300 frames, and draw text on it for the same duration, directly from the draw commands. In so doing, you could avoid messy for loops, or timed if statements.

The problem, is that you'd need to support drawing/rendering for more than one frame internally. Essentially, the draw command would need to create drawn objects in the internal code, that continue to exist for the specified duration. I also should note, that it would need a bool remain, so that it stays indefinitely (until otherwise invalidated by something), because that could also be useful for making game elements. I guess the problem with that latter part, is how to invalidate it, because there's no way to point to the drawn construct in ZScript; but aye, a timed value would be nice.

For the record, you don't need to draw first to a bitmap, to use a counter in an if statement. You can draw the same object every frame directly from the if statement, as-is. I think the benefit of a bitmap, would be what...lack of possible flicker, and the option to apply rendering commands?

[Tamamo]

Your missing the point of bitmaps! They don't get cleared! Draw to the bitmap once, enjoy it forever!

[ZoriaRPG]

Your missing the point of bitmaps! They don't get cleared! Draw to the bitmap once, enjoy it forever!

Is it legal to do Screen->Bitmap directly, and have it persist in the user screen space, instead of Screen->DrawBitmap for one frame; or am I wrong in believing that Screen->DrawBitmap is for one frame only, as all other draw commands?

I don;t need to preserve the image perpetually, without changing it here; well, I do, for other things; but they will also need updating each frame, with the exception of pure decoration.

If so, I'm mistaken, I would indeed like to know about it. I also wouldn't mind clarification on the mask property, so that I can define the transparent areas. I believe that's the point here, but I'm not sure how to make a permanent line, or single char, and mask it so that I can overlay it with transparency. If Screen->Bitmap is a legal instruction, I'd appreciate a list of its args, as it isn't in std.txt, or zscript.txt. If there's any moderate to advanced bitmap tutorial for ZScript, I should explore that.

P.S. That doesn't invalidate this future-feature request, as durations on draw commands are inherently useful things, and would make it possible for draw command to behave like short lived visual FFCs.

[Tamamo]

Except Allegro doesn't support it as far as I know. So your going to have to do what Gleeok Suggested.

[ZoriaRPG]

Except Allegro doesn't support it as far as I know. So your going to have to do what Gleeok Suggested.

What he suggested, does not apply. Created weapons aren't lines, or shapes of any defined size, or scale.

What I'll have to do, and am doing, is the only way that's feasible, and is in line with what I discussed with Saffith on this matter...and of course Allegro would support drawing for multiple frames. Any, and all game objects are drawn for consecutive frames: This would need to pass a duration to the internal drawing engine, and render the same object every frame, for x frames. I don't believe for a microsecond that it's beyond the capabilities of the engine; but I do believe that no-one has ever suggested to implement it.

We're talking about lines, chars, tiles, and polygons; not particles. (I already have a way to fake particles.)

I know that the internal primatives don;t have this arg, but it should be possible to re-draw it for X frames, by issuing the internal draw command every frame, internally. I would think this would allow for it to work, without needing to manually add Waitframe() instructions in the command on the ZScript size, so that it doesn;t wreck timing.

One other thing: Allegro 4 has void Polygon, but ZScript doesn't, and could use it.

I note that you didn't see, or didn't care about my concerns over masking, and transparency for bitmap objects too; or my question regarding Screen->DrawBitmap, as to whether it follows the same duration rules as other draw commands. What colour is masked out with mask_blit when I enable mask on a bitmap in ZScript? Is it just colour 0?

---

Aren't drawn shapes internally removed at Waitframe() with release_screen() ?

[Tamamo]

1. About the duration primitives. If ZC was sane then it would actually be possible. It'll have to wait till the rewrite.

2. Color 0 is masked out yes.

3. Yes.

4. Yeah we should get off your asses and add Screen->Polygon already. :p

[ZoriaRPG]

1. About the duration primitives. If ZC was sane then it would actually be possible. It'll have to wait till the rewrite.

2. Color 0 is masked out yes.

3. Yes.

4. Yeah we should get off your asses and add Screen->Polygon already. :p

Good, good. I was suggesting it for 2.60, which as I understand, is an least a moderate engine re-write. I don;t expect anyone to shoe-horn it it, if it's obscenely tedious.

Screen->Polygon should just be a direct pass to the void Polygon function of Allegro, so duplicating the way that Screen->Triangle works, should do for that.

Are bitmaps drawn directly on-screen static? I know that off-screen bitmaps are static, and drawn on-screen with Screen->DrawBitmap. Is there a sane way to use bitmaps over the user space, directly?

(I suppose I could define a bitmap of the same proportions as the screen space, draw to it, and call it with Screen->DrawBitmap every frame, but that just seems silly.)

[Binx]

Yes! Polygons please! It'll make drawing certain things for my quest a billion times easier.

[Tamamo]

Me and gleeok will talk tonight if we get the chance.