Screen->Draw Screen Shows Wrong CSet of Combos

[ywkls]

When using Screen->DrawScreen, the combos in the drawn screen are all the same CSet instead of being adjusted as they are on the original screen.

Demonstratory Video-



Quest Used to Test This-

https://www.dropbox.com/s/40tz8e30hw...awbug.qst?dl=0

All of the screens shown uses the same DMap and level palette.

[Saffith]

It's ignoring CSet2. DrawLayer does, too.

[ZoriaRPG]

It's ignoring CSet2. DrawLayer does, too.

Before I even consider doing anything about that, what was the reason that the original devs chose to do this?

[Saffith]

I don't think it was intentional.

[ZoriaRPG]

I don't think it was intentional.

Fair enough. I guess I'll see if I can add support for drawing the combo cset2 colours to it. I've been trying to get a git set-up to begin migrating changes, and even git shell is causing me migraines. Bloody fun, all around.

[ywkls]

It's ignoring CSet2. DrawLayer does, too.

I should note also (because I remember this from a previous attempt to use it) that Game->GetComboCSet also ignores CSet 2.

[Saffith]

That one's correct. ComboC and Get/SetComboCSet have to do with the CSet in which the combo was placed, regardless of how it actually appears.

[ZoriaRPG]

That one's correct. ComboC and Get/SetComboCSet have to do with the CSet in which the combo was placed, regardless of how it actually appears.

Aye.

One thing I had considered doing, is adding a way to GetComboAttributes() and SetComboAttribbutes() at some point down the line. It's actually a bit weird now, as some GetCombo*() values are from the placed combo, and some are from the static editor values, and this is inconsistent as hell. A clean set of handlers is probably in order.

I was thinking of GetComboAttributes(int combo, *ptr) and SetComboAttributes(int combo, *ptr) to allow reading or editing them.

Anyway...

I will look into this, unless Saffith or someone else wants to do it. DrawScreen and DrawLayer are terrible instructions, from what I remember, or at least, they seem sort of half-wrought, but I;m not certain if I can improve their implementation. The way that they work, may be as good as it gets, in terms of performance. As I recall, doing DrawCombo() to a bitmap for each combo on a screen, and then doing DrawBitmap, is probably equally efficient. hHe main difference is in the number of draw commands issued by the user. That's essentially what DrawScreen is doing.

It also lacks some args, such as opacity, while DrawLayer doesn't, for no good reason. Perhaps I'll do DrawScreenEx at some point, too, with args like DrawScreen(int layers[], int coordinates[], int opacity[]), but I have enough to worry about with the merge in progress. THat will delay my ability to do any bugfixes for a while.