| カテゴリ | 重要度 | ステータス | 解決状況 | 登録日時 | 最終更新 |
|---|---|---|---|---|---|
 グラフィック | 低 | 仮承認 | 未処理 | 2025-01-02 07:34 | 2025-01-03 17:24 |
| テスター | ywy | 担当者 | ソース | taito/taito_f3.cpp | |
| バージョン | 0.273 | 発生バージョン | 修正バージョン | ||
| 修正コミット | プルリク | ||||
| フラグ | 実機・資料検証済み, コード検証済み | ||||
| セット | gseeker | ||||
| セット詳細 |
 gseeker - グリッドシーカー (Ver 1.3O) | ||||
| 概 要 | 5面ボスの爆発スプライトが消えない。 | ||||
| 詳 細 | version: since forever. write it down so you don't forget. screenshot of gseeker manifestation in https://github.com/mamedev/mame/pull/11811#issuecomment-2098804995 usually sprite limit doesn't matter because sprite commands are cleared properly. grid seeker has bad behavior where a burst of sprite allocations during the stage 5 boss explosion causes an explosion in the number of sprites, which get stuck. | ||||
| 再現手順 | |||||
| 追加情報 | taito f3 has 2 sprite command banks with capacity for 2048 sprite commands each. however, the TC0630FDP interprets fewer than 1024 sprite commands per frame. the second block within each bank tends to be unused but can be rendered with a [jump] sprite command, (also some games (pbobble4) write checksum code into the sprite list and execute it around POST time) usually sprite limit does not matter because games track sprite handles and spriteram commands are cleared properly. grid seeker has bad behavior where a burst of sprite allocations during the stage 5 boss explosion causes an explosion in the number of sprites some of these overflowing sprites seem to be leaked and not freed properly. on hardware, the uncleared sprites, which can start around command # 958, are not rendered. this sprite rendering limit was known to taito: many games have a bankswitch or infinite loop sprite command well before command # 1023. this is the approximate arrangement on grid seeker: - commands 0-52: 'header' area, contains global sprite control commands, bankswitch setup. - commands 53-886: normal sprite commands. grid seeker does not use jumps. - command 887: end-of-bank bankswitch command. if this were a loop like later games, the bug wouldn't appear. - commands 888-957: unexpected, but usually cleared. - commands 958-1037+: overflow, usually leaked and uncleared. attached is a screenshot with the sprite command ram represented on the left of the screen, after the explosion animation resolves. banks 1 and 2 are shown side-by-side. each red dot is one sprite command. command 887 is the green dot near the middle. the white lines are rulers at 1016 and 2040. during the explosion, sprites are drawn throughout the command list, before clearing them, leaving only necessary sprites (player ship, etc.) -- and the leaked sprites around the end of the buffer. because the game writes these sprites to both banks, and sprite interpretation continues after bankswitch, we continue drawing. unlike hardware, we currently interpret up to 1024 sprite commands. we measured sprite rendering limits on cartridge-based f3 hardware: - last known fully rendered sprite at command 863 - first known unrendered sprite at command 883 this is close to taito's 'end of bank' position, and within the safe range for grid seeker. ! the behavior in between these two points is strange: - sprites 864-882 will render with partial rows of missing pixels in them. - sprite 879 will have the top half visible, up to the missing pattern. - sprites 879-882 sometimes show up alone on the next frame. the sprite limit is unaffected by the number of visible/rendered sprites, and is just a limit on the number of slots that are processed. we plan to reduce the sprite command limit to 882, after checking the limits as known to other f3 titles. | ||||
| 添付ファイル |  gseeker-explosion-annotated.png (2025-01-02 07:34) | ||||
| pb4-partial-sprites-864.png (2025-01-02 07:41) | |||||