Escutcheon draws every party member a plate of worked metal at run time - EscutcheonBind.js,EscutcheonCorpus.js,EscutcheonPlate.js,EscutcheonRender.js,EscutcheonScene.js
Escutcheon draws every party member a plate of worked metal at run time（Author:Core Systems Asset Factory） - EscutcheonBind.js,EscutcheonCorpus.js,EscutcheonPlate.js,EscutcheonRender.js,EscutcheonScene.js
https://en.plugin-mz.fungamemake.com/archives/12557
Escutcheon draws the party HUD for MZ as an object built at run time. There is no PNG in the package, no atlas and no windowskin, so every plate is geometry. It reads the database you already have. The plate form comes from the class archetype, derived from that class's own level 1 parameters, so two characters of one class carry the same shape because they hold the same office. The material comes from the class and the character's seniority within it. The device is struck from the character's own name, so adding somebody to the party later never restrikes ...
Plugin desc :
Escutcheon draws the party HUD for MZ as an object built at run time. There is no PNG in the package, no atlas and no windowskin, so every plate is geometry. It reads the database you already have. The plate form comes from the class archetype, derived from that class's own level 1 parameters, so two characters of one class carry the same shape because they hold the same office. The material comes from the class and the character's seniority within it. The device is struck from the character's own name, so adding somebody to the party later never restrikes ...
License :
・Copyright: Retained
・Commercial Use: Allowed
・Modification: Allowed
・Redistribution: Prohibited (This does not apply to works made using the material.)
・Details: See Download Page / In-plugin documentation
File name : EscutcheonBind.js,EscutcheonCorpus.js,EscutcheonPlate.js,EscutcheonRender.js,EscutcheonScene.js
Help of plugin :
Part 5 of 5. Load all five files. They resolve each other at FIRST USE, so
the order in the Plugin Manager does not matter (wing §8 trap 2) — this
product deliberately ships NO plugin_order.json so the headless loader and
the engine both exercise the ALPHABETICAL worst case a buyer can create.
WHAT THIS FILE ADDS
• A party HUD on the map, drawn from the furniture the other four files
generate. One card per battle member.
• Scene_Muster — a full-screen view of the whole party's furniture, opened
by a plugin command. It contains NO engine window and NO engine button.
• Plugin commands to show/hide the HUD, open the muster, and restyle the
house at runtime.
─────────────────────────────────────────────────────────────────────────────
⛔ NOTHING IN THIS PRODUCT DRAWS DURING A FRAME, AND HERE IS THE MECHANISM.
A HUD is the worst place in the engine to be expensive: it is on screen for
the entire game. One escutcheon issues well over a thousand marks, so drawing
one from an update loop would fail the MZ gate on frame one (draw calls ≤ 60,
display-object growth ≤ 4) and would keep failing forever.
The usual answer — cache the plate, redraw the bar when the value moves — is
only half an answer, because HP moves constantly and a redrawn bar is still a
redraw. So a gauge here is never redrawn at all:
Each card is baked TWICE, at construction: once with every gauge EMPTY and
once with every gauge FULL. A value is then shown by CROPPING the full
bitmap to the charge's own width and letting the empty one show through
beside it.
That works because the two bakes are identical everywhere except inside the
charge: same channel, same bezel, same caps, same material. The seam between
them is invisible, and it lands exactly where the charge ends. The charge's
gradient runs VERTICALLY (see EscutcheonPlate.P.gauge), so a column of it is
the same colour whatever the value — which is why cropping is EXACT here and
not an approximation. `Internal_Ops/_probe/crop_exact.js` measures that claim
against a genuinely re-rendered gauge rather than asserting it.
Cost of a value change: four numbers on a PIXI frame rect. No canvas work, no
allocation, no new display object.
⚠️ The crop is quantised to whole pixels ON PURPOSE. `Sprite.setFrame` only
calls `_refresh` when the rect actually changes, and `_refresh` allocates a
Rectangle — so a sub-pixel crop would allocate on every frame of a slow drain
while floor()ing to the same picture. Whole pixels make "did it change?" exact
and make the steady state allocation-free.
─────────────────────────────────────────────────────────────────────────────
⛔ TWO ENGINE FACTS THIS FILE IS BUILT AROUND, BOTH READ OUT OF THE RUNTIME
SOURCE RATHER THAN REMEMBERED (wing §8 trap 10, §23a):
1. `Sprite.prototype.destroy` passes `{ texture: true }` (rmmz_core.js:1976),
and an MZ Sprite's texture is backed by its Bitmap's baseTexture. Cards
hold SHARED, CACHED bitmaps, so letting that run would destroy the GPU
texture of a bitmap the NEXT scene is about to reuse — a blank HUD after
one trip to the menu, with nothing in a headless suite able to see it.
Sprite_EscutcheonCard therefore overrides destroy and passes
`texture: false`; PIXI propagates the option to children, so the whole
card subtree is covered by the one override.
2. `hpRate`/`mpRate`/`tpRate` are `Game_BattlerBase`, NOT `Game_Actor`
(rmmz_objects.js:3067/3071/3075). They are only ever CALLED here, never
patched — writing `Game_Actor.prototype.hpRate = ...` would shadow rather
than extend, which is wing §23a's `recoverAll` defect exactly.
`_probe/verify_method_names.js` holds both facts with controls.
─────────────────────────────────────────────────────────────────────────────
SAVE COMPATIBILITY. The house style is small, versioned data and IS saved, so
a game restyled at runtime reloads restyled. Nothing else persists: every
sprite and bitmap is rebuilt from the database on scene creation, so a save
from an older build loads without migration and a save from this build loads
in a project where the plugin was removed.
Escutcheon draws the party HUD for MZ as an object built at run time. There is no PNG in the package, no atlas and no windowskin, so every plate is geometry. It reads the database you already have. The plate form comes from the class archetype, derived from that class's own level 1 parameters, so two characters of one class carry the same shape because they hold the same office. The material comes from the class and the character's seniority within it. The device is struck from the character's own name, so adding somebody to the party later never restrikes anyone else's plate. The rim, the terminations and the temper are one house decision for the whole game, so the set always looks like a single workshop made it. There are 10 plate forms, 11 materials, 7 worked rims, 6 gauge terminations and 8 devices, 42 authored entities in total, and on the stock MZ project with no configuration at all the starting party of four resolves to four different shapes in four different metals. A HUD is on screen for the entire game, so this one does no drawing during a frame. Each card is rendered twice at construction, once with the gauges empty and once with them full, and a value is then shown by moving a crop over the full version, so changing a character's HP costs four numbers on a rectangle. Measured in the engine on the muster scene: 2 draw calls per frame, 0 texture uploads, 0 bitmap redraws and 0 display object growth over 90 frames. It extends two Scene_Map methods with the originals saved and called, and replaces none, so another plugin patching the same two keeps working. Five plugin files, no image assets, raw readable JavaScript, and load order does not matter.
AI disclosure: the code and the generated graphics are AI authored.
