[RPGMVX-A] UNABLE TO DRAW SPRITES DURING 'PERFORM_BATTLE_TRANSITION'
Posts
Pages:
1
Is there a hard-coded prevention of this, or am I simply doing something wrong?
I'm working on something to fix the resolution of Battle Transitions, cuz I'm too lazy to be bothered resizing them all in photoshop.. So, I'm taking the much more difficult route of learning how to code RGSS, and duplicating Graphics.transition() since apparently, you can't plug resized sprites/bitmaps into it.
... Starting to look like you can't plug bitmaps into PBT either though.
I'm working on something to fix the resolution of Battle Transitions, cuz I'm too lazy to be bothered resizing them all in photoshop.. So, I'm taking the much more difficult route of learning how to code RGSS, and duplicating Graphics.transition() since apparently, you can't plug resized sprites/bitmaps into it.
... Starting to look like you can't plug bitmaps into PBT either though.
module Cache def self.btrans(filename) load_bitmap("Graphics/System/", filename) end end class Scene_Map < Scene_Base def perform_battle_transition @BTrans_Name = "BattleStart" @FillRate = 80 @Trans = Cache.btrans(@BTrans_Name) @BattleTrans = Sprite.new @BattleTrans.bitmap = Bitmap.new(Graphics.width, Graphics.height) @BattleTrans.bitmap.stretch_blt($ScreenRez, @Trans, @Trans.rect) @BattleTrans.z = 1 @Overlay = Sprite.new @Overlay.bitmap = Bitmap.new(Graphics.width, Graphics.height) @Overlay.bitmap.fill_rect($ScreenRez,Color.new(0,0,0,@FillRate)) @Overlay.z = 0 Graphics.fadeout(60) @BattleTrans.bitmap.dispose @Overlay.bitmap.dispose end end
There might be a script out there for that.
I would search that out before trying to make one.
Or first try to change the file type from
Bitmap to jpg or png (I know the program accepts
these two files types because I use them all the time
when making battlebacks.)
Edit:
Also make sure everything is in the right folder and has
the proper name.
The Bitmap command simply draws a graphics field which is plugged into the available space defined by Sprite. Doesn't actually mean it's using a bitmap.
The default battlescene is a png file, anyways.
In theory, everything -should- be working.. Using Yanfly's Debug Extension, and putting in the code in, as it is in the editor, properly displays, resizes, and clears the images. Just something about the PBT call.
As for pre-existing scripts, I spent many an hour trying to look into it, but quite honestly, it was inordinately difficult to just find a tutorial to do
so trying to find anything except battletrans randomizers.. Almost pushed me to giving up. Unfortunately, the aforementioned guides all use Graphics.transition, and Graphics.freeze, which do not support what I'm aiming to do with the bitmap resizing though.
-----------------------------------------------------------\Edit\
Found the problem. Apparently, there's a Graphics.freeze call in {Scene_Map < Scene_Base} (pre_battle_scene)
Migrated the code I had in PBT to PBS, and disabled the PBT call in (terminate).
The bitmap is now being displayed at the correct time, and size. I just now have to tweak the effect so that it can closely mimic Graphics.transition(). Might be a challenge, that.
-----------------------------------------------------------\Edit\
It isn't perfect, but it's close enough for me to move on for now. \o/
Just gotta add in the framework to allow for multiple battletrans now, since trying to simply add compatibility code for each different script out there is far more hassle than it's worth.
The default battlescene is a png file, anyways.
In theory, everything -should- be working.. Using Yanfly's Debug Extension, and putting in the code in, as it is in the editor, properly displays, resizes, and clears the images. Just something about the PBT call.
As for pre-existing scripts, I spent many an hour trying to look into it, but quite honestly, it was inordinately difficult to just find a tutorial to do
Img = Sprite.new Img.bitmap = Bitmap.new(Img.png) Img.bitmap.stretch_blt(rect, source, oldrec)
so trying to find anything except battletrans randomizers.. Almost pushed me to giving up. Unfortunately, the aforementioned guides all use Graphics.transition, and Graphics.freeze, which do not support what I'm aiming to do with the bitmap resizing though.
-----------------------------------------------------------\Edit\
Found the problem. Apparently, there's a Graphics.freeze call in {Scene_Map < Scene_Base} (pre_battle_scene)
Migrated the code I had in PBT to PBS, and disabled the PBT call in (terminate).
The bitmap is now being displayed at the correct time, and size. I just now have to tweak the effect so that it can closely mimic Graphics.transition(). Might be a challenge, that.
-----------------------------------------------------------\Edit\
It isn't perfect, but it's close enough for me to move on for now. \o/
Just gotta add in the framework to allow for multiple battletrans now, since trying to simply add compatibility code for each different script out there is far more hassle than it's worth.
module Cache def self.btrans(filename) load_bitmap("Graphics/System/", filename) end end class Scene_Map < Scene_Base def terminate super SceneManager.snapshot_for_background dispose_spriteset end def pre_battle_scene Graphics.update @spriteset.dispose_characters BattleManager.save_bgm_and_bgs BattleManager.play_battle_bgm Sound.play_battle_start @BTrans_Name = "BattleStart" @FillBase = 20 @FillLength = 60 @Trans = Cache.btrans(@BTrans_Name) @BattleTrans = Sprite.new @BattleTrans.bitmap = Bitmap.new(Graphics.width, Graphics.height) @BattleTrans.bitmap.stretch_blt($ScreenRez, @Trans, @Trans.rect) @BattleTrans.z = 0 @Overlay = Sprite.new @Overlay.bitmap = Bitmap.new(Graphics.width, Graphics.height) @Overlay.bitmap.fill_rect($ScreenRez,Color.new) @Overlay.z = 1 @i=0 @DeltaRate = (255-@FillBase)/@FillLength*2 while(@i<@FillLength) @Overlay.bitmap.fill_rect($ScreenRez,Color.new(0,0,0,@DeltaRate*@i)) Graphics.update @i+=1 end @BattleTrans.bitmap.dispose @Overlay.bitmap.dispose end end
I think it might have been easier to adjust the image sizes in
a program like Gimp.
Just export the resources you want to adjust, then open them in Gimp.
Scale the image size and export it to the correct folder.
author=Me
I'm working on something to fix the resolution of Battle Transitions, cuz I'm too lazy to be bothered resizing them all in photoshop.
As in, I'd much rather have a fix that I never have to worry about, then resizing every battletrans I get to the resolution I'll be using them at.
So far, despite the transition not being perfect, it'll upscale and downscale any image assigned as a battletrans automatically.
Read, and comprehend the post you're commenting on, before commenting on it.
But doesn't your script readjust all images without prejudice.
So if you want to use resources that aren't default, the script
could make them look odd. Also if you make your own images you'll
have to keep your script in mind.
What I have posted /only/ resizes the battle transition image. Nothing else.
And, uh. Resizing non-default assets in photoshop is exactly the same distortion wise as resizing it in RMA. So.... Yeah.
However, I have expanded the code to include all battlebacks, and all backgrounds that come with Galv's menu system, with the option of randomizing battletransitions. Still don't have the actual transition effect where I'd like it, but eh. Not a big deal.
And to further clarify, minor rescalings, like the ones from default rez to 640x480 tend to work just fine. I'd worry if someone were trying to drop a 1080P image into it, but, then that one's on them.
And, uh. Resizing non-default assets in photoshop is exactly the same distortion wise as resizing it in RMA. So.... Yeah.
However, I have expanded the code to include all battlebacks, and all backgrounds that come with Galv's menu system, with the option of randomizing battletransitions. Still don't have the actual transition effect where I'd like it, but eh. Not a big deal.
And to further clarify, minor rescalings, like the ones from default rez to 640x480 tend to work just fine. I'd worry if someone were trying to drop a 1080P image into it, but, then that one's on them.
Pages:
1













