PDA

View Full Version : ZC 2.future Codebase Changes (Log)



ZoriaRPG
02-16-2016, 06:42 AM
Logging some codebase changes here. These apply mostly to 2.xx, but they may also be used in the present (ZScript-enabled) builds of ZC3.x.

script_drawing.cpp

Added routines to do_drawbitmapr() that allow using Allegro sprites for effects:

The present 'rotation' argument is now used for the following: Enable transparency, rotation.

Works as follows:


if rot is 0, it draws opaque, but does not rotate.
if rot is between -360 and 360, it draws opaque, and rotates normally.
if rot is either between 361 and 720, or between -361 and -720 it rotates, but is transparent
if rot is outside these limits, it draws a transparent bitmap with no rotation.



Did initial work on do_drawquadr() to allow mapping a bitmap as a texture, in addition to tiles/combos.
Works as follows: A value above MAX_TILES (65519) will use a bitmap as a texture. At present, how this is to work is undefined, however I plan to use the normal RT_* in addition to a constant TEX_BITMAP = 65520 to point to the bitmap in question.
Xor mode drawing, with extremely limited support, using OP_XOR to all drawing prims. This works with bitmaps perfectly well, but not with direct screen drawing. I do not have a personal desire to muck with the colour table to fix it, but perhaps Dimentio does. Either way, with the changes to do_drawbitmapr(), it should be feasible to use Xor drawing reliably.

I plan to further expand do_drawbitmapr(), but I need to determine what other sprite effects to use. Until i test the latest modifications, I'll hold off on any further changes.


Initial work on Polygon() / POLYGON*, but not Polygon3d() / POLYGON3D*
These need ZASM side instructions in the bytecode, and other things, to be enabled. I believe that I know how to do this, but at present this is not a certainty.
I initially did this before the release of 2.50.2, but Saffith did not want to add a new function, so it'll go into 2.

Parser/Lexer:

Initial modifications to allow some global symbols.

Char ? will be added to symbols for IDENTIFIER, to allow var, and function names such as ?Walking()
Char ? also needs to be added to lexical errors if it is a single char, to prevent accidental use where char / is desired.
Char ^^ added as symbol LOGICALXOR
The LOGICALXOR component is not implemented, but I added it to the .lpp file as a valid symbol (placeholder)
Symbol COMMENTBLOCK using /* and */, but again, not implemented.
Token #include added. I intend to add the token type DIRECTIVE and various strings as directive types. I may simply add # as the token for DIRECTIVE, and any legal INDENTIFIER chars as the string.

At present #include is set to function as import "" and is only partially implemented.

...

Gleeok
02-16-2016, 08:43 AM
Really, there should be an extra parameter for translucency. Like my pappy used to say: "forwards compatibility of yesterday today, nonsensical and confusing rubbish of yesterday tomorrow".

Not that the all drawing stuff are the greatest or anything, but still. ;)

ZoriaRPG
02-16-2016, 09:53 AM
Really, there should be an extra parameter for translucency. Like my pappy used to say: "forwards compatibility of yesterday today, nonsensical and confusing rubbish of yesterday tomorrow".

Not that the all drawing stuff are the greatest or anything, but still. ;)

I know, and I agree; but only to a point. I'd rather do the extra things using overloads, so that older scripts don't break. This is primarily because you can't expect users to know how to update a script, particularly if the author doesn't update it (and you know that they won't); and also, because sometimes changing arguments will result in quests breaking., such as Starshooter, if you recall, I had to fix a few calls to make it work on any 2.5 final release.

I'll probably add overloads in, eventually, but for the moment, this works, to test things, and of course, we're still waiting on you, too, before we do anything officially for 2.future, so there's that. :darkmage:

http://timelord.insomnia247.nl/zc/script_drawing_all_XOR_Updated_Trans_Bitmaps_3D_Bi tmaps.cpp

Added support to Quad(), Quad3D(), Triangle(), and Triangle3D() to use a bitmap RT_* as a valid texture. I'm not entirely certain that what I did is correct, so if it isn't, then feel free to throw pet rocks.

This change uses the texture argument, and functions by using a value of 65520 as RT_0, 65521 as RT_1, and so forth. Thus, in ZScript (and std.zh) this would be represented as:



const int TEX_BITMAP = 65520;

void Quad3D(layer, pos, uv, cset, size, size, TEX_BITMAP+RT_BITMAP3, mode );


I don't think that it is possible to read the screen as a bitmap, via: zscriptDrawingRenderTarget->GetBitmapPtr(-1) ; -- or is it?
That could make for some rather interesting effects, if it's legal.

I set the minimum value for this method as '0', so if it's possible to read the screen as a bitmap like that, I'll need to adjust the values a tiny bit, to permit it.

If you have a moment, please look at how I set up the drawing commands, and tell me if I did anything that is obviously broken. I think one point that I may need to address, is the size (w and h) used in the vertices vectors. I set it up to do the vectors, create the bitmaps, and then issue the draw instruction inside the statements that read the type (tile, combo, bitmap) of texture. This feels like unnecessary duplication, but at least I know what I'm looking at, this way.

Gleeok
02-17-2016, 03:37 AM
In general, reading the backbuffer at any arbitrary point in time during a frame is just a really bad idea; you'd have to look at what allegro4 does with it for every platform, which I just assume is not possible (someone correct me if I am wrong). If you look at what 'Wavy' does you'll see why it does it there. (Also, scanlines, etc.) Maybe you'd have to just request it, ex;



Screen->RequestBackbuffer(RT_BITMAP0, sx, sy, sw, sh, dx, dy, dw, dh); //will be available after a call to Waitframe(); ...or WaitDraw() ..?





I know, and I agree; but only to a point. I'd rather do the extra things using overloads, so that older scripts don't break. This is primarily because you can't expect users to know how to update a script, particularly if the author doesn't update it (and you know that they won't); and also, because sometimes changing arguments will result in quests breaking., such as Starshooter, if you recall, I had to fix a few calls to make it work on any 2.5 final release.


It won't affect older scripts if it's a different function. 2.5x was supposed to be only bugfixes anyway. I think it's pretty bug free at this point. Might as well just start from 2.60; then you only have to worry about backward compatibility with 2.50, but can add in proper features and not ones shoehorned in.

ZoriaRPG
02-17-2016, 02:04 PM
In general, reading the backbuffer at any arbitrary point in time during a frame is just a really bad idea; you'd have to look at what allegro4 does with it for every platform, which I just assume is not possible (someone correct me if I am wrong). If you look at what 'Wavy' does you'll see why it does it there. (Also, scanlines, etc.) Maybe you'd have to just request it, ex;



Screen->RequestBackbuffer(RT_BITMAP0, sx, sy, sw, sh, dx, dy, dw, dh); //will be available after a call to Waitframe(); ...or WaitDraw() ..?



I will indeed examine how Screen->(Effect) works at present, to see how it's read. I think it'd be available after a Waitdraw() call though, as bitmap rendering occurs then, and is copies to the visible screen at Waitframe().

Else, I'm wrong, which would be for the Nth time this week, as it is every week.



It won't affect older scripts if it's a different function. 2.5x was supposed to be only bugfixes anyway. I think it's pretty bug free at this point. Might as well just start from 2.60; then you only have to worry about backward compatibility with 2.50, but can add in proper features and not ones shoehorned in.

What I figured to do, was finish a few things that were intended for 2.5, add in a few things that people whine about (including things that I routinely wish were present), maybe implement (an easy/basic) VC mechanism, and leave anything that demanded big sweeping changes, like increasing the number of available pointers for all these objects, for 2.60+.

Unlike some, I try to use SW versioning that makes sense, so I wouldn't want to jump from 2.50 to 2.60. If ZC used small numbering, 2.5.1, instead of 2.50.1, it would make sense to jump tot 2.6; but 2.60 represents a drastic change (to me), whereas 2.51, 2.52, etc make sense for minor changes. Sadly, we do have to skip those numbers, to prevent user confusion as people have been labelling 2.50.1 et. al as 2.51 and 2.51 and so forth.

That's why I'd go with 2.53, 2.54, or 2.55. The last of these 'sounds' better, but is inaccurate, unless we include more than a few small things. It would still make sense as an incremental release, considering that some of the things on that list are going to be monumentally convoluted. I don't even know if the changes listed on shardstorm ( build > 1793 ) represent a base for 2.50.3, or something else. We're actually going to need to discuss how everyone wants to handle that, as well as how build numbering is set up, as I know that you and Saffith have a system for that, but it's a mystery to everyone.

The main thing, is that internal, and external build IDs differ, and that's something I'd like to consolidate, so that devs, and users, are on the same page. At the very least, ZC needs to report the build to ZScript in some fashion. I think that is better than reporting the version number, as the build is unique, and the version number may not be unique.

Did you review either of those files, that I sent across? I'm mainly concerned about the vectors in the drawing functions, and of course, I'm still uncertain what the best way to handle Polygon() will be. ideally, reading/duplicating the structure of a ZScript array directly into a local array, or vector, on the engine side, and declaring the size based on the size of the ZC array, would be best. It may also be convoluted, but that's another matter. I think that some of the ideas that I had for Polygon(), I already sent over, but IDR.

I might add DrawSprite() as a function though, in addition to DrawBitmap() rather than having a dozen variations of DrawBitmap(), to call the Allegro 4 sprite functions. Insofar as additions go, I think that would be best, but I wonder if it would confuse users, given that sprites are also an internal ZQuest thing of their own.

ZoriaRPG
02-20-2016, 07:01 AM
Parser, proposed changes/additions (r12 - 23rd February, 2016). This file should be a drop-in replacement for ffscript.lpp, and all the additions (that are complete) should work properly. All the incomplete additions should either be disabled, or be redirected to do something that is already possible.

I'm uncertain how I want to format declaration tokens for array, char, and string; for new types, as these (if used as TOKENS) would conflict with pre-existing IDENTIFIERS. The ideal solutions would be to add a second layer to the parser, to view tokens in CONTEXT; but that is a daunting task.

The temporary solution is that declarations of new types would use the directive format, such as #array, or all caps ( e.g. ARRAY ). Either, or both of these would prevent possible conflicts.

Also, while it is plausible that there exists a script where someone defined constants for some of these tokens, such as TRUE or ELSE, that is simply terrible programming, and if those break, then the scriptmaker can easily correct this, as the likelihood of many scripts doing something that bizarre is minimal, and it is rather unlikely that they will be in general use by non-scripters.

For this reason, all the normal tokens will be available both in lowercase, and in ALLCAPS: This permits following some other (common) C-styles, for those who care about such things. :D

Note that anything in the comment blocks is simply proposed. There is no promise of these things coming to fruition, or indeed, of them being desirable. Some of them, such as SETFLAG* are included in the file, as a model to do some ZASM things directly in ZScript. This is somewhat dangerous, as people may use them improperly, but at least it affords doing some things in ZScriopt that are otherwise only possible with ZASM.

Of course, I'm uncertain that we would ever do a true GOTO instruction for ZScript, but you never know. It would be useful to do hardwired overrides, and that's about all; as it's easy to wreck a script with improper GOTOs, and then again, if we did GOTOs, they'd reference ZASM instruction numbers, not ZScript line numbers.

More interesting are things like CASE, and DEFINE, if we manage to fit those into the lexicon.

The following code is the drop-in file, should anyone wish to test it:

-=SPOILER=-

19-Feb Added some types, and symbols, plus clean-up.
19-Feb Added template routine for octal numbers to parser. Might even work.
22-Feb Added comment for igr type fo that we don;t forget what it is.
22-Feb Added unsigned and signed int, long, float defs to ffscript.lpp
* Unsigned int and float would work as normal ZScript int and float, but from 0 to 429,496.7295
* Signed|Unsigned long would be a true long. If we do this, then a true float is probably prudent.
* At present, the parser is set up to read both keywords together as a single token, rather than signedor unsigned being tokens in and of themselves. This is simply easier to handle with the typechecker, if it works.
* The additional types, such as array, char, unsigned | signed long, are something we want to add to make future AngelScript output easier.

ZoriaRPG
02-23-2016, 05:31 AM
Updated, above. Additional updates follow:


23-Feb : Added :: as equivalent to ->
23-Feb : Removed * from IDENTIFIERS: This would pose a lexical problem with certain code styles, where use of multiplication does not use spaces on either side of the MULTIPLY token *.
* Added @ and $ to IDENTIFIERS.
* Solving this would require scoped, recursive checking that I am not prepared to add to the parser (at this time).

23-Feb : I added the following line to the flex .lpp file:



[\x80-\xFF] { ; }//ASCII chars above 127 register as Whitespace.


If I understand flex formatting, this should convert any char from 0x80 to 0xFF, that is, upper-ASCII that is not part of a QUOTEDSTRING into a whiltespace. This should bypass errors involving these chars. I can add an action to report the error as well, but that'd be a courtesy warning.

If anyone knows if this is incorrect flex formatting for the set, or can confirm if it's correct, please let me know. (I'm not sure if you can make sets using ASCII values like that, or if you need to list each char individually.)

23-Feb : Added "" as a token for QUOTEDSTRING. I do not know if this will work, and allow an empty QUOTEDSTRING, or not. The parser may fault because it can't find anything between the quotes. if so, I'll revert this change.

23-Feb : I re-added the * to the parser, as follows:



//Add * to the identifier class, but only if at the end of an identifier, and no other alpha
//or numeric chars follow it. This should prevent it being mistaken for a MULTIPLY token.

([?]|[_a-zA-Z]|[0-9]|[@][$]+)([?]|[_a-zA-Z]|[0-9]|[@]|[$])*[*^([?]|[_a-zA-Z]|[0-9]|[@][$]+)([?]|[_a-zA-Z]|[0-9]|[@]|[$])]
{
doLines();
yylval = new ASTString(yytext, yylloc);
return IDENTIFIER;
}

/*
[^([?]|[_a-zA-Z]|[0-9]|[@][$]+)([?]|[_a-zA-Z]|[0-9]|[@]|[$])*] ([?]|[_a-zA-Z]|[0-9]|[@][$]+)([?]|[_a-zA-Z]|[0-9]|[@]|[$])*
{ doLines();
yylval = new ASTString(yytext, yylloc);
return USERPOINTER;
}
*/


I'm not sure if the logic of these sets if correct, but the idea is that any IDENTIFIER followed by a * and by nothing else, is an IDENTIFIER, and any token that starts with a * and has nothing preceding it, is a pointer. This could however, still cause problems with multiplication if the style is strange, such as:




int val = abc123* 3;
int val2 = abc123 *3;
int val3 = abc123 * 3;


I think we can live with this, to allow * in function/identifier names such as A*(), and in pointers, such as *ptr.

Otherwise, I can change it to ** as being allowed, but * not allowed.

I think that I will need to enter the ASCII value for a *, instead of , as flex will see that as '0 or more', even in braces. The same may apply for ?.

ZoriaRPG
02-23-2016, 11:12 AM
23-Feb : Added more types, and some potential plans...

In this, I also added pure-char tokens for : and, or, not, AND, OR, NOT, inaddition to the symbolic versions; and some prelims for XOR, xor, NAND, nand. NOR, and nor.

Apparently AngelScript uses this format, so ZScript may as well support it. All of these should work, unless they conflict with identifiers. They shouldn't, if their own internal case statements precede the IDENTIFIER case statement.

Likewise, I added prelims for case, CASE, switch, and SWITCH.

This may be easy to add, or a true pain, but I won't know until I do the logic for it.

Code to follow...damned post-length limitations.

ZoriaRPG
02-23-2016, 11:13 AM
ffscript.lpp (r16 - 23rd February, 2016)

-=SPOILER=-