Script Drawing Improvements.

[ZoriaRPG]

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

May as well start from scratch at that point, and probably write the core libs instead of relying on anything made by a third-party.

[Gleeok]

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.


This pretty much completes the script drawing. I don't plan on adding anything else at this point. At least not until angelscript, where we can create a new drawing API that's much, much, better.

[ZoriaRPG]

I'd just do int bitdepth on CreateBitmap(). In theory, a user could make 32b bitmaps, do alpha stuff, and render them back as 8-bit. Might make interesting effects. Might look dreadful, but Allegroshould auto downsample 32b to 8b when rendering it via a release. then we can add all those 32b only modes that you wanted.

I also noticed that in CreateBitmap, you added static sizes of min =1 max = 2048. Care to explain?why not just allocate whatever the user wishes, up to zscript numbering limitations? Won't this also conflict with the other preddefined constraints too?

I'll go over it al in more detail, and patch in the functions. If you thought Polygon was big, BitmapEx is bigger. I'd alllso sugest DrawBitmapFx() (as in 'effects'). I think that's more on the money than Ex (Experimental, or Extended?)

I'll see if I can connect all the dots and make a text file on adding functions. We absolutely need this, including for adding setter/getter stuff.

[Gleeok]

Nothing is finished yet, so anything may and probably will change slightly.

If you want 10,000 x 10,000 bitmaps at 32bit I'll leave it to you to figure out how much memory that would require/ costs/ effects on CPU cache/ etc.
Sounds like a bad idea to me, but whatever. If anyone can give me a single use case that isn't completely bat-shit dumb-dumb then that's fine with me.

[ZoriaRPG]

The @Moosh has been asking me to add allegro light table things, which we could, and may as well do, or at least discuss, at the same time. I suppose I could just pile up a full set of DrawLit*() functions, but IDK if we properly support lit drawing modes. If we cannot support light tables, then i should rip out lit modes in DrawBitmapEx().

[Tamamo]

Hold up on that, I want to add Dynamic Lighting.
That is to say. Where CSets 2-4 all have different dark levels like in LttP.

[ZoriaRPG]

Hold up on that, I want to add Dynamic Lighting.
That is to say. Where CSets 2-4 all have different dark levels like in LttP.

So...light tables are an allegro thing. It's possible to manually change them, but it's not something I'd call fun. I don't even know if they will work properly with the present set-up. It's just DRAW_LIT_SRITE or DRAW_MODE_LIT, which is a subset of DRAW_MODE_TRANS. In fact, DRAW_MODE_TRANS is supposed to support light tables, but we don't use them. (We use a simple trans table, instead.)

What exactly are you planning to do, and by what method; and does it tie into the base drawing functions?

FWIW I was just going to to slap Lit* versions of all the drawing commands in there, to support light table transparency. There's not really a better way to do it that wouldn't break piles of existing scripts. LitCombo(), LitTile(), LitLine(), LitCircle(), and so forth, all functioning as the ordinary draw command, except that they are always in DRAW_MODE_LIT/TRANS and the opacity arg is the actual lit/trans level, rather than an arbitrary value, so 0 to 256 would all be 'gradients'.

I also went ahead and simplified DrawBitmapEx() quite a bit. I added a second sub-bitmap, set to '10'--may need to change that-- to which rotation is drawn, if we're rotating things. Then, the rotated sprite is released to the first sub-bitmap, and that is rendered to the screen bitmap with one of the effects (modes, flips). That's in the file, here:

http://timelord.insomnia247.nl/zc/zc...pt_drawing.cpp

So, the first sub-bitmap is always in use. The second is only used for rotation. I hope this makes sense.

Polygon is also in there, but it lacks rotation maths, if we want to automate those somehow at all. I'm sort of at a loss for a good way to do that, or do an outline mode, because there's no way to predict the number of vertices: It technically supports up to 214747 / 2 angles per shape. There's just no realistic way to rotate all of those, that comes to mind, and forget doing an outline mode with that many variables. If people want an outline of their polygon, they can draw a second polygon that is slightly smaller, in colour 0.

If they want it to rotate, they should probably just adjust the vertices in the array to make it rotate manually, or draw it to a bitmap and rotate the bitmap. That would be the easiest solution.

The temporary 'lit' functions, that at present do nothing, are here: http://timelord.insomnia247.nl/zc/zc...rawing_lit.cpp