New Rokko has unpredictable activation rect

[Quintus]

The new rokko has some subtile problems with his activation rectangle. It can be quite set off from the real rokko graphic.

Vale,
Quintus

@Quintus Vertical Rokko has a similar problem for collision. The player dies if he is like 50 to 100 pixels left to him.

[ciro589m]

Hi Quintus, i'm cirocc :)

[Quintus]

Hi Quintus, i'm cirocc :)

Yeah ✨

Vale,
Quintus

[Quintus]

I see myself unable to fix this issue. I have tried yesterday and today morning, but it appears I can’t get it right.

The problem is in the cSprite::Update_Rect_Rotation_Z() method, and there only the branches for upwards (90°) and downwards (270°). That method rotates both the main image rectangle and the collision rectangle, and, it does it wrong for both as it does not set the Y coordinate upwards nor the X coordinate rightwards. It only works accidentally when the image and collision rectangles are squares or at least close to squares so that the offset is only little. The old Rokko was squared, so the problem did not occur in a noticable way. The only other objects affected by the method in question are Flyon and Eato, both of which do not have a rectangle too different from a square.

If someone with a more math-trained brain wants to try this one, feel free to do so.

Vale,
Quintus

[datahead8888]

I could try playing with it, but I can't guarantee any end date. I've done a lot of stuff with rotating/scaling/translating before. How do you active debugging mode? Does it show collision rectangles like this one?

Could you post your attempt in a branch?

Also, do you need help with #149?

@Quintus - could you assign yourself to a task when you start working it? Otherwise there is a high chance we will eventually duplicate each other's work.

[Quintus]

datahead8888 notifications@github.com writes:

How do
you active debugging mode? Does it show collision rectangles like
this one?

Use Ctrl+D to activate debugging mode. It shows collision rectangles in
red, and the real image rectangle in a thin green outline. Using that on
a rotated Rokko you will notice that the image rectangle is entirely
unaffected regardless of what you do. :-/

Also, do you need help with #149?

As I already explained, I’ve never used OpenGL. I know I have to learn
it, but for now this doesn’t change... I suppose I have to open some
kind of OpenGL context, put the image on it, and then rotate it, finally
displaying the result on the screen. I simply don’t know how to do
that. The comment I made in #149 points directly to the method that
needs to contain the code (at least I concluded so).

Vale,
Quintus

[datahead8888]

As I already explained, I’ve never used OpenGL. I know I have to learn
it, but for now this doesn’t change... I suppose I have to open some
kind of OpenGL context, put the image on it, and then rotate it, finally
displaying the result on the screen. I simply don’t know how to do
that.

I just wanted to confirm what help was needed with. Actually, if we do the upgrade we've been discussing, there may be no need for you to learn OpenGL -- Allegro or SFML will probably end up being more useful skills for TSC (with the exception of the lighting system task). I am the one who will be behind the curve, as I have never used either of these 2 API's in a project.

[datahead8888]

@Quintus - could you post your changes in a branch when you get a chance? This would pinpoint where the affected code is and show the results of any analysis you did. When I attempt this, I could start my changes from a different branch to avoid putting your changes in the history if this is a concern.

[datahead8888]

For the sake of my understanding, are these the two issues?

• The activation rectangle is the gray rectangle that shows up in the level editor when creating a Rokko. It's way too far to the left/right and should be closer to Rokko.
• It is not possible to stomp on a vertical Rokko (You will go through him). This is the collision detection issue Quintus spoke of.

For a vertical Rokko in debug mode, it is showing a collision box a bit to the left of the Rokko. You can actually stand on part of this box in god mode, but it does not kill him. If the stomp action is not working on the displayed collision box, is the collision box also displayed incorrectly?

It also might be clearer if we moved one of these into its own ticket, but we of course have a lot of technical information posted here already.

[datahead8888]

I think it might be simpler and less error prone to rewrite the Sprite::Update_Rect_Rotation_Z() method to rotate based on a rotation matrix so as to rotate the points rather than try to swap and/or subtract points. We would clamp the m_rot_z value to 0, 90, 180, or 270 as needed.

Either way I'll need to get a better understanding of what coordinate systems it's using for each rectangle used, but I still think using standard rotation operations sounds simpler.

[Quintus]

For the sake of my understanding, are these the two issues?

Not really. The rectangles built upon one another, i.e. the collision rectangle and the activation rectangle are interpreted relative to the main image rectangle. If the main image rectangle is wrong, the other two necessarily will go wrong.

If the stomp action is not working on the displayed collision box, is the collision box also displayed incorrectly?

If you look at the code, it appears to be possible to kill vertical Rokko by jumping against him from the side, see here. Killing an upwards-flying Rokko by jumping onto it from above also just seems wrong, so I think the current code is good. I’ve never tried to kill a vertical Rokko, though.

Vale,
Quintus

[datahead8888]

I will probably be largely unavailable for coding for 4-6 weeks (till a week after the semester or so), so this probably isn't going to be done soon. I am unassigning myself. If someone else looks into it, please assign yourself, in case I somehow did get free time and decided to look into this as a task.