attack graphics glitch

I've noticed this glitch for a while, but I wonder if anyone else has. When you use a projectile attack that has the color black in it, occasionally the black will show up as being transparent, even if it is not. This most typically happens when the hero and the enemy are at different heights on the battle screen and the attack has to fly at an angle.

I can provide a copy of an .rpg file that demonstrates this if anyone is curious. Does anyone have a way to fix it?

I would be interested to see the RPG file that does this

Cool. I'll upload it tomorrow night. I'm swamped this evening. This isn't an isolated instance either. I had the same problem on another game. I eventually just changed the attack animation so it didn't use black.

Was the black the first color in the palette? If so... that's because the first color in a palette is always transparent, whether it's black or not (though in older versions--I can't remember when the change was made--it was always the first color in the master palette, which was usually black, and couldn't be changed to anything else.)
I'm guessing everyone knows that already, but it's possible to forget random stuff like that sometimes.

If it's not the first color... then yeah, something's wrong here.

EDIT: ...reading over the original post I'm guessing that the first-color-is-transparent thing isn't the problem, but I figured I'd mention it just in case.

---

FYS:AHS -- Swapping out some step-on NPCs for zones + each step script
Puckamon -- Not until the reserve party is expanded.[/size]

James:

I sent you a PM including the game test file. Tell me if you have any questions.

EDIT: Oh crap! I figured out what's happening! Sometimes ranged attacks slide behind the enemy sprite and sometimes they go on top of it. That's weird. Is that a bug or a feature?

Yes.

---

Mega Tact v1.1
Super Penguin Chef
Wizard Blocks

Oh, yeah, I would call it a buggy feature.

The projectile animation calculates how many pixels horizontally and vertically the projectile has to move each frame to reach the target... but then any decimal values are rounded off, so the animation happens only using integer pixel distances. This means that if the distance between the attacker and the target is just wrong, the projectile sometimes ends up on the wrong side of the target.

The slice code actually has the ability to fix that behavior, but I have to convert the battle system to use slices before we can get the benefit of that fix.

I actually read that as the layering being random. If both enemy and target have the same y value at the end of the animation, then the final layering probably is the same as in the previous frame.

Very interesting. That makes sense since changing the position of the enemy would often make the problem go away.

Thanks for your help anyway. I'm sorry I bugged you about it.