The z-space problem of displaying sprites

[DerVVulfman]

There is a hidden class called 'TileMap', and it draws the tiles in Viewport 1, the viewport that draws the map. The TileMap class draws the three layers of the map itself, the ground layer, the middle layer, and the top layer. And when the Tilemap draws the tiles, it calculates an estimated z-Depth for each 'line' of tile across the screen. This so it knows if the player or the other events are drawn above or below certain graphics... the branches of a tree or part of a wall.

If you use another viewport to render the character and the equipment, it would be independent of the viewport and the Tilemap that draws your map.  This would likely cause issues with placing your character behind things like trees or walls to be hidden.  This is why it is not recommended to use another viewport for your characters.

*   *   *

Ah..  You asked whether the code that separates your sprites into a 4x4 grid is separate from the viewport. YES.  Yes it is separate from the viewport.  The code that handles your sprite's 4 facing directions and 4 frames of animation per step is controlled within two classes:  Game_Character and Sprite_Character.

  Now THAT is one of the right questions to ask.  Does it pertain to working on a paperdoll/visual equipment system???  That depends

Game_Character is the class that calculates the values for your hero and other sprites, the facing direction, how fast they move, and even what graphic the sprites are assigned.  It is a 'parent' class to both 'Game_Event' and 'Game_Player'.  And what this means is that the routines and values of Game_Event carries a copy of Game_Character....

Its like this....

Code:

class Game_Character
  #--------------------------------------------------------------------------
  # * Determine if Jumping
  #--------------------------------------------------------------------------
  def jumping?
    # A jump is occurring if jump count is larger than 0
    return @jump_count > 0
  end
end

The above method called 'jumping?' is part of Game_Character

The first 'coded' line of the Game_Event class begins like this:

Code:

class Game_Event < Game_Character

... which means that Game_Event inherits all the values and methods from Game_Character.  And by that, Game_Event already has its own 'jumping?' method already written.  It was written within, and copied from Game_Character.

Why I bring this up is simple.  Your events use the same code for facing direction, frames, and walk animation options as your player.  So Game_Character is the SOURCE of your values for the 4 facing directions and 4 frames of animation for all your sprites.

But when it comes to changing the 4 frames and 4 facing directions... it is a nuisance.  Yep, I know.

But that above is all about Game_Character.

Sprite Character reads the values from Game_Character and uses them to render your hero and the map sprites. 

The primary area that divides your character into the 4x5 grid appears within lines 45 to 50 within Sprite_Character:

Code:

        self.bitmap = RPG::Cache.character(@character.character_name,
          @character.character_hue)
        @cw = bitmap.width / 4
        @ch = bitmap.height / 4
        self.ox = @cw / 2
        self.oy = @ch

And the lines to control 'which' frame to render (facing direction and movement frame) is not far below

Code:

      # Set rectangular transfer
      sx = @character.pattern * @cw
      sy = (@character.direction - 2) / 2 * @ch
      self.src_rect.set(sx, sy, @cw, @ch)

The values @character.pattern and @character.direction handles the individual step taken and the facing direction of the sprite.

  This would normally be of interest for a coder who wishes to make a script that uses 8-directional sprites for diagonal movement or increase the number of animation frames for smoother and more realistic movement.

BUT...

*   *   *

It is the Sprite_Character class that acquires your hero's sprite.  When you go from map to map, it acquires and memorizes your hero's graphics, and draws it on the map when the character walks about.  AND, it is a key area for Paperdoll/Visual Equipment systems.

As I said before, when you draw the equipment from your visual equipment script, it is only done once. And it just draws the hero walking around without lag from that point on.  I should say, it is only drawn once when you switch from map to map, or from the main menu to map.  That would be better said.

*   *   *

Now regarding over-sized graphics for your hero to wear, the armor, large cloak, or wings. Please look upon the following section of code within Sprite_Character:

        self.bitmap = RPG::Cache.character(@character.character_name,
            @character.character_hue)
        @cw = bitmap.width / 4
        @ch = bitmap.height / 4
        self.ox = @cw / 2
        self.oy = @ch

When the sprite is loaded for use in the game, it divides the sprite in 4x4 slices, and calculates the width and height of each frame.  Those values being @cw and @ch.

Below that, the system calculates the ox and oy values for the sprite itself, the bottom-most position of the sprite and the horizontal center. The ox and oy values are used when drawing the sprite on the map.

And it is the @cw and @ch values of the loaded sprite that are later used (shown below) that handles the drawing of the sprite on the map

    if @tile_id == 0
      # Set rectangular transfer
      sx = @character.pattern * @cw
      sy = (@character.direction - 2) / 2 * @ch
      self.src_rect.set(sx, sy, @cw, @ch)
    end
    # Set sprite coordinates
    self.x = @character.screen_x
    self.y = @character.screen_y
    self.z = @character.screen_z(@ch)

So yes, the width and height of the sprite is necessary when rendering.  This is why paperdoll systems have only dealt with graphics of the same size as the hero they are drawn upon.

*   *   *

Does this mean you cannot have 'oversized' equipment for your hero?

NO!!!

It's just... no one has done it before.

What needs to be done would be a multi-step process
1) Get 'all' the graphics for your hero and put them in an arrat:  His default body, his armor, his wings.
2) Sort through them all and find the maximum width and height needed
3) Get the 'center' point of your re-rendered sprite
4) Draw each layer (body, armor, wings) based on the new center point
  a) the center y and bottom x for the largest frame must be calculated
  b) Each layer must be divided into their individual frames.
  c) each frame must be individually centered and positioned to fit the new size

Yes, that is a bit more detailed... but it is possible.

The statement of
    self.bitmap = RPG::Cache.character(@character.character_name....
would now be replaced with
    self.bitmap = Bitmap.new(@ch, @cw)
assuming that @ch and @cw have been re-calculated to the largest size

And again, you would need to slice every frame of all the graphics and center each frame of every one of your graphics.  Once that is accomplished, they are then saved in self.bitmap.

A challenge, to say the least.