E
Efrik
Guest
Hi.
I am having an issue with this statement that I can not comprehend.
I am designing a wordsearch writter that should include an option to export the resulting grid. I am trying to save it as a png file. In order tod o so my intention is to save the grid with the "surface_save_part" command.
In orer tod o so the "print" button (sized 3x1 cells) included in the room executes this in the draw event:
if (mouse_x>x)&&(mouse_x<(x+cellX*3))&&(mouse_y>y)&&(mouse_y<y+cellY)&&( mouse_check_button_released(mb_left)){
surface_save_part(application_surface,"searchforme.png",(room_width-(cellX*grindX))/2,96,cellX*grindX,cellY*grindY);
I know I wrote "grind" instead of "grid". That was funny at that moment so I left it like that.
The origin coordinates for the area to save are the same as those for the object that creates the grid. As the grid has a variable size stated by the user, and the grid was supposed to stay at the center of the screen, the X origin was coded as "room_width-(cellX*grindX)/2". It works and the grid is perfectly centered, no matter the size.
The problem comes when I execute the surface_save part. Although the origin and size should be the same, the result is as follows:
The grid where the image comes from has one column more to the right.
The problem should not but gets worse if I rersize the room in case the grid is too big to fit in the original room size.
I´ve tried with surface_save, screen_save, _part, copying the surface, copying the view, and scaling, and the result is allways the same. I may have fail my maths, but the function is the same for the object and the surface, so I doubt it.
Any solution?
I am having an issue with this statement that I can not comprehend.
I am designing a wordsearch writter that should include an option to export the resulting grid. I am trying to save it as a png file. In order tod o so my intention is to save the grid with the "surface_save_part" command.
In orer tod o so the "print" button (sized 3x1 cells) included in the room executes this in the draw event:
if (mouse_x>x)&&(mouse_x<(x+cellX*3))&&(mouse_y>y)&&(mouse_y<y+cellY)&&( mouse_check_button_released(mb_left)){
surface_save_part(application_surface,"searchforme.png",(room_width-(cellX*grindX))/2,96,cellX*grindX,cellY*grindY);
I know I wrote "grind" instead of "grid". That was funny at that moment so I left it like that.
The origin coordinates for the area to save are the same as those for the object that creates the grid. As the grid has a variable size stated by the user, and the grid was supposed to stay at the center of the screen, the X origin was coded as "room_width-(cellX*grindX)/2". It works and the grid is perfectly centered, no matter the size.
The problem comes when I execute the surface_save part. Although the origin and size should be the same, the result is as follows:
The grid where the image comes from has one column more to the right.
The problem should not but gets worse if I rersize the room in case the grid is too big to fit in the original room size.
I´ve tried with surface_save, screen_save, _part, copying the surface, copying the view, and scaling, and the result is allways the same. I may have fail my maths, but the function is the same for the object and the surface, so I doubt it.
Any solution?
