Ok so I doing a redo of the battle system it will still work the same way but it will look a lot different and along the way I'm sure to have lots of questions so I'm making a thread for it
Questions:1) Is there a better way to do this? [Answered]
Stretching the battle back to the bottom of the window: ShowHide class Spriteset_Battle
alias atbs_Spritset_Battle_upd_later update
def update
@viewport1.rect = Rect.new(0, 0, 640, 480)
if @battleback_name != $game_temp.battleback_name
@battleback_name = $game_temp.battleback_name
if @battleback_sprite.bitmap != nil
@battleback_sprite.bitmap.dispose
end
@battleback_sprite.bitmap = Bitmap.new(640, 480)
@battleback_sprite.bitmap.stretch_blt(Rect.new(0, 0, 640, 480),
RPG::Cache.battleback(@battleback_name), Rect.new(0, 0, 640, 320))
end
atbs_Spritset_Battle_upd_later
end
end
2)Sprite or Window [simi answered]
ok. so I'm remaking the window battle status into a bar at the top of the screen I made a sprite class that draws a box that holds the actors SP, HP, and status then made another class that creates four instances of the sprite and puts them together into a bar and acts as a buffer so that all the method calls that would work with Window_Battlestatus would have the same effect with my new boxes. (The reason i made them different boxes is so that I could move them separately).
what i want to know is if I made the right choice in picking sprites instead of windows to do the job?
also you know the window that pops up with skill names? should I remake that as a sprite or window?
3) What does $game_temp.battle_proc do when called? [Answered]
4)animated posing battlers [Answered]
so i'm considering an option for my new battle system that would allow animated batterers (like they go up and attack enemies)
I was looking at the Sprite_Battler class and it appeared that I could just change the sprites bitmap based on @battler.current_action am I correct?
also if I wanted to shrink or expand the battler as it got closer the only way i could think of would be to use the stretch_blt method repeatedly changing the destination rect every time. but this seems like a laggy process is there any better way?
5)scrolling battleback [Answered]
how would you get the other side of the battleback appear on the other side of the screen as you move it?
Lines 7-9 are unnecessary; that is done automatically by the GC.
Also, if you're making an ATB, please consider using my ATB Engine (in database). Nice and tiny, and should do the job for you easy.
Quote from: WcW on May 20, 2009, 07:04:05 am
Lines 7-9 are unnecessary; that is done automatically by the GC.
Also, if you're making an ATB, please consider using my ATB Engine (in database). Nice and tiny, and should do the job for you easy.
I not really making a ATBS that was really just a mis name of the method it should be AnTeBS >> Asan'Tear Battle System.
and what dose GC stand for?
"Garbage Collection" or "Garbage Collector" -- it's the device in Ruby that automatically deletes objects for you when they become unused. For instance, when you declare a variable in a method like so:
def do_stuff
my_var = 0
end
You will keep the variable until the method is done, at which point it will be deleted (unless you've stored it in class/instance/global variable since then).
Quote from: WcW on May 20, 2009, 07:04:05 am
that is done automatically by the GC.
No, it's not. But you shouldn't dispose bitmaps anyway. Only dispose sprites. If you have a bitmap that is being used by 2 sprites and you dispose it, there will be blood. I mean problems.
Called a "SEGFAULT" by some ;)
And the GC doesn't dispose bitmaps when no sprites/variables are referencing them? That's weird.
No, because they are usually contained in RPG::Cache. Otherwise it would dispose them automatically. If I'm not wrong, Window classes dispose self.contents automatically. I have never tried saving a bitmap from self.contents for later to try that out, though.
If you save it for later, it won't, because it won't be marked for GC >__<
No, I meant if the Window class disposes Bitmaps by itself before the GC does it.
Ah, I see.
so I don't need line 7-9 which dispose the bitmap in preparation for remakeing it because it will be disposed automatically?
Exactly. You generally don't need to worry about disposing bitmaps.
is it just me or are the RTP scripts redundant?
The RTP scripts suck. A lot. That's why scripters write all of their own stuff for games, usually.
Point made. They are not the worst framework in existence, but they need a lot of work and refactoring. i.e. The VX RTP scripts are better than the XP RTP scripts. Since I'm not very familiar with the VX scripts, I can't really estimate how good they are. But the XP scripts could definitely be better. Even the SDK sucks because it doesn't revamp the RTP scripts, it only extends it and makes it just slightly different and a very little bit better.
first post updated with new question
I have no idea what you're trying to ask, sorry.
ok rephrased as "what purposes are sprites best for and which purposes are windows best for" when talking about displaying information
Edit: New question
2. I prefer using sprites. They are more lightweight than windows. But then again sprites don't support the window skin. But using 2 sprites, one for the text and another one as background is still better than 1 window.
3. It sets the execution index of the event calling the battle (if an event is actually calling it) to the proper position depending on the outcome of the battle (Win, Lose or Escape).
New question
You can change the zoom_x and zoom_y attributes of a sprite rather that using stretch_blt.
If you want to change bitmaps on actions, you should implement it in Scene#update_phase4_step3 (animation for action performer) and Scene_Battle#phase4_step4 (animation for action targer) as those are the moment where the database animations are being played. @active_battler is the current battler instance.
zoom_x and zoom_y... *slaps head*
Quote from: Blizzard on June 01, 2009, 03:19:14 am
If you want to change bitmaps on actions, you should implement it in Scene#update_phase4_step3 (animation for action performer) and Scene_Battle#phase4_step4 (animation for action targer) as those are the moment where the database animations are being played. @active_battler is the current battler instance.
but those methods only pass information to a Game_Actor/Game_Enemy class instance, when Spriteset_Battle is updated it updates Sprite_Battler instances which handle the animation based on information it pulls from the Game_Actor/Game_Enemy class instance stored in @battler. so yes I would need to use those methods but the methods for the animation would have to go in Sprite_Battler, right?
You need two parts of code. One for setting it up in the scene (i.e. @active_battler.run_animation = true) and another part in Sprite_Battler#update where you check if there is a request for an animation (by checking @active_battler.run_animation or something like that) and execute it.
Sprite_Battler and Sprite_Character classes use a concept of observation. They observe the data classes and display information in form of sprites.
ok makes since now ty blizz.
New question.
I'm not sure what you mean, but I think you're trying to ask "How do I get the battleback to scroll," like the way you scroll a webpage. You just change the x and y of the sprite (assuming you loaded the full bitmap or whatever you needed to do) by whatever increment you need. Some of the classes (can't remember which, I think it's just Bitmap) also have @ox and @oy, but I haven't really used those so I don't know if they'd help.
Alternatively, just look at how Fogs are implemented in the RTP.
or panorama's
Yeah, but those aren't interesting. Fogs = Fancy Graphics.
aw found what I needed, the Plane class, changing the ox and oy of a plane class will scroll it.