02-19-2023, 04:00 AM
(This post was last modified: 02-19-2023, 04:29 AM by DerVVulfman.)
I would DEFINITELY not use Viewports. Viewports are like panes of glass... one atop the other. For this, allow me to illustrate.
The map system is divided into three viewports already
Viewport 1: The Map tiles and panorama viewport
Viewport 2: The pictures (from Show Picture) is atop that
Viewport 3: This handles the flash effect alone
Relatively speaking, the z-Depth of Viewport 1 is defaulted to a depth of 0, Viewport 2 to a depth of 200 and Viewport 3 to 5000. And yes, the sprites within Viewport 1 can be set to a wide variety of z-Depths. But these sprites only have a z-Depth within in Viewport 1 alone. A sprite, be it a tree or hero, at a Z-Depth of 300 within Viewport 1 will never be drawn over the depth of Viewport 2.
Also...
If you were to create a separate viewport for visual graphics and had this layer atop Viewport 1, you would likely show the graphics atop the trees from whatever position you were. And if your custom viewport were below (good luck with that), then the custom graphics would not be very visible.
Now it's MAGIC time....
ALL... paperdoll systems, and I prefer the term because of its historic connotations, rely upon layering to be sure. But moreso, they also create or recreate the character's sprite only when triggered. So when your hero is walking about, nothing happens. However, when something is given to them within their Equip menu, a trigger is pulled and the character sprite system looks and then redraws accordingly. And ONLY then it performs the redraw, so no lag should ever be equated with a paperdoll system. And since it is creating, or re-creating the sprite, from the layers, there is no need to deal with a layer's z-depth.
Now for some drawbacks to older systems....
Most all assume that the principle character (the hero) is drawn first and every graphic is drawn atop. This works most of the time for clothing or armor if a rigid setup. But there is nothing drawn behind the hero... so cloaks behind the hero can be problematic depending upon the armor, dress or garments worn.
For that, you would want a layering system that would know to layer the cloak first, the hero, the clothes, the armor atop, and so on.
And THEN, you have another issue... Layer direction. Assuming the fore-mentioned hero is facing you, the cloak would be drawn first, and then the hero. But if the hero is facing away, the cloak would be the last item rendered. This I know too well. As JayRay mentioned, I created a version of my ABS with a paperdoll system... and it does take character facing direction into consideration. It wasn't easy, but it did.
And then, character 'size' difference... you may want to have a feature in the paperdoll system to recognize certain shirts' or 'wings' for different heroes based on their size. You may have a hero named Kim who is the normal sized character. Then, you can have Keiko being an unusually tall fighter. For her, you may wish to have a separate wings given the name 'wings_keiko.png'. You would need to have the paperdoll system check to see if wings_keiko exists of course. But this is a feature I personally looked into.
And I won't talk about the fun with dual weapons... TOO LATE!!!
The map system is divided into three viewports already
Viewport 1: The Map tiles and panorama viewport
Viewport 2: The pictures (from Show Picture) is atop that
Viewport 3: This handles the flash effect alone
Relatively speaking, the z-Depth of Viewport 1 is defaulted to a depth of 0, Viewport 2 to a depth of 200 and Viewport 3 to 5000. And yes, the sprites within Viewport 1 can be set to a wide variety of z-Depths. But these sprites only have a z-Depth within in Viewport 1 alone. A sprite, be it a tree or hero, at a Z-Depth of 300 within Viewport 1 will never be drawn over the depth of Viewport 2.
Also...
If you were to create a separate viewport for visual graphics and had this layer atop Viewport 1, you would likely show the graphics atop the trees from whatever position you were. And if your custom viewport were below (good luck with that), then the custom graphics would not be very visible.
Now it's MAGIC time....
ALL... paperdoll systems, and I prefer the term because of its historic connotations, rely upon layering to be sure. But moreso, they also create or recreate the character's sprite only when triggered. So when your hero is walking about, nothing happens. However, when something is given to them within their Equip menu, a trigger is pulled and the character sprite system looks and then redraws accordingly. And ONLY then it performs the redraw, so no lag should ever be equated with a paperdoll system. And since it is creating, or re-creating the sprite, from the layers, there is no need to deal with a layer's z-depth.
Now for some drawbacks to older systems....
Most all assume that the principle character (the hero) is drawn first and every graphic is drawn atop. This works most of the time for clothing or armor if a rigid setup. But there is nothing drawn behind the hero... so cloaks behind the hero can be problematic depending upon the armor, dress or garments worn.
For that, you would want a layering system that would know to layer the cloak first, the hero, the clothes, the armor atop, and so on.
And THEN, you have another issue... Layer direction. Assuming the fore-mentioned hero is facing you, the cloak would be drawn first, and then the hero. But if the hero is facing away, the cloak would be the last item rendered. This I know too well. As JayRay mentioned, I created a version of my ABS with a paperdoll system... and it does take character facing direction into consideration. It wasn't easy, but it did.
And then, character 'size' difference... you may want to have a feature in the paperdoll system to recognize certain shirts' or 'wings' for different heroes based on their size. You may have a hero named Kim who is the normal sized character. Then, you can have Keiko being an unusually tall fighter. For her, you may wish to have a separate wings given the name 'wings_keiko.png'. You would need to have the paperdoll system check to see if wings_keiko exists of course. But this is a feature I personally looked into.
And I won't talk about the fun with dual weapons... TOO LATE!!!