From 308b6bcd2cf6704134e7c7b836472ef7ecd410f5 Mon Sep 17 00:00:00 2001 From: nmlgc Date: Sun, 23 Apr 2023 16:14:54 +0200 Subject: [PATCH] =?UTF-8?q?[Maintenance]=20[th01]=20Endings:=20Reclassify?= =?UTF-8?q?=20the=20=E3=83=89=E3=82=AB=E3=83=BC=E3=83=B3=20image=20tearing?= =?UTF-8?q?=20issue=20as=20a=20bug?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit And explicitly define observability in terms of an infinitely fast PC-98. That's the only reasonable assumption to make when considering ports to faster architectures that aren't bottlenecked by disappointing blitter chips. Part of P0239, funded by Ember2528. --- CONTRIBUTING.md | 3 ++- th01/end/end.cpp | 9 ++++++++- th01/end/pic.cpp | 2 +- 3 files changed, 11 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 240f1f79..bcddd948 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -415,7 +415,8 @@ only the subset of issues they care about. When categorizing such issues, first ask whether a fix could be πŸ”— observed: Would it change any of the individual frames rendered by the game, as defined by the original frame delay -boundaries? +boundaries? Assume that these frames are rendered by an infinitely fast PC-98 +that will never add additional lag frames on top. ### Categories diff --git a/th01/end/end.cpp b/th01/end/end.cpp index a9f1f303..a592aeb6 100644 --- a/th01/end/end.cpp +++ b/th01/end/end.cpp @@ -211,7 +211,7 @@ void pascal near shake_then_boom(int shake_duration, int boom_duration) end_pic_show_and_delay(1, 2); if(i & 1) { - // ZUN quirk: No delay after rendering this image. Unlike the + // ZUN bug: No delay after rendering this image. Unlike the // z_vsync_wait_and_scrollup() function used in REIIDEN.EXE, // master.lib's graph_scrollup() doesn't wait for VSync, causing // this image to immediately be overwritten with pic #1 on the next @@ -222,6 +222,13 @@ void pascal near shake_then_boom(int shake_duration, int boom_duration) // usual slowness of PC-98 VRAM, you'll still end up seeing at // least parts of the "boom"/"ドカーン" image even on faster PC-98 // systems before it's fully overwritten on the next iteration. + // + // Technically this could be considered a quirk, as the resulting + // frame drops affect the length of the ending. On the other hand, + // we explicitly judge observability in terms of an infinitely fast + // PC-98. Such a system would consequently never show this image + // that ZUN clearly intended to show, thus turning this into the + // exact definition of a bug. end_pic_show(2); } else { // And why are we re-showing the same pic here? Redundant, diff --git a/th01/end/pic.cpp b/th01/end/pic.cpp index 5203f87b..716e05db 100644 --- a/th01/end/pic.cpp +++ b/th01/end/pic.cpp @@ -23,7 +23,7 @@ void end_pic_show(int quarter) vram_word_amount_t vram_x; pixel_t y; - // ZUN quirk: This EGC-"accelerated" copy operation ends up performing a + // ZUN bloat: This EGC-"accelerated" copy operation ends up performing a // total of ((320 / 16) Γ— 200 Γ— 2) = 8000 VRAM page switches, which are // everything but instant. Even the optimal assembly instructions for a // *single* page switch, `MOV AL, (0|1)` followed by `OUT 0xA6, AL`, take