[Xane M.]

Hi! After a couple years, I've returned to MegaZeux and I'll quickly say I love some of the changes I've seen, like the new SMZX palette editor and palette support in the character editor!

Discovering this, I decided I'd try to make something using SMZX Mode 3, which I avoided years ago due to it not being as user-friendly. Everything seemed to be going fine, I have 256 colors I can use at any time, and many customizable four-color mini-palettes! I used the first row for my player character, the border, and common things, but then I tried to use 0x10 (c10). Suddenly, all colors in my game looked wrong, using the grey colors from the second row in the palette!

Here's screenshots to show how it's meant to look and what happened once I made the background use the second row:
 screen9.png (6.21K)
Number of downloads: 18  screen10.png (6.21K)
Number of downloads: 20

Here's the palette:
 SMZXPalette.png (6.99K)
Number of downloads: 22

I even made it use the last row, and predictably, basically everything turned black. It seems only Mary (the girl unbounded sprite) looks normal while all tiles are forced to use the last palette row that the game used. Is this normal behavior? If so, it's a bit limiting that I can only use sixteen mini-palettes at a time.

(I posted this topic here instead of the subforums because this isn't about Robotic or a technical problem, as this may be intended SMZX behavior.)

[Lachesis]

All I can think of is if you filled the board with something that's c10 and there are non-unbound/overlay graphics displaying over it using c0?, they'll turn into c1? even in SMZX mode 3. The background "transparency" effect from normal MZX mode (where sprites and overlay with background color zero inherit the background color of the thing under them) also affects the SMZX modes. If that's not what's happening, then it sounds like there could be a bug.

[Xane M.]

Lachesis, on 26 September 2018 - 09:50 PM, said:

All I can think of is if you filled the board with something that's c10 and there are non-unbound/overlay graphics displaying over it using c0?, they'll turn into c1? even in SMZX mode 3.

<strike>] Seems that's what's happening. The purple border seen in the screenshots is a static overlay but when I change all of the "c07 Space" into c10 CustomFloor, it affects the overlay. Strange behavior but I guess SMZX isn't perfect</strike>, it just makes MegaZeux look better.

 overlay-color-error.png (2.25K)
Number of downloads: 1

Here, I added a diagonal line of arrow blocks using a c1? palette. It looks fine until it goes under the overlay, which then uses the second row's corresponding palette. Strange behavior, but good to know it's normal. I suppose to work around this, I just have to make duplicates of every overlay palette on each row, so the colors messing up isn't visible.

<br><br>EDIT: Re-reading your reply, I'm now doubting that's what MegaZeux's doing. It seems when the overlay is over a tile with a palette from a different row, the whole tile inherits that row's palette. Therefore, if the overlay uses something like <b>c03</b>&nbsp;but the tile under it changes to <b>c10</b>, it'll become <b>c13</b>&nbsp;until that tile isn't under it. If it was just MegaZeux's transparency behavior (which I'm familiar with, where a character with a c?0 palette will have its BG color dynamically changed to whatever tile's behind it), it would only affect the darkest purple color, since that's the first, transparent "index" color, but it's affecting <b>all four</b>&nbsp;of the colors! This has to be a bug as MegaZeux's transparent color behavior doesn't replace both the BG and FG colors of a tile, it only changes the BG color.

This post has been edited by Xane M.: 27 September 2018 - 10:40 PM

[Dr Lancer-X]

Xane M., on 28 September 2018 - 05:42 AM, said:

I suppose to work around this, I just have to make duplicates of every overlay palette on each row, so the colors messing up isn't visible.

Or just reserve the c0? row of the palette for things that can't be affected by this, like background chars and unbound sprites. In a typical game you'll have plenty of things on the background so I don't see why you should waste entire rows just to work around this.

[Xane M.]

Dr Lancer-X, on 27 September 2018 - 05:05 PM, said:

Or just reserve the c0? row of the palette for things that can't be affected by this, like background chars and unbound sprites. In a typical game you'll have plenty of things on the background so I don't see why you should waste entire rows just to work around this.

I was doubting this would even change anything, but I was just making a demonstration to show the problem, but it seems it only affects the overlay if it uses a c0? palette! If I use palette line 1, it works even when something's behind it, but the moment I change a overlay tile to something on the first row, it glitches when over tiles. Not sure if this is a bug now or not, but you're right, I should just use the first row for things like Mary and use the rest for the overlay and environment.

[Dr Lancer-X]

Xane M., on 28 September 2018 - 08:58 AM, said:

I was doubting this would even change anything, but I was just making a demonstration to show the problem, but it seems it only affects the overlay if it uses a c0? palette! If I use palette line 1, it works even when something's behind it, but the moment I change a overlay tile to something on the first row, it glitches when over tiles. Not sure if this is a bug now or not, but you're right, I should just use the first row for things like Mary and use the rest for the overlay and environment.

No; this is just the behaviour Lachesis described.

Remember how in regular MZX, if you put overlay (or even foreground tiles like the player, builtins etc.) that has a background colour of 0 over something that has a background colour that isn't 0, the foreground tile inherits the background colour?



Here I have c07 overlay over some c1b floor. Well, that means the part of the c07 overlay that goes over the floor is drawn as c17

This still happens in SMZX mode, which means that the overlay that was previously drawn using SMZX subpalette #7 is drawn using SMZX subpalette 23 (the decimal value of c17) instead. Not a bug, and in fact can be useful, but can also be annoying when you aren't expecting it.

[Lachesis]

Note: when I mention the regular MZX background "transparency" effect, I'm not talking about actual unbound sprite transparency, but the background color inheritance effect. For example, if you put a c0F CustomBlock on a c11 Space in regular MZX mode, you'll get what looks like a white-on-blue CustomBlock that uses the palette c1F. This behavior makes sense in normal MZX and SMZX modes 1 and 2 since they all essentially use the idea of "cXY" meaning background color X and foreground color Y on a 16-color palette. The char inherits the entire palette from the wrong row because this effect still exists in SMZX mode 3, even though the effect maps poorly to it.

[Xane M.]

Ah, now it makes sense! Thanks for the explanations! It really is the same effect, just stranger-looking in SMZX Mode 3 since any combination of four colors can be chosen. I guess I didn't expect the psuedo-transparency to still be enabled in SMZX because of how different it looks compared to normal MegaZeux graphics. Now the next mystery will be finding out how to properly handle collision for that unbound sprite.