The z-space problem of displaying sprites

[kyonides]

There's something missing in Kain's reply that you should be aware of for your game's sake, like in performance and memory handling. I noticed it in his Sprite_Character class edit.

Code:

  def dispose
    # Call alias method
    visualequip_spcharacter_dispose
    # Dispose of equipment sprites
    @equipment_sprites.each do |sprite|
      sprite.bitmap.dispose
      sprite.dispose
    end
  end

I changed the definition of the each loop for a good reason: Sprite class and its derivatives don't dispose their bitmaps automatically. That means that there's a chance you can still see your character on a new scene like the menu scene when it's supposed to have been marked for future deletion. Even if they weren't visible, it'd still be happening behind the curtains. This issue can be accumulative...

EDIT

There's a second issue that is related to the z coordinate.

Code:

class Sprite_Equipment < Sprite_Character
  def initialize(sprite)
    # Get character sprite
    @sprite = sprite
    # Parent method (Set viewport)
    super(@sprite.viewport)
    # Set Z value on top of character
    self.z = (@sprite.z + 1)
    # Refresh equipment graphic
    refresh
  end

self.z = (@sprite.z + 1) can't always be + 1 because of the character's current direction. If he's facing downwards, the wings will be on top of it.  Thus, you need to change the value to - 1 when it's facing down at least.

Probably, he could have taken care of it already, yet, I had to mention it just in case icogil ended up finding his characters in such a perilous situation.

Code:

  def dispose
    unless (self.bitmap.nil? || self.bitmap.disposed?)
      self.bitmap.dispose
      self.bitmap = nil
    end
  end

There self.bitmap.disposed? is optional normally, for you should only dispose such sprites at the end of your Scene script. The only reason why you'd need it would be if you're implementing a dynamic change of the equipment ON THE MAP. If you leave the scene and open another one, even if it has the spriteset being drawn on screen as a backdrop, you'll never need to double check that there's no disposed bitmap still hanging around at that moment. The parentheses he used above are unnecessary in this case.

PLUS, it should include a call to super method, like ALWAYS. It should be placed outside that condition, in fact, below the end keyword that closes the definition of the unless statement. Just super because it'd handle the disposal of the Sprite object in C or C++ code.

Code:

  def dispose
    unless self.bitmap.nil?
      self.bitmap.dispose
      self.bitmap = nil
    end
    super
  end

Correction of an Inaccurate Statement

Please note that I'm using Sprite_Character's viewport as Sprite_Equipment's viewport; if the accessory is larger than Sprite_Character's graphic, you may have to create a new Viewport object with modified dimensions. It would need to retrieve the width and height properties from the equipment's bitmap.rect. You might also need to modify the X and Y of the Viewport (synchronize them with the Character's X and Y, but modified.) I did not address this issue in the sample code, I only focused on synchronizing the Z value, so you'll have to implement your own solution.

No, Kain. He won't need to define a new Viewport object at all. The reason is quite simple, the Spriteset_Map class assigns a viewport that has the same dimensions as the game window so ANY of icogill's weapons and armor pieces and wings will be visible the whole time his heroes spend on the map, travelling around the game world.

A Badly Needed Emphasis

There's something quite basic but HIGHLY important that Kain Nobel told you that you should keep in mind, icogil.

Hopefully I didn't overload you with too much information. There is a lot of different aspects to think about when making a visual equipment system. I'm not discouraging you from writing your own, but I would definitely suggest checking out existing visual equipment systems and getting more study time in with the Ruby language. Figure out what you like VS what you don't like and go from there.