Bitmap::width, height

[Engr. Adiktuzmiko]

though you might need to adjust x,y too if you do that... stretch_blt and blt will be easier, and it seems to be used in the defaults too...

 

[Mithran]

Don't Graphics.update more than once per frame. I just wanted you to know opening a message box does it implicitly, which is useful for seeing exactly what is going on with the screen layout sprites at that exact moment.

stretch_blt is an alternative to using zoom, but in my experience, it isn't any more accurate any more accurate than using the sprites zoom_ methods. It also requires maintaining a separate bitmap for every sprite. It is definitely more costly if used every frame (as the script is set up now, it would be used every frame, which is not advisable).

If something doesn't work how you thought it would, try testing in a scenario with less variables.

DataManager.init$game_map.interpreter.window_on(Window_Gold, 'testing')folder = $game_message.michael_wndw_bg_ary[Window_Gold][2]name = $game_message.michael_wndw_bg_ary[Window_Gold][1]b = Cache.cache_extended(folder, name)s = Sprite.new()s.bitmap = bw = Window.new(0, 0, Graphics.width, Graphics.height)w.visible = falses.zoom_x = w.width / s.bitmap.width.to_fs.zoom_y = w.height / s.bitmap.height.to_floop do  Input.update  Graphics.update  s.zoom_x += 0.001 if Input.repeat?(:RIGHT)  s.zoom_x -= 0.001 if Input.repeat?(:LEFT)  s.zoom_y += 0.001 if Input.repeat?(:UP)  s.zoom_y -= 0.001 if Input.repeat?(:DOWN)  p s.zoom_x, s.zoom_y  if Input.trigger?(:    s.dispose    break  endend

Using your 161 x 105 there to the size of a window the screen, you can see how accurate zoom is for overall image size (pressing down or left even once creates a pixel gap by reducing the zoom by 0.001.) You can still use stretch_blt of course, but since your problem is not with the function of the zoom but with the values you are feeding it, it probably won't solve anything.

 

[Engr. Adiktuzmiko]

I don't seem to have any problems with blt every refresh (which I made in a way such that moving cursor will call refresh), at least frame rate wise, my test game still runs at 60fps...


but anyway, why would the picture be remade every frame? it does seem too costly...

 

[Mike]

K, I gave strech_blt a shot.

Spoiler

#============================ Resized ============================#

 

      #self.x = 0 if self.bitmap.width == 559 

      #self.y = 0 if self.bitmap.height == 423

      

      #store_sp_w_float = self.bitmap.width.to_f

      #store_sp_h_float = self.bitmap.height.to_f

      #store_wndw_w_float = window.width.to_f #+ 12 #paddings

      #store_wndw_h_float = window.height.to_f #+ 12

 

      #self.zoom_x = store_wndw_w_float / store_sp_w_float

      #self.zoom_y = store_wndw_h_float / store_sp_h_float

      #self.src_rect.width = Graphics.width

      #self.src_rect.height = Graphics.height

 

      #=========================== Relocate ============================#

 

      #No relocation is necessary for default resizement, but for organized purpose

      #self.x = window.x

      #self.y = window.y

      

      #testing something here

      self.visible = false

      name = i[1]

      folder = i[2]

      test_sprite = Sprite.new

      test_sprite.bitmap = Bitmap.new(544, 416)

      some_bitmap = Cache.cache_extended(folder, name)

      some_bitmap_rect = Rect.new(0,0, some_bitmap.width,some_bitmap.height)

      #self.src_rect.set(self.x,self.y,Graphics.width, Graphics.height)

      window_rect = Rect.new(window.x, window.y, window.width, window.height)

      test_sprite.bitmap.stretch_blt(window_rect, some_bitmap, some_bitmap_rect)

      test_sprite.viewport = (window.viewport) ? window.viewport : window.michael_bg_vp

      test_sprite.visible = ((window.open?) && (window.visible))

Result:

Spoiler

It does what it should (well I still need to fix some minor stuff, but yes, it fills the gap left by zoom_x and zoom_y), but I'm still trying to figure out what alter the 'correct' values for zoom_x and zoom_y. Thanks for the alternative, Shana. But constructing Rect without any destructor is quite scary for me though if I'm too frustrated, I'll go with stretch_blt : )

@Mithram

The stretch_blt does take a lot that the fps slows down to the point where I could see how the viewport of Scene_Battle is shifted from left to right by 10-15 pixels at a time.

And yes, thank you, the error is in sprite update thingy. I'll try to manually debug it one logic at a time. : D

 

[Engr. Adiktuzmiko]

anyway, try to reduce the number of times the picture is redrawn, and only redraw when needed... no matter which method you choose...

 

[Mithran]

Rect doesn't need a destructor, they are GC'd when no longer referenced. Bitmap and Sprite on the other hand, yes, you should manually dispose them before you lose their last reference to avoid a leak (potential crash issue if dealing with viewports). stretch_blt is not very costly by itself, but if you need to create a new bitmap to account for the new size every time, it will be. If you only draw it once per change, though, it shouldn't be an issue, since it follows that very few people would want to rapidly change their window backgrounds. You can stress test and optimize after debugging.

 

[Mike]

I'm still collecting data for the offset x and y, but I've found out that nothing is wrong with the value from

window.width / self.bitmap.width

I calculated their real values and replaced them with their floating value.

zoom_x = 0.74418 #0.74418 is the correct value of window.width / self.bitmap.width (yes, I translate them into numbers, and set the zoom using the raw number instead of using any variable), and yet it's offset by -0.021

I had to do the following for the zoom_x to work properly

zoom_x = 0.74418 + 0.021 #Only work for that one bitmap though. :3

I'm just letting you folks updated before I go to sleep. I'll continue collecting more data for the Sprite.zoom offset next time. I'll gather enough data so that the offset equation would work 95% the time... If I lose my passion, then I'll go for the second derivative (90% accuracy) Have a good night .-.

@Shana

Yea, I'll do that after I find the offset values...

@Mithram

Yes, yes, I'll definitely debug first. Thanks for letting me know about the class Rect properties.

=================================================================================================

I have to do statistic just for this freakin' offset/bug...

 

[Mithran]

0.74418 is correctly calculated. The issue is that you are setting src_rect to the screen's size instead of the bitmap's size. zoom considers src_rect size but it also considers the actual bitmap size. It seems there is an internal rounding error for calculating the display width and height if the src_rect happens to be anything bigger than the bitmap (a more than the actual bitmap is considered for display, but not the entire dimensions of the src_rect), resulting in the gap. If you are using a src_rect smaller than the bitmap, then you need to use the src_rect's dimensions in the zoom calculation (since that is actually what is displayed). The safest way would just be to set the src_rect's values to the bitmap's dimensions before calculating zoom, then use the src_rect's dimensions to calculate zoom.

 

[Mike]

0.74418 is correctly calculated. The issue is that you are setting src_rect to the screen's size instead of the bitmap's size. zoom considers src_rect size but it also considers the actual bitmap size. It seems there is an internal rounding error for calculating the display width and height if the src_rect happens to be anything bigger than the bitmap (a more than the actual bitmap is considered for display, but not the entire dimensions of the src_rect), resulting in the gap. If you are using a src_rect smaller than the bitmap, then you need to use the src_rect's dimensions in the zoom calculation (since that is actually what is displayed). The safest way would just be to set the src_rect's values to the bitmap's dimensions before calculating zoom, then use the src_rect's dimensions to calculate zoom.

I didn't know that... Thanks for stopping me from continuing the inefficient research. I might be able to get that "bigger" rounding offset if I keep collecting data and find the pattern, but hey, if I could make the code more simple and less math, that would be great, too. I'll try that, I was careless by setting src_rect size to be that of the graphic size...

Edit:

self.src_rect.width = self.bitmap.width# * store_wndw_w_float / store_sp_w_floatself.src_rect.height = self.bitmap.height# * store_wndw_h_float / store_sp_h_floatResize is working properly now. Thanks, Mithram... I'll just increase the efficiency for now after fixing the others, then release the script and update it till I got no more time. lol. I'm pretty bad at exploring uncharted area. Hmm, hopefully things would go smoother from now on. .-.

 

[Mithran]

Glad you got it working. I would have said something sooner except I wasn't even aware that causing a src_rect bigger than the sprites bitmap would cause a rounding error in the sprite's zoom function as I've never had a legitimate reason to ever set the src_rect bigger than the bitmap's size. You never stop learning.

 

[Mike]

Glad you got it working. I would have said something sooner except I wasn't even aware that causing a src_rect bigger than the sprites bitmap would cause a rounding error in the sprite's zoom function as I've never had a legitimate reason to ever set the src_rect bigger than the bitmap's size. You never stop learning.

I've learned so much by now on both ruby and RGSS. : D

If you've seen any of my screen shot. I had all ruby built-in-core-classes and stuffs open on other tabs. And I even have ruby cheat sheet printed.

Alright, I'm getting off-topic now. I've sent my script submission, let me know if you have any concern about it.

I'm quite overjoyed for conquering this code, but it's not over yet, I still have much more expansion plans. : D