ZC 2.future Codebase Changes (Log)

[Gleeok]

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]

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.