Translate/Scale/Rotate Testing
DescriptionDue to the fact that translation, scaling and rotation operations are not commutative, it's possible to get different results when changing their order. All of these 3 have been implemented in the Sprite class so far which will serve as a test case.
Use different combinations of x/y coordinates (x, y), offsets (ox, oy), scales (zoom_x, zoom_y) and different rotations (angle). Check out if the results in RMXP match with ARC's display. If they differ, change the Sprite::draw method. There are three blocks of code that might require you to change their order.
if (this->x != 0 || this->y != 0)
{
april::rendersys->translate((float)this->x, (float)this->y);
}
if (this->zoomX != 1.0f || this->zoomY != 1.0f)
{
april::rendersys->scale(this->zoomX, this->zoomY, 1.0f);
}
if (this->angle != 0.0f)
{
april::rendersys->rotate(this->angle);
}
The second part of the task includes checks if the ox and oy for Plane work the same in ARC when using scales as they work in RMXP.
PriorityHigh.
PrerequisitesNone
AssignedForeverZer0
Everything elseThis is a simple task, it just needs some time. I am sure that I have implemented it properly, but testing to make sure would be a good idea.
Just started looking for a task to start and noticed my name on it already. Didn't see it the first time I read it. Oops.
Will start now. :P
Gooooooood! >8U
:V:
Finished. (finally, I know...)
Did a lot of testing, in the end I only had to swap two methods, but found that it is always the same as RMXP.
Plane works like a charm already, and there were no changes made.
One thing to note though, since ARC has a higher frame rate, scrolling Planes can appear to move fast (depending on what you want), even when it is only one pixel per update. Just a thought to maybe have an easy way to use an "every 3rd update" or whatever type way for users to slow it down if needed.
Damn them clouds look smooth floating across the screen, though!
Plane still doesn't cut off stuff, that's the only thing that still needs to be fixed.
Don't worry about update speed, we will fix these things in the end.
What do you mean by "cut off stuff"?
I didn't see any problems with it, at least visually.
If you have a viewport of 32x32, then everything will be rendered only within that 32x32 box. Everything outside of that box is not visible. Remember my Blizz-ABS Minimap? It is actually a big bitmap one a sprite within a viewport. That's why it is so nicely cut off. I don't have that functionality ready in our Viewport yet. I've tried using a render-to-texture procedure, but it doesn't seem to be working so I'll have to think of something else. ._.
rendering to a texture is the only way I can think to do it. the only other way I could think of would be to somehow clip the render able object at render time so that it's source rect or whatever matched that of the viewport
And I think that can be done if I can't get render-to-texture working.