In ZQuest, the border combos showing the adjacent screens always act as if the Layer 2/3 is background flag for the screen is unset.
For instance, if you're looking at screen 10, the leftmost column of screen 11 will appear to the right. Even if screen 11 has the Layer 2 as background flag set, layer 2 will be drawn over layer 0 while looking at screen 10.
Need I remind you that this would only effect large mode?
This is not a bug... -__-
Keep your eyes focused on the area of the screen your working on.
Tamamo wrote:Need I remind you that this would only effect large mode?
This is not a bug... -__-Keep your eyes focused on the area of the screen your working on.
Wait, no. No, no no, we're not going there. We are not pulling a Microsoft with this one...
This is a graphical issue, pure and simple. if it affects only one facet of the editor (e.g. in 'large' mode), then it's even more of a bug.
The editor should display what screens adjoining the one the user is editing appear to be in-game, to allow designing them so that game objects are seamless; to design transitions. I have no issue in making an option to show these layers over, for users that want to see screens in that fashion, but the default should put the layers where they belong.
We're going to attempt to address that one.
Find I'll humor you...
The drawing layer for zquest is 0 1 2 3 4 5 6 if draw layers 2 and 3 as background is checked on a screen then they are drawn before layer 0.
What is happening is that the screen itself is being draw not the layers individually. Drawing the layers individually will fix it if you check for the flags on the adjacent screens.
[MENTION=42714]Gleeok[/MENTION]
You're the master of bitmap drawing. And understanding how layers work, How much of an arse do you think it would be to get this working the way it should?
IIRC, it's done with ReleaseSubBitmap(). I'd need to look at that again though, as I paid more attention to how script drawing objects are rendered, than to how the screen itself is rendered normally. I sort of wanted to add negative layers to ZScript drawing, to allow people to draw layered background effects, which would be extreme;y useful. Think of SCHMUP style moving star backdrops, or (fake) parallax scrolling effects. I believe that if a screen has a background layer flag, script drawing to it works that way, but I am not certain of that.
Can anyone confirm without me needing to make something to test it?
Also, the passive subscreen drawing is handled with that wacky quest rule for Z1 compatibility, and the active subscreen is 'effectively' layer 7, as it's rendered over all the layers on the screen. IDR what 'draw over' ffcs do. Do they have their own lovely little layer, or are they just rendered last on 6?
I think we could probably cram a few more layers into 2.6, but not 2.55, as that has (sadly) been requested before. More important than adding layers though, is adding a light table. Allegro supports it, and Moosh, and a few others have asked for more levels of transparency, sop I may as well work on it; if Gleeok didn't already include that in his own new drawing modes. The ability to create, and define bitmaps is going to rock, and the new bitmap drawing modes are going to make people want to do even more with layers.
What I had in mind for 2.6, or 2.65--I know, that's far ahead, but 2.65 is on the roadmap--is layers -9, to 0, to +9. That would give people plenty of freedom, without needing to sacrifice layers to make backgrounds; and they would no longer need to tick that flag box.
On another note, we need to address 'Do not draw subscreen', as when this mode is on, the row 0 screens of a DMap--so, screens 0x00 to 0x0F--are offset, but no other rows are. If you want a sample quest to illustrate this, let me know. That's technically a bug of its own, and I should file it, which I'll try to do tomorrow. Still much work to finish tonight-ish.
The draw borders stuff is different than in ZC. ZQuest has it's own thing it does for that, which may or may not be a bug.
It's easy to get lost in there, but what you want is actually "zmap." There's a few draw*column/row functions somewhere around there. "zq_class.h" has a lot of the ZQuest specific class stuff in it.
Gleeok wrote:The draw borders stuff is different than in ZC. ZQuest has it's own thing it does for that, which may or may not be a bug.It's easy to get lost in there, but what you want is actually "zmap." There's a few draw*column/row functions somewhere around there. "zq_class.h" has a lot of the ZQuest specific class stuff in it.
[spoiler]
This should be the cover for any docs on the source files.
[/spoiler]
Unrelated, but how would I add the FDS (English chars) font to zc internally? How are the internal fonts constructed, stored, and ordered?
I believe they are just allegro ascii monochrome fonts.