{"action":"created","issue":{"url":"https://api.github.com/repos/project64/project64/issues/72","labels_url":"https://api.github.com/repos/project64/project64/issues/72/labels{/name}","comments_url":"https://api.github.com/repos/project64/project64/issues/72/comments","events_url":"https://api.github.com/repos/project64/project64/issues/72/events","html_url":"https://github.com/project64/project64/issues/72","id":57283783,"number":72,"title":"Bug in GFX plugin spec. implementation","user":{"login":"Fanatic-64","id":10682703,"avatar_url":"https://avatars.githubusercontent.com/u/10682703?v=3","gravatar_id":"","url":"https://api.github.com/users/Fanatic-64","html_url":"https://github.com/Fanatic-64","followers_url":"https://api.github.com/users/Fanatic-64/followers","following_url":"https://api.github.com/users/Fanatic-64/following{/other_user}","gists_url":"https://api.github.com/users/Fanatic-64/gists{/gist_id}","starred_url":"https://api.github.com/users/Fanatic-64/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Fanatic-64/subscriptions","organizations_url":"https://api.github.com/users/Fanatic-64/orgs","repos_url":"https://api.github.com/users/Fanatic-64/repos","events_url":"https://api.github.com/users/Fanatic-64/events{/privacy}","received_events_url":"https://api.github.com/users/Fanatic-64/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2015-02-11T07:11:02Z","updated_at":"2015-02-15T23:27:53Z","closed_at":null,"body":"Re-reading Gonetz's GLideN64 blog I noticed this bit:\r\n>Technically, emulation of CPU rendering is easy. Image to display is stored in RDRAM, its address is known. The image is just loaded as texture to video card and rendered as full screen rectangle. The problem is the same as with CPU based fb effects: graphics plugin does not know that CPU started rendering by itself, emulator does not notify the plugin about it. **To be honest, plugin's specification has the function for such notification, but it almost never works.** Thus, plugin can’t rely on emulator’s help.\r\n\r\nIt would be nice if the function to notify the graphics plugin that the CPU has begun writing to the color framebuffer was fixed. It would allow correct emulation of such instances (which currently relies on a hack), and frankly it's a bit embarrassing that Project64 doesn't have a fully correct implementation of Zilmar's specification.\r\n\r\nAnd by the way, would it be hard to document the 1.7+ plugin specs (Audio 1.2, GFX 1.4, Input, 1.2, RSP 1.2)?\r\n\r\nEDIT: It appears this is the function in the spec that needs fixing:\r\n>/******************************************************************\r\n  Function: ShowCFB\r\n  Purpose:  Useally once Dlists are started being displayed, cfb is\r\n            ignored. This function tells the dll to start displaying\r\n\t\t\tthem again.\r\n  input:    none\r\n  output:   none\r\n*******************************************************************/ \r\n>EXPORT void CALL ShowCFB (void);"},"comment":{"url":"https://api.github.com/repos/project64/project64/issues/comments/74443543","html_url":"https://github.com/project64/project64/issues/72#issuecomment-74443543","issue_url":"https://api.github.com/repos/project64/project64/issues/72","id":74443543,"user":{"login":"project64","id":4994272,"avatar_url":"https://avatars.githubusercontent.com/u/4994272?v=3","gravatar_id":"","url":"https://api.github.com/users/project64","html_url":"https://github.com/project64","followers_url":"https://api.github.com/users/project64/followers","following_url":"https://api.github.com/users/project64/following{/other_user}","gists_url":"https://api.github.com/users/project64/gists{/gist_id}","starred_url":"https://api.github.com/users/project64/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/project64/subscriptions","organizations_url":"https://api.github.com/users/project64/orgs","repos_url":"https://api.github.com/users/project64/repos","events_url":"https://api.github.com/users/project64/events{/privacy}","received_events_url":"https://api.github.com/users/project64/received_events","type":"User","site_admin":false},"created_at":"2015-02-15T23:27:53Z","updated_at":"2015-02-15T23:27:53Z","body":"from Gonetz:\r\n\r\n>Do you have an option to be writing back to the rdram and what is the penalty\r\nActually yes. There are options to copy depth buffer and frame buffer from video card to RDRAM. I tried to make these operations as fast as possible and I don't see performance penalty on my PC. You may check how fast they work on your system.\r\n\r\nRegarding help from emu side: 1964 introduced set of extension functions\r\nEXPORT void CALL FBRead(wxUint32 addr)\r\nEXPORT void CALL FBWList(FrameBufferModifyEntry *plist, wxUint32 size)\r\nEXPORT void CALL FBWrite(wxUint32 addr, wxUint32 size)\r\nEXPORT void CALL FBGetFrameBufferInfo(void *p)\r\nwhich should help video plugin to get information when the game is going to read/write to frame buffer area and either render FB to screen or copy video card's frame buffer to RDRAM.\r\nI could not get any use from that extension in 1964. Hacktarux also implemented these functions in Mupen64 and it helped to emulate some effects without speed drop. But it did not always work. Hacktarux explained that it is very hard to track frame buffer access because it can be done from many places. Again, we played with these functions when AGP was in use, because read from AGP was slow. Today I enable both depth and color buffer copy without noticeable speed drop."}}