Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[Maintenance] [th01] Endings: Reclassify the ドカーン image tearing issue as a bug 

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.
This commit is contained in:
nmlgc 2023-04-23 16:14:54 +02:00
parent 0b13967de3
commit 308b6bcd2c
3 changed files with 11 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
CONTRIBUTING.md
View File

@ -415,7 +415,8 @@ only the subset of issues they care about.
When categorizing such issues, first ask whether a fix could be <a When categorizing such issues, first ask whether a fix could be <a
id="observable" href="#observable">🔗 observed</a>: Would it change any of the id="observable" href="#observable">🔗 observed</a>: Would it change any of the
individual frames rendered by the game, as defined by the original frame delay 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 ### Categories

9
th01/end/end.cpp
View File

@ -211,7 +211,7 @@ void pascal near shake_then_boom(int shake_duration, int boom_duration)
end_pic_show_and_delay(1, 2); end_pic_show_and_delay(1, 2);
if(i & 1) { 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, // z_vsync_wait_and_scrollup() function used in REIIDEN.EXE,
// master.lib's graph_scrollup() doesn't wait for VSync, causing // master.lib's graph_scrollup() doesn't wait for VSync, causing
// this image to immediately be overwritten with pic #1 on the next // 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 // usual slowness of PC-98 VRAM, you'll still end up seeing at
// least parts of the "boom"/"ドカーン" image even on faster PC-98 // least parts of the "boom"/"ドカーン" image even on faster PC-98
// systems before it's fully overwritten on the next iteration. // 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); end_pic_show(2);
} else { } else {
// And why are we re-showing the same pic here? Redundant, // And why are we re-showing the same pic here? Redundant,

2
th01/end/pic.cpp
View File

@ -23,7 +23,7 @@ void end_pic_show(int quarter)
vram_word_amount_t vram_x; vram_word_amount_t vram_x;
pixel_t y; 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 // total of ((320 / 16) × 200 × 2) = 8000 VRAM page switches, which are
// everything but instant. Even the optimal assembly instructions for a // everything but instant. Even the optimal assembly instructions for a
// *single* page switch, `MOV AL, (0|1)` followed by `OUT 0xA6, AL`, take // *single* page switch, `MOV AL, (0|1)` followed by `OUT 0xA6, AL`, take