User Tag List

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

Thread: Script Drawing Improvements.

  1. #1
    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%

    Script Drawing Improvements.

    [edit] Added the following:


    Screen->SetRenderSource(source, x, y, w, h);
    Screen->CreateBitmap(w, h, depth = 8);
    Screen->DrawBitmapEx(layer, bitmap, x, y, w, h, tx, ty, tw, th, mask, bool, bool);
    Screen->Polygon(...);
    Screen->DrawPixelArray(layer, count, []x, []y, []colors);
    Screen->DrawTileArray(layer, count, []tiles, []x, []y, []colors);
    Screen->DrawComboArray(layer, count, []combos, []x, []y, []colors);

    TODO:
    Screen->Polygon(...);
    Screen->DrawBitmapEx(...);
    int opacity arguments to Tile() and Combo() will accept 128, or 256 to draw a cloaked tile or combo.



    Post anything I'm missing here. It's better just to get everything in one go, so I'm making super duper sure berforhand. :) *cough* I'm lazy *cough*

    Likely candidates so far:

    [1] Screen->DrawBitmapEx(...);
    [2] Screen->SetRenderSource(source, x, y, w, h);
    [3] Screen->Polygon(...);
    [4] Screen->DrawPixelArray([]x, []y, []colors, int count);

    [1] Most common bitching about bitmaps is the way allegro does translucency and the fact that drawing inverted things is all the rage with the kiddies these days.... fair enough. Let's make one specially designed for those cases then.
    [2] Instead of drawing from tiles or combos with other 3D (Quad, Triangle, etc..) drawing commands you could draw from bitmaps instead. Usage:
    Code:
    Screen->SetRenderSource(RT_BITMAP1, ...);
    Screen->Quad(...);
    Screen->SetRenderSource(RT_DEFAULT);
    [3] Not sure really... It's over 9000!!! (ZoriaRPG was going to test this one)
    [4] Because PutPixel is slow and crappy, and if you ever want to draw single pixels then you probably want to draw a lot more than 1000 of them.

    Others (?) XOR drawing mode. ZoriaRPG expressed interest in this, but I'm a bit skeptical on the usefulness (Not too mention the testing! Oh noes, the tesing! ) Though, it could be easy enough to support other drawing modes by introducing a simple mask to opacity. [Example: DrawSomething(x, y, 128 | DM_XOR] ..or some other non-intrusive thing.

    [5] Screen->CreateBitmap(w, h); // let users specify the size of bitmaps.
    [6] Screen->DrawCloakedTile/Combo(); // Draw invisible stuff. ...Confused yet? (Perhaps instead add a mask to other drawing commands, ie; translucent = 64, opaque = 128, cloakes = 256, - might be better.
    Last edited by Gleeok; 03-30-2016 at 02:38 AM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  2. #2
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,430
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.57%
    Quote Originally Posted by Gleeok View Post
    Others (?) XOR drawing mode. ZoriaRPG expressed interest in this, but I'm a bit skeptical on the usefulness (Not too mention the testing! Oh noes, the tesing! ) Though, it could be easy enough to support other drawing modes by introducing a simple mask to opacity. [Example: DrawSomething(x, y, 128 | DM_XOR] ..or some other non-intrusive thing.
    I've been opposed to XOR drawing for two reasons.
    One, no one asking for it seems to understand what it would actually do. It doesn't simply cut shapes out, and it wouldn't erase upper layers. People say they want it for LttP-style dark rooms, and it simply isn't appropriate for that.
    Two, Allegro's implementation is problematic. It doesn't XOR the colors; it XORs the palette indices. That makes it too unpredictable to be useful at all, and it would be very difficult to support in the future.

    I would like to see additive and subtractive drawing modes, but adding those in 8-bit color would mean keeping two more translucency tables. I don't think it's worth the added effort and overhead.

  3. #3
    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%
    Quote Originally Posted by Saffith View Post
    I've been opposed to XOR drawing for two reasons.
    One, no one asking for it seems to understand what it would actually do. It doesn't simply cut shapes out, and it wouldn't erase upper layers. People say they want it for LttP-style dark rooms, and it simply isn't appropriate for that.
    Two, Allegro's implementation is problematic. It doesn't XOR the colors; it XORs the palette indices. That makes it too unpredictable to be useful at all, and it would be very difficult to support in the future.

    I would like to see additive and subtractive drawing modes, but adding those in 8-bit color would mean keeping two more translucency tables. I don't think it's worth the added effort and overhead.
    One of the many reasons I hate Allegro and think we should get rid of it entirely.
    It's possible to create LttP-style dark rooms with bitmap drawing thankfully, I've already crossed that bridge before.

  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%
    As far as I'm aware, I've solved the translucent drawing and 'cut-outs' without XOR drawing. It needs a build, and some testing.
    I have, ready and prepared, a variation of DrawBitmap() that is set to roll out as DrawSprite(), or whatever you intend to call it, that has settings for all the Allegro 4 sprite modes. I did not yet add this to the bytecode, or elsewhere, but I planned to do this in the next build.

    Xor would be interesting for a handful of visual effects, but I agree that the problems it presents versus the needs/desires of other people that care about it, make it infeasible to implement, and to support. For the record, I wanted to do overlapping 'additive' drawing, that Xor'd out the overlapped areas, but drew the non-overlapping areas.

    If we do get sprite effects in here as planned, there's no reason no to allow that sort of thing with the understanding that it only works properly on bitmap layers, and not when rendered tot he screen; but if you expect to move to ag5, at some future point, you'll need to figure out how to handle replicating the effect. I personally have no concern with ag5, at present, and no intention to move to it as things stand.

    SetRenderSource() would be interesting enough.

    I'm pretty much in favour of an expansion of the pasudo-3D functions. I've done that partly, and have solutions for handling it without massive rewriting. Polygon() might be usable. I'm not entirely sure. I worked on it in August, and when I saw that it wasn't going to be included in 2.50.2, I stopped dead. Now I don't recall where I left off, but I sent the files to both of you at the time. I might just start from scratch.

    I think I was unsure how best to read the array values passed into the ZScript params with it;and I never did a non-filled version, as that would be solved with drawing the shape again in colour 0.

    On that topic,what I sense that people want to do, is to exclude out objects drawn to the screen in colour 0 on a given layer. That is, if you draw a rect in colour 13, and draw a rect inside of it in colour 0, it would slice out that portion; just as it would on a bitmap layer. I have no idea how to accomplish that at present, but I do know how to achieve this goal with bitmap usage, as I stated above.

    Regarding bytecode, and other word table concerns: Does anyone care if I use some of the present, 'reserved' fields for this? I'd rather do that than expand the table, and that's why they were reserved, in theory.

    One thing that is absent here, is a much larger bitmap area. I think CreateBitmap(int ID, int width, int height, int cdepth, [...]) would be the most useful command, in which an area can be defined as a specific size, and then selected as a target.

    Additional drawing layers above 7 would also be interesting, but I've no examined the difficulty.

    I'll remind everyone that all the other interesting ag4 drawing can only be accomplished in 32b colour depths, but it _may_ be possible to create 32b bitmaps, do things such as alpha layers, ans then render them to the screen in 8-bit mode. The results, I can't guarantee.

    Some way to save bitmaps tot he quest file, such as StoreBitmap() or SaveBitmap() would be useful as well. Ideally, this would work in cojunctiom with CreateBitmap() using the ID specified on creation; and would allow preconfiguring graphics that the author intends to reuse, without needing to set them up on each quest load. They can be configured with ~Init or something, and then called instantly.

    Another (infrequent, but multiple-instance) user request has been an increased number of draws per frame. I haven't looked into that at all.

    I should probably pull the script drawing sections from the to-do list and expand on them here.

  5. #5
    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%
    Quote Originally Posted by ZoriaRPG View Post

    One thing that is absent here, is a much larger bitmap area. I think CreateBitmap(int ID, int width, int height, int cdepth, [...]) would be the most useful command, in which an area can be defined as a specific size, and then selected as a target.
    Ha! You've just been ninja'd.

    The other things are good, but not part of this go. I do like the idea of loading and storing bitmaps into the quest file itself through the editor, possibly even multiple tile pages, etc., but that's for another day.

    The limit on draws per frame can be fixed without much problem, but it requires me to rewrite the current system. It's always been on my todo radar, but it's very low priority.

    I only mentioned Polygon because you said you had it partially done. I can add the bytecode and array handling for it, then you can just see how I do it.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  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 Gleeok View Post
    Ha! You've just been ninja'd.

    The other things are good, but not part of this go. I do like the idea of loading and storing bitmaps into the quest file itself through the editor, possibly even multiple tile pages, etc., but that's for another day.

    The limit on draws per frame can be fixed without much problem, but it requires me to rewrite the current system. It's always been on my todo radar, but it's very low priority.

    I only mentioned Polygon because you said you had it partially done. I can add the bytecode and array handling for it, then you can just see how I do it.
    I do have it partially done. In fact, I have two distinct versions of it. I'm pretty sure that I sent both of them to you... I set it aside when it seemed as if it wasn't going to happen.

    If you want to do the bytecode and params, and a send me the revised file, or some notes on what you changed to add a new function, that would be very useful; as at present, all that I know if based on presumptions on how to properly add things. If it proves what I'm doing is right, fantastic. Otherwise, I can correct any issues, and add the other components at the same time.

    Some code comments on how you handle passing the ZScript arrays should suffice for that. I still do not know if there is a way to allow the user to pass either an entire array via its pointer, or a specific variable value/index value, to the same param, and detect which was passed. Knowing this would be very useful to some of the plans.

    I haven;t added any of the recent changes to a git fork or anything like that; as GitHub is being prissy, and giving me errors when i try to merge them into the present fork... They are all on one of the private servers though, so I will link you to them, if you want to have a look. I've been doing some things with the parser itself, that I believe can easily go into the next build, but they may need tinkering.

    DrawSprite() with params for pretty much all the modes (e.g. DrawBitmapEx(), whatever 'Ex' is supposed to mean) is complete enough for me to finish in twenty minutes and send over, but if you send me the bytecode changes for Polygon(), I can use that to do all of the work needed to implement it.

    I'm going to mention that I somewhat favour DrawSprite(0 for this, as that is how allegro works, but I see the concern with the word 'sprite' as a user-end confusion/conflict. I think we can come up with a better name, unless you know a way to use the number of params to call a different internal function.

    That is, DrawBitmap() with more params than now, calls do_drawaspriter(), but with the present number of params, calls do_drawbitmapr(). That would be ideal, as it would function as a simple overload, and be generally transparent to the user.

    P.S. Where was I ninja'd here? Oh, you edited the top post. I see.

    So, aye, option [5] sounds good. I'd consider the args that I specified, though, so that we can implement other colour depths in the future. I'm pretty sure that allegro will translate downward, after applying effects to a 32b bitmap, when copying it to an 8-bit bitmap in memory. That would allow 'using' advanced editing, before rendering it.

    Also, my modifications to the pseduo-3d functions go hand-in-hand with all of this, and should be in the next version. The changes allow using a bitmap as a drawing texture, and would be very useful for advanced visual effects. Again, a param overload would be good for them, if possible.

    Here's a copy from the list:

    ZScript::Script Drawing
    • Add additional routines for bitmap handling, including translucent rendering to screen.
    • Increase bitmap area to a very large size (possibly for advanced panning, or scrolling)
    • Add missing drawing functions, such as Polygon() and Polygon3d()
    • Allow setting a bitmap as a texture to a drawn object.


    3/4 are at least partially done, or mostly implemented. I didn't touch making larger bitmaps...yet; nor did I handle the 3D version of Polygon(), although that shouldn't be too much of a pain in the arse once Polygon() is implemented.

    Let me know what files you want, or need.

    Also...I need some documentation on how you changed DrawBitmap() between 2.50.0/1 and 2.50.2, that changed the offset bug, so that I can supply a version-reading workaround for the users that need one. I should be able to do that simply enough, in an automatic fashion, but I have no idea what you changed, and I do not believe I have the version of the codebase prior to your changes.

  7. #7
    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%
    Wait until I get to it and I'll set those up for you. Just tell me the parameters your DrawSprite takes.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  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 Gleeok View Post
    Wait until I get to it and I'll set those up for you. Just tell me the parameters your DrawSprite takes.
    Code:
    void do_drawspriter(BITMAP *bmp, int *sdci, int xoffset, int yoffset)
    {
    	//sdci[1]=layer
    	//sdci[2]=bitmap
    	//sdci[3]=sourcex
    	//sdci[4]=sourcey
    	//sdci[5]=sourcew
    	//sdci[6]=sourceh
    	//sdci[7]=destx
    	//sdci[8]=desty
    	//sdci[9]=destw
    	//sdci[10]=desth
    	//sdci[11]=int rot
    	//sdci[12]=bool mask
            //scdi[13]=bool lit
            //scdi[14]=bool trans
            //scdi[15]=bool stretch
            //scdi[16]=int flip (none, horiz, vert, both)
    I'm also going to suggest doing a poll for the function name on Pure, and a discussion here, to determine if people want it to be called DrawSprite(), or something else. We can put together some suggestions...unless it is possible to choose from multiple internal funcntions (in this case, do_drawbitmapr() and do_drawspriter() based on the number of parameters passed to DrawBitmap() in ZScript.

    Meaning, if 12 params are passed to DrawBitmap(...), the parser will compile as the ZASM word BITMAPR, but if 16 params are passed to DrawBitmap(...), it will compile to SPRITER (or DRAWSPRITER ... I think that I prefer the latter).

    As a note, I'd like to explain why i want to use an overload for this:

    I wish to use DrawBitmap() as a single function, and use these 16 params as the prime instruction for 2.55/2.60; bit I want to ensure that older scripts do not lose compatibility. If we can make that work, it'll avoid any user confusion based on the naming, we won't have two similar functions with different names, and all scripts made to use the prior function will still compile; but we can effectively deprecate it.

    Otherwise, we have two functions in ZScript, with different names, that do the same thing, except that one will be more limited, and it happens to be the one with the better function name. I know that the instruction index includes a 'number of parameters' entry, so is it possible to use this to determine the output, or is that params value only valid for the ZASM side of things?

    It'd help to have a little more documentation on how to modify the table, and so forth, so that I can patch that into my docs. I've done what I can, but some of it is guesswork, and I'd rather have the straight dope on something this important. Do you think you can write up a quick 'how to' on adding a function, as a step-by-step process; and on how to set up reading it; so that I can add it to the docs?

  9. #9
    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%
    If I've learned anything from naming functions from game programming it's don't be arbitrarily over generic because it just ends up being confusing. Sprite really isn't a good name because it's not a sprite. It's a function that draws a rectangle from a memory bitmap with some params in a purely procedural context. What if, later on, scripts can actually create sprite objects. What do we call the function that draws that? Then DrawSprite() draws bitmap stuff and DrawObjectGrapghicDataInstance() draws sprites. See what I mean?

    I think you're thinking about this too hard. A separate function is fine because it fundamentally does something different, and, also to retain backwards compatibility with 2.50. Also, I'm not going anywhere near trying to hack in some weird call stack replacement thing. I'd prefer to not have to worry about corrupting peoples scripts in the first place. :)
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  10. #10
    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%
    @Gleeok @Saffith
    I'd hate to be the asshole to ask this question but..

    How much of a pain in the ass would it be to just replace Allegro 4? Allegro 4 needs to be removed entirely it's visa has expired you both know that. Sure we'll break ZC all the way to it's core and have to fix it back up again. It would be a monster project and AGN might even need to find another dedicated ZC Dev who knows. But it's not the 90s anymore damn it. We've been using Allegro 4 since the beginning. Don't you think it's time we move on to a more modern library.

    Allegro 5 does not count.

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