{"action":"closed","issue":{"url":"https://api.github.com/repos/gonetz/GLideN64/issues/618","labels_url":"https://api.github.com/repos/gonetz/GLideN64/issues/618/labels{/name}","comments_url":"https://api.github.com/repos/gonetz/GLideN64/issues/618/comments","events_url":"https://api.github.com/repos/gonetz/GLideN64/issues/618/events","html_url":"https://github.com/gonetz/GLideN64/issues/618","id":95795957,"number":618,"title":"framebuffer area in RDRAM is not filled with correct data","user":{"login":"purplemarshmallow","id":7283660,"avatar_url":"https://avatars.githubusercontent.com/u/7283660?v=3","gravatar_id":"","url":"https://api.github.com/users/purplemarshmallow","html_url":"https://github.com/purplemarshmallow","followers_url":"https://api.github.com/users/purplemarshmallow/followers","following_url":"https://api.github.com/users/purplemarshmallow/following{/other_user}","gists_url":"https://api.github.com/users/purplemarshmallow/gists{/gist_id}","starred_url":"https://api.github.com/users/purplemarshmallow/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/purplemarshmallow/subscriptions","organizations_url":"https://api.github.com/users/purplemarshmallow/orgs","repos_url":"https://api.github.com/users/purplemarshmallow/repos","events_url":"https://api.github.com/users/purplemarshmallow/events{/privacy}","received_events_url":"https://api.github.com/users/purplemarshmallow/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-07-18T06:38:22Z","updated_at":"2015-11-10T03:29:04Z","closed_at":"2015-11-10T03:29:04Z","body":"GLideN64 is able to fill framebuffer area in RDRAM with a single color (fill RDRAM option). Experiments with different fillcolors suggest that it's necessary to fill RDRAM with correct data (write framebuffer texture into RDRAM) to make GLideN64's validity checking work correctly.\r\n\r\nZelda OOT:\r\nHere's some information from the forum, Gonetz investigated validity checking in Zelda OOT\r\n>I started to investigate and found weirdest thing. As I described, the game uses auxiliary buffer for Link’s model. Plugin writes small portion of test pixels (fingerprint) to the beginning of the buffer area to detect when the game will overwrite that fingerprint, and mark buffer as invalid. To my surprise, when I pressed start to open subscreen, then at some moment, which happen outside of the plugin (that is in the emulator’s thread) the buffer data below my fingerprint changed. That is for some reason CPU decided to write something to the buffer, but below my fingerprint. Validity check marked the buffer as invalid and I lost Link’s model.\r\nOK, I filled the whole frame buffer area with the test value and this time the buffer remained intact until the moment when I closed subscreen. Then frame buffer area was filled with the original data, validity check detected that data change and marked buffer as invalid. That is, if I fill the whole buffer with some value everything works fine. Otherwise, CPU spoils my buffer with irrelevant data and shit happens.\r\n\r\nfill RDRAM does not always work, I tested different colors. It only works with the default fillcolor (black), if I change the fillcolor it does not work, validity check removes Link's model. My guess is that the game checks data in RDRAM and writes incorrect data there if this check fails. The black color tricks the game, I guess the game \"thinks\" there's Link's model because this image is mostly black.\r\nedit: I tested more colors and some colors work for this game, some colors don't\r\n\r\nPokemon Stadium 2:\r\nusing a different fillcolor fixes one problem with validity checking but causes a different problem at another point in the game. This supports my theory\r\n"}}