Script Drawing Improvements.

[Gleeok]

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.

[ZoriaRPG]

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.