big bug squash (#261)

src/render/HudTiles.lua

@@ -77,7 +77,17 @@ end
 -- one-pixel sliver.  The fill is tinted with the SGB bar palettes at
 -- GetHealthBarColor's thresholds (>= 27 px green, >= 10 yellow, else
 -- red).
-function HudTiles.drawHPBar(data, tx, ty, mon, barType)
+--
+-- grayFill (#229): when the caller will colorize this bar with an SGB
+-- region palette (BattleState's zone pass, BATTLE_ZONES pal 0/1 =
+-- GetHealthBarColor), leave the fill as its raw DMG shade-2 gray and skip
+-- the per-pixel tint -- the DMG hardware bar is ONE gray shade recolored by
+-- the region palette (engine/gfx/palettes.asm SetPal_Battle,
+-- data/sgb/sgb_packets.asm BlkPacket_Battle), never a per-pixel repaint.
+-- Tinting first would double-apply the color: GREENBAR's fill {0,189,0} has
+-- red channel 0, so the tint zeroes the whole bar's red and the zone's
+-- red-channel-keyed shade shader then maps every pixel to color 3 = black.
+function HudTiles.drawHPBar(data, tx, ty, mon, barType, grayFill)
   local x, y = tx * 8, ty * 8
   HudTiles.tile(0x71, x, y)
   HudTiles.tile(0x62, x + 8, y)
@@ -86,15 +96,17 @@ function HudTiles.drawHPBar(data, tx, ty, mon, barType)
     px = math.max(1, math.floor(mon.hp * 48 / mon.stats.hp))
   end
   local tint
-  local PaletteFX = require("src.render.PaletteFX")
-  local name = px >= 27 and "GREENBAR" or px >= 10 and "YELLOWBAR" or "REDBAR"
-  local colors = PaletteFX.pal(data, name)
-  if colors then
-    local c = colors[3] -- GB color 2 is the fill shade
-    -- the fill pixels are the 2/3-gray shade; divide so they land on
-    -- the palette color exactly (the black outline stays black)
-    tint = { math.min(1, c[1] / 170), math.min(1, c[2] / 170),
-             math.min(1, c[3] / 170), 1 }
+  if not grayFill then
+    local PaletteFX = require("src.render.PaletteFX")
+    local name = px >= 27 and "GREENBAR" or px >= 10 and "YELLOWBAR" or "REDBAR"
+    local colors = PaletteFX.pal(data, name)
+    if colors then
+      local c = colors[3] -- GB color 2 is the fill shade
+      -- the fill pixels are the 2/3-gray shade; divide so they land on
+      -- the palette color exactly (the black outline stays black)
+      tint = { math.min(1, c[1] / 170), math.min(1, c[2] / 170),
+               math.min(1, c[3] / 170), 1 }
+    end
   end
   for i = 0, 5 do
     local seg = math.min(8, math.max(0, px - i * 8))

src/render/PaletteFX.lua

@@ -50,14 +50,23 @@ PaletteFX.GBC_OBJ = {
 }
 
 -- OG BLUE: Pokemon Blue's Game Boy Color boot-ROM auto-palette.  Same
--- one-global-pair scheme as OG RED (Blue also ships no CGB code), but the
--- boot ROM colorizes the background blue instead of red -- so "OG RED" for a
--- Blue playthrough is white -> light blue -> dark blue -> black, mirroring
--- GBC_BG channel-for-channel so the blue reads at the same brightness.  The
--- OBJ (sprite) palette stays the same green, matching how Red and Blue share
--- the green-character look on a Game Boy Color.
+-- one-global-pair scheme as OG RED (Blue also ships no CGB code), but the boot
+-- ROM gives Blue its OWN entry rather than a recolored Red: a light-blue/blue
+-- BACKGROUND and -- unlike Red -- a PINK object palette (OBP0).  Values from
+-- Bulbapedia's "List of color palettes ... Generation I" GBC boot-ROM table
+-- (BG 0x63A5FF/0x0000FF, OBJ 0xFF8484/0x943A3A), confirmed against a Gambatte
+-- hardware capture.  The earlier code mirrored GBC_BG channel-for-channel
+-- (0x8484FF/0x3A3A94) and reused Red's green sprites for both versions on the
+-- premise that Red and Blue "share the green-character look"; both premises
+-- are wrong -- Blue's background is a genuinely different blue and its
+-- characters are pink (#155).  Lightest shade first, like GBC_BG.
 PaletteFX.GBC_BG_BLUE = {
-  { 255, 255, 255 }, { 132, 132, 255 }, { 58, 58, 148 }, { 0, 0, 0 },
+  { 255, 255, 255 }, { 99, 165, 255 }, { 0, 0, 255 }, { 0, 0, 0 },
+}
+-- Blue's OBJ palette (OBP0) is the red/pink ramp -- the very same colors OG
+-- RED uses for its BACKGROUND (GBC_BG), just applied to objects instead.
+PaletteFX.GBC_OBJ_BLUE = {
+  { 255, 255, 255 }, { 255, 132, 132 }, { 148, 58, 58 }, { 0, 0, 0 },
 }
 
 -- The active game's OG boot-ROM background palette: blue for a Blue
@@ -69,6 +78,16 @@ function PaletteFX.ogBg()
   return PaletteFX.GBC_BG
 end
 
+-- The active game's OG boot-ROM object palette (OBP0): Blue's pink ramp for a
+-- Blue playthrough, Red's green otherwise.  Returns the colors AND a
+-- version-distinct cache-group string, because SpriteRenderer.getObpImage keys
+-- its baked-image cache by (image path, group): a shared group would collide a
+-- Red bake with a Blue one and one version would show the other's colors.
+function PaletteFX.ogObj()
+  if GameVersion.isBlue() then return PaletteFX.GBC_OBJ_BLUE, "gbcobj_blue" end
+  return PaletteFX.GBC_OBJ, "gbcobj"
+end
+
 local INV_MAP = { [0] = 3, [1] = 2, [2] = 1, [3] = 0 }
 
 function PaletteFX.shader()
@@ -183,17 +202,25 @@ function PaletteFX.usesGbcPack(mode)
 end
 
 -- Whether the active mode bakes a per-OBJ palette onto overworld sprites
--- (the OBP bake + post-zone redraw path).  ONLY OG RED does: it wears the
--- GBC boot-ROM green object palette (PaletteFX.GBC_OBJ) so the player and
--- NPCs stay green over the red background, exactly like Pokemon Red on a
--- Game Boy Color.  SGB mode deliberately does NOT: an SGB OBJ carries no
--- palette of its own, so the characters tint with the whole-map region
--- palette along with the terrain (the Super Game Boy never colored Pokemon
--- Red's sprites separately -- baking a per-sprite palette there was the
--- "reds coloring on the player/NPCs" bug).  RED++ colors sprites through
--- the usesGbcPack() path in SpriteRenderer instead.
+-- (the OBP bake + post-zone redraw path).  OG RED and SGB both do: characters
+-- wear the GBC boot-ROM object palette (PaletteFX.ogObj -- green over Red's red
+-- background, pink over Blue's blue background), so the player and NPCs carry a
+-- fixed object color instead of tinting with whatever region palette their
+-- feet stand over.  On real hardware a sprite is an OBJ colored by an OBJ
+-- palette (color/sprites.asm ColorOverworldSprite), distinct from the BG it
+-- overlaps -- so Red's cap must stay green in tall grass, not turn the ROUTE
+-- palette's light-blue (issue #150: SGB region-tinting sent the cap to shade-2
+-- = light-blue and the character clashed with the grass it should blend into).
+-- Terrain is unaffected -- pal() below still hands SGB its per-map BG palette;
+-- only OG RED short-circuits BG to the one global red palette.  An EARLIER
+-- attempt at per-sprite SGB color baked GBC_BG (the RED background ramp) onto
+-- characters -- that was the "reds coloring on the player/NPCs" bug; the object
+-- palette is GBC_OBJ (green), so baking it here is the fix, not that
+-- regression.  RED++ colors sprites through the usesGbcPack() path in
+-- SpriteRenderer instead.
 function PaletteFX.usesSpriteObp(mode)
-  return (mode or PaletteFX.mode) == "ogred"
+  mode = mode or PaletteFX.mode
+  return mode == "ogred" or mode == "gbc"
 end
 
 -- ------- post-zone sprite redraw (GBC mode)

src/render/Renderer.lua

@@ -46,18 +46,30 @@ Renderer.UPRIGHT_MARGIN = 160
 -- non-square "pixels", and movement judder (issue #87).  Always derive the
 -- crisp integer scale from the drawable pixel size; draw with (pixels/dpi)
 -- so the GPU lands on whole framebuffer pixels.  Desktop dpi=1 is unchanged.
+--
+-- `dpi` here must be the factor LOVE actually applies to every draw call
+-- (getDPIScale), NOT the drawable/unit size ratio pw/ww.  On a normal device
+-- those are equal (getPixelDimensions == getDimensions * getDPIScale), but on
+-- the AYN Thor dual-screen surface in forced landscape they diverge: LOVE
+-- reports pw/ww ≈ 1 while its real transform is 1.5, so scaling by pw/ww lands
+-- each GB pixel on Sp*(getDPIScale/(pw/ww)) physical pixels -- a fractional,
+-- stretched/non-square count (issue #208).  Prefer getDPIScale so draws land
+-- on whole physical pixels through LOVE's actual transform; fall back to pw/ww
+-- (then 1) only when getDPIScale is unavailable.  Since getDPIScale == pw/ww
+-- on every normal device, #87's behavior is byte-identical there.
 local function displayMetrics()
   local ww, wh = love.graphics.getDimensions()
   local pw, ph = ww, wh
   if love.graphics.getPixelDimensions then
     pw, ph = love.graphics.getPixelDimensions()
   end
-  local dpi = 1
-  if ww > 0 and pw > 0 then
-    dpi = pw / ww
-  elseif love.graphics.getDPIScale then
+  local dpi
+  if love.graphics.getDPIScale then
     dpi = love.graphics.getDPIScale()
   end
+  if (not dpi or dpi < 1e-6) and ww > 0 and pw > 0 then
+    dpi = pw / ww
+  end
   if not dpi or dpi < 1e-6 then dpi = 1 end
   return ww, wh, pw, ph, dpi
 end
@@ -99,6 +111,18 @@ function Renderer:fitScale()
   return math.max(1, math.floor(math.min(pw / self.WIDTH, ph / self.HEIGHT)))
 end
 
+-- The LOVE-unit draw scale endFrame uses for the UI blit: the integer
+-- framebuffer scale (fitScale) divided by the live coordinate->pixel factor,
+-- so a GB pixel lands on fitScale() whole PHYSICAL pixels once LOVE applies
+-- its own transform (fitScale() == drawScale() * dpi).  Exposed so #208's
+-- regression can assert GB pixels stay square on divergent-DPI surfaces
+-- without reaching into endFrame's locals; endFrame recomputes the same value
+-- inline (`S = Sp / dpi`).
+function Renderer:drawScale()
+  local _, _, _, _, dpi = displayMetrics()
+  return self:fitScale() / dpi
+end
+
 -- world-pass canvas size in world pixels: enough to fill the window at s'.
 -- In tilt mode the canvas grows (both dimensions, by Tilt.viewGrowth) so
 -- the projected ground plane still covers the whole window with no

src/render/SpriteRenderer.lua

@@ -105,7 +105,10 @@ function SpriteRenderer:resolveImage()
     local colors, group = PaletteFX.spriteObp(self.def, self.seed)
     if colors then return getObpImage(self.def.image, colors, group) end
   elseif PaletteFX.usesSpriteObp() then
-    return getObpImage(self.def.image, PaletteFX.GBC_OBJ, "gbcobj")
+    -- OG boot-ROM OBJ palette: green on Red, pink on Blue (PaletteFX.ogObj
+    -- returns colors + a version-distinct cache group so the two never
+    -- collide in obpCache) -- see issue #155
+    return getObpImage(self.def.image, PaletteFX.ogObj())
   end
   return self.image
 end
@@ -141,11 +144,13 @@ function SpriteRenderer:draw(px, py, camX, camY, facing, walkPhase, stepFlip)
       image = getObpImage(self.def.image, colors, group)
     end
   elseif PaletteFX.usesSpriteObp() and PaletteFX.spriteRedrawPassActive() then
-    -- OG RED (GBC boot-ROM look): every OBJ wears the one global green
-    -- object palette.  The red BG zone shader still runs over the world
-    -- canvas, so the baked sprite is queued for a post-zone redraw
-    -- (PaletteFX.markSpriteRedraw) that restores its green pixels on top.
-    image = getObpImage(self.def.image, PaletteFX.GBC_OBJ, "gbcobj")
+    -- OG RED (GBC boot-ROM look): every OBJ wears the one global object
+    -- palette -- green over Red's red background, pink over Blue's blue
+    -- background (PaletteFX.ogObj, #155).  The BG zone shader still runs over
+    -- the world canvas, so the baked sprite is queued for a post-zone redraw
+    -- (PaletteFX.markSpriteRedraw) that restores its object-colored pixels on
+    -- top.
+    image = getObpImage(self.def.image, PaletteFX.ogObj())
     redraw = true
   end
   -- single-frame sprites (item balls, fossils...) have one fixed pose;