Fixes for Rainbow Treasure OP

[scurest]

Fixes the errors I noticed in the Rainbow Treasure OP.

Character placement off f1fe079

Some events are drawn off by one pixel. Caused by the formula in Game_Character::GetScreenX() and Y(). Changed to take the difference in pixels, not real coordinates, which I think is correct. Can someone check?

Pan speed too slow be05554

The pan drags behind the characters during the OP. Changed just by increasing the pan speed, but also changed to use SCREEN_TILE_WIDTH / 128 instead of 2, like for characters, I think it goes here too: @Ghabry, you made that change for character speed, what do you think?

Pan jumps after map teleport 8efd1a5

Caused by the pan in Game_Player being reset too early. I think this also fixes a bug where the pan is lost when teleporting within the same map (?).

Parallax BGs don't scroll backwards 28cedf8

Manganese's OP uses a parallax background to make it look like she's walking, but it goes the wrong way! Just a missing sign in UpdateParallax but I also used SCREEN_TILE_WIDTH / 128 here and sped it up.

Jumping in place 716623d

Discussed here.

---

There's also #356 and one more I just noticed—the old man in front of the chest's sweat drop is drawn behind him when it should be drawn in front—that I didn't fix.

[Ghabry]

This can be simplified to

(real_y - Game_Map::GetDisplayY()) / (SCREEN_TILE_WIDTH / TILE_SIZE) + TILE_SIZE;

(same for x)

[Zegeri]

a / (b / c) = a * c / b. So that can be rewritten as:

((real_y - Game_Map::GetDisplayY()) / SCREEN_TILE_WIDTH + 1) * TILE_SIZE;

[Ghabry]

Finally a practical use for school math.

[scurest]

Unfortunately integer division doesn't distribute over addition, eg. take SCREEN_TILE_WIDTH/TILE_SIZE=16, GetDisplayY()=1, and real_y=16. Then 16/16 - 1/16 = 1, but (16-1)/16 = 0.

[fdelapena]

Thanks scurest, about the swear drop issue is possibly related with #333.

[Ghabry]

+1 for this really detailed pull request.
Are you aware of any further open issue that are fixed by this?

[scurest]

I'm pretty sure no open issues are closed by this one, haha.

By the way... (I've never used Github before) would it have been better to open individual issues for all these and put details there?

[fdelapena]

I think there are a good collection of visible bugs not reported in the issue tracker which can be fixed "on the fly" without needing to open a separated bug before and it saves development time. They can be reported before, but I think it is not necessary in the current development stage. A lot of code contributed didn't have an issue previously opened and it can be discussed in pull requests too :) .

[Ghabry]

I usually only open issues for problems where I'm certain that there won't be a fix from my side soon.
When you fix some unreported problems just do it like in this PR