This is just a small fix to address #1099 which I have confirmed is in fact a bug. Mark Overmars is very explicit in the manual that
draw_sprite_stretched"fills" the area as opposed to
draw_spritewhich places the origin at the position specified.
This simple fix just removes the offset of the primitive drawn by the sprite's origin. I've additionally added a test to the drawing test so we know if somebody tries to change it again. Although I do not actually change draw_sprite_stretched_ext here, it is still affected because it's just a wrapper that calls draw_sprite_stretched with its color and alpha.
In my opinion, GameMaker is correct about this behavior as the sprite origin is basically useless when drawing the sprite stretched over an area. I feel this is especially true considering the sprite origin is not scaled with the rest of the sprite, so it's better to just not use it both for compatibility and because it's saner.
The GameMaker 6 through 8 manuals state the following:
draw_sprite(sprite,subimg,x,y) Draws subimage subimg (-1 = current) of the sprite with its origin at position (x,y). (Without color blending and no alpha transparency.)
draw_sprite_stretched(sprite,subimg,x,y,w,h) Draws the sprite stretched so that it fills the region with top-left corner (x,y) and width w and height h.
The new GameMaker: Studio manual is even more explicit:
NOTE: When drawing with this function, the sprite x offset and y offset are ignored and the sprite will be drawn with the top left corner at the specified x / y position in the room.
This function ignores the sprite's origin.
This pull request
The bot is correct that changes have been introduced to the drawing test, but this time, they are intentional.
@@ Coverage Diff @@ ## master #1447 +/- ## ========================================== + Coverage 17.18% 17.34% +0.15% ========================================== Files 164 164 Lines 17099 17103 +4 ========================================== + Hits 2939 2967 +28 + Misses 14160 14136 -24
|Impacted Files||Coverage Δ|
Alright, so I performed some additional testing on GameMaker 5 because of what I noticed in my comment on #1099. It seems Mark Overmars scaled the sprite origin in GM5 as you can see in the following screen. I will add a compatibility fix for that.
Alright, I've added a compliance setting for the behavior now for GameMaker 5 projects. I had to make several adjustments to the way
GM_COMPATIBILITY_VERSIONis implemented though.
- Had to include "Preprocessor_Environment_Editable/GAME_SETTINGS.h" for
GM_COMPATIBILITY_VERSIONto be checked in
- Had to change the macro
void ABORT_ON_ALL_ERRORS()to stop multiple definition errors. I changed it to just define the value and then check it in the engine inside
- I included
PFwindow.hso that I could check the
PFwindow.hat some time before it, although I noticed
API_Switchboard.his in fact including
UNMATCHED: Regression tests have indicated that graphical changes have been introduced. Carefully review the following image comparison for anomalies and adjust the changeset accordingly.
Including that header will cause files to be rebuilt each time that header changes. Depending on what's in that file, that is probably every time. This change, then, would vastly slow the build. Don't do less-than checks on the compatibility version without first checking that it is
defined(), and otherwise, don't include that header.