User Tag List

Page 1 of 2 1 2 LastLast
Results 1 to 10 of 12

Thread: Duration arguments for drawing primitives.

  1. #1
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%

    Duration arguments for drawing primitives.

    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.

  2. #2
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    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.
    Last edited by Tamamo; 05-29-2015 at 05:08 PM.

  3. #3
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    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.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  4. #4
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    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?

  5. #5
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    Your missing the point of bitmaps! They don't get cleared! Draw to the bitmap once, enjoy it forever!

  6. #6
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Tamamo View Post
    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.

  7. #7
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    Except Allegro doesn't support it as far as I know. So your going to have to do what Gleeok Suggested.

  8. #8
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Tamamo View Post
    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() ?

  9. #9
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    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
    Last edited by Tamamo; 06-02-2015 at 11:25 AM.

  10. #10
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Tamamo View Post
    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.)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social