Originally Posted by
Gleeok
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?
) 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.
(Perhaps instead add a mask to other drawing commands, ie; translucent = 64, opaque = 128, cloakes = 256, - might be better.
Reply With Quote
