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.

[kyonides]

Basically, what icogill stubbornly wants to achieve is to repeat the same process that Sprite_Character performs multiplied by as many weapons and pieces of armor every hero has equipped so far. Every single one of those extra sprites would need to recalculate their width and height like quite often to make sure everything will run smoothly. All of them could have different sizes so it's... messy to say the least. And then they should handle the z coordinate properly depending on which side they're currently facing.

[optional]
My friendly advice would be to desist on doing it yourself. You're not acclimated with the engine as to do it on your own without getting into serious troubles. You'd end up depending on available scripters to make it work, but the code wouldn't be yours anyway. Or you could just use an existing visual equipment script...

You see, when something simply requires of you a lot more time and effort than what's deemed necessary or convenient, it's better to desist. That's important because it usually means there's gotta be a quick way to achieve the same goal without going through many unexpected issues for no good reason.

That also means you'd need to resize all of your weapons and armors and wings, like it or not. Yet, that's way better than causing your game to lower its framerate for it'd dealing with many extra calculations very often.
[/optional]

Since it seems you'll keep insisting on making it, be ready to wait for a long time before you can make it run properly under every single condition that it needs to fulfill to work just as intended.

[DerVVulfman]

Stubbornly? I'd be a bit more diplomatic. It is not stubborn when one doesn't know the amount of work to bring about the desired effect.

I would wish to eventually look at the Paperdoll system in my Lycan ABS. It has been so long since I worked upon the paperdoll system within, apparently having written the code in 2016. And it has a lot of code within which is dependent upon the Lycan system, so removal and use outside is ... problematic.

But it would take care of two things, Proper Layering and individual layering based upon direction faced. Including custom choice graphics per character and ... maybe? flexible sizes??? That would need to be worked upon. As far as custom choice graphics per character, that I have done before. But the latter.... nope. If I did, it would be a first.

[icogil]

I guess it's more complicated than I thought
I really wanted to make it, but it was a pity.
I thought about how to match the sprite of the event to the position of the character on the map, but this is also my coding issue, so the prospects are not good.
Thank you all for your kind replies.
I learned a lot but I have to stop
I wanted to use RMXP's unique sensibility, but there are too many limitations for me to handle alone...
Anyway thanks again
I am moved by your passion and knowledge.

[DerVVulfman]

Never... say never.



Yes, the header states that this was something I worked on over six years ago.  And for 'general' usage, I do need to strip away much of the BattleSystem code I had introduced. But the code itself is still sound.  The small render of the four characters, two carrying shields, is thanks to code I only just introduced to let it work with Fukuyama's classic "Train Actor" script, the oldest caterpillar or hero follow script I know.

Currently, the script has some nice features already
1) You can change the order in which your gear is placed based on facing direction.  So if the player character is facing forward to you, the cloak is rendered first before anything else.  If the player is facing up and away from you, the cloak is rendered last and atop all the armor.  Of course, this is assuming you have a cloak.  Let's assume these are the wings, shall we? 

2) You can have custom individual graphics per character.  So if  Aluxes has a set of wings and Hilda has a set of wings, yes... both have wings.  Only, you can give Hilda prettier wing graphics even though they both identify as the same wing item in inventory.

3) HUES.   Why make 4 sets of shirts when you only need one...?  You may only need one graphic and just change the hue in the setup?  Four shirts of red, blue, yellow and brown with ONLY one graphic needed.

Examples:

Code:

    EQUIP['2,1']        = ["Shield/RndShield"]
    EQUIP['2,2']        = ["Shield/RndShield",    90]
    EQUIP['2,3']        = ["Shield/RndShield",    180]
    EQUIP['2,4']        = ["Shield/RndShield",    240]

A bit sloppy, but usable.

The EQUIP array has 2 parameters, the 'slot' and the 'item_id'.  For all four here, the slot is #2 for the shield. And the item IDs are for the Bronze, Iron, Steel and Mythril shields.

Each one is given an array that has the path to a shield graphic and an optional hue.  ALL FOUR SHIELDS USE THE SAME GRAPHIC!!!  I only changed the hue so they have different coloring.  For a shield that has many colors... well, not the best. It depends on the source graphic.  But the option is there.

Code:

    EQUIP['2,1,'008']        = ["Shield/Shield2"]
    EQUIP['2,2,'008']        = ["Shield/Shield2",   90]
    EQUIP['2,3,'008']        = ["Shield/Shield2",   180]
    EQUIP['2,4,'008']        = ["Shield/Shield2",   240]

This is BASICALLY the same.  but the EQUIP array now has a third parameter, that being 008.   The third parameter indicates the specific ActorID that acquires 'Shield2' instead of 'Rndshield', though they are still being hue-altered.

I don't have the layering exactly as I want it... wanting to allow full graphics to be drawn 'before' the player/actor.  That will be an endeavor, but one I should be up to task.

I mean, hey...  I made a Dance-Dance-Revolution demo with this, and am probably the only person who invented a system to actually "CACHE" the audio files so they can be compressed within your .rgsaad file (limiting what you need to send with your game.

[kyonides]

You could take a break to learn more about the language and get ideas on how to simplify the processing of many images to find an ideal balance between ease of use and configuration while not allowing it to become a resource hog. Did you ever try any character maker before asking for this custom script? For instance, they'd deal with the z coordinate issue by default.

EDIT: I was talking about the sprite's z coordinate alias depth from the very beginning. I don't know why they insisted on calling it z depth if it's still a coordinate. Oh well, the only issue is that the maker doesn't keep a 1:1 ratio for that coordinate, instead the help files claim it's something like 50:1.

[DerVVulfman]

Okay, I currently isolated the system that creates the final-result bitmap to its own method within my Paperdoll module. So it no longer needs to be duplicated within both Sprite_Character and the 'draw_actor_graphic' method of Window_Base. This will make future work easier as I don't have to do the same thing over and over and over.

I wonder why other scripters never thought of that?

In fact... here's the draw_actor_graphic method

Code:

#--------------------------------------------------------------------------
  # * Draw Graphic
  #     actor : actor
  #     x     : draw spot x-coordinate
  #     y     : draw spot y-coordinate
  #--------------------------------------------------------------------------
  def draw_actor_graphic(actor, x, y)
    return if actor.nil?
    bmp       = Paperdoll.get_graphic(actor, actor.character_name,
                  actor.character_hue)
    cw        = bmp.width  / 4
    ch        = bmp.height / 4
    # Set the rectangle
    src_rect  = Rect.new(0, 0, cw, ch)
    self.contents.blt(x - cw / 2, y - ch, bmp, src_rect, 255)
  end

The above section only registers one, and only one, bitmap image. It is the final product generated from the various layers. The sprite itself has only one bitmap image too. Only one if you do not use a paperdoll system and only one IF you use a paperdoll system. Paperdoll systems do not show 2,3 or 5 layers atop each other at the same time. It takes your character, gets the bitmap from it, and then blits another image on top of it, and then saves that bitmap now altered. No multiple layers shown... only one after it has been altered.

As to other Visual Equipment scripts, it appears that Geso Chisku had intended... 'had' ... intended... to have multiple size graphics as you desired. But his script was last updated in 2014, and it was never added.

Towards z-Depth, let me re-iterate...

The work which handles order of the individual graphic layers is done within the sprite rendering system itself. No zDepth is needed, nor has it ever been used in any Visual Equipment script, be it Geso's, Me™'s, Rataime's, or any other I have seen. This includes "Composite Graphics / Visual Equipment" v 1.0.1 © January 13, 2013 by Modern Algebra for RPGMaker VXAce, or "Visual Equpment!" v 1.1b © November 12, 2015 by Rexal for RPGMaker MV (the only one I know that is free at WEB).

The only z-Depth that matters is the base character walking about.

[DerVVulfman]

Well, the layers used when creating the final resulting bitmap may not be 'resized' to suit you, icogil.  But the layers can be controlled as to where the player is when it comes to layering.  By that, I can draw things like a shield  'behind' the actor if he/she is facing the right of the screen.  And the shield draws 'over' the actor when facing left.  So my 'layering' system that happens automatically is now working.

  # CONSTANT SLOTS
  # ==============
  # Add, remove or change the value of constants to match the slots
  # used in your system.
  # ======================================================================
    BODY        = 0 # (FAKE SLOT) Reserved for the Subject's body
    RIGHT       = 1 # Slot for the Right hand ... weapon
    LEFT        = 2 # Slot for the Left Hand  ... weapon or shield
    HELMET      = 3 # Slot for the Helmet
    ARMOR       = 4 # Slot for the Armor
    ACCESSORY   = 5 # Slot for the Accessory

  # SLOT ORDER STYLE
  # ================
  # This array defines the order in which your graphics are drawn based
  # on the slots.  Easy to use, just fill in with the IDs of the contants
  # defined above.
  # ======================================================================
    ORDER_STYLE[2] = [ BODY, ARMOR, HELMET, ACCESSORY, LEFT, RIGHT]
    ORDER_STYLE[4] = [ BODY, ARMOR, HELMET, ACCESSORY, LEFT, RIGHT]
    ORDER_STYLE[6] = [ LEFT, BODY, ARMOR, HELMET, ACCESSORY, RIGHT]
    ORDER_STYLE[8] = [ BODY, ARMOR, HELMET, ACCESSORY, LEFT, RIGHT]

The first section, the CONSTANT SLOTS section, lets you identify the equipment slots.  Not really hard to understand, you have five equipment slots in your game including your weapon, so the RIGHT hand is your weapon and the LEFT is typically your shield  *No suggesting left-handers, guys!!  And for convenience, I just set up a constant for the default actor sprite, the BODY slot.

The second section, the ORDER STYLE section, allows you to define the way all the graphic layers are applied based on the direction your sprite is facing. So visibly show, we have four arrays indicating if the sprite is facing down, left, right and up.  Most of the time, it would be the same... or you would ASSUME it would be the same. But when the sprite faces right (6), then the way the graphic layers are put together changes... the item (shield) in the LEFT slot is drawn first before even the character's body... so it is hidden behind the character.

Yes. This means that the graphics are updated, not only when your characters' equipment changes, but when your sprite(s) change direction. Already tested and it is quite nice.

The beginning of true layering!

More cleaning and work needs to be performed.  But after that, methinks 'sizes' may be next?

[Kain Nobel]

I learned a lot but I have to stop

Nobody can blame you. It sounds like you're attempting to come up with an extremely complicated system from scratch. I'm guilty of that as well from time to time.

An existing script would be a great source to examine. Get some experience using it, then you'll be able to figure out what you like and what you don't like. Keep notes of problems and pitfalls, draft some notes on solution proposals, then put them to the side until you're ready.

I still encourage you to keep studying and doing. Nothing beats experience. It's best to find a simpler subject to focus on then work your way up from there. Continue your studies and continue to find new challenges. Also, learn about yourself; do self audits and separate what you know from what you're unsure of and you'll be able to set a learning path that is right for you. Find your strengths and weaknesses. Be honest with yourself.

However, not all is a loss because this is still a fascinating topic that not even I'm 100% familiar with. I hope you still had a good time and were able to learn a thing or two from these posts.

Take care and have a nice day.

[DerVVulfman]

NEVER GIVE UP!   NEVER SURRENDER!!!!

No.
Redbull does NOT give you wings.
But I do.

It is still a work in progress. But yes, it is true. Your eyes do not deceive you. I took the '081-Angel03' graphic from the RPGMaker XP RTP and made a 'wings-only' graphic. The graphic is still 256x256 in size while Aluxes remains his native size of 128x192.

So as you can see, actual matching resizing and layering is working!

For compatibility sake, I still have much to accomplish. The paperdoll system works by itself or with Fukuyama's classic Train Actor system. But I wish to allow it to work with other systems as well. Who knows what character-follow system may be desired? And then there may be issues with 8 direction and/or the number of frames per character.

STILL... the entertaining work of multiple size graphics has been accomplished!