{"action":"created","issue":{"url":"https://api.github.com/repos/gonetz/GLideN64/issues/1047","repository_url":"https://api.github.com/repos/gonetz/GLideN64","labels_url":"https://api.github.com/repos/gonetz/GLideN64/issues/1047/labels{/name}","comments_url":"https://api.github.com/repos/gonetz/GLideN64/issues/1047/comments","events_url":"https://api.github.com/repos/gonetz/GLideN64/issues/1047/events","html_url":"https://github.com/gonetz/GLideN64/issues/1047","id":163563616,"number":1047,"title":"Ogre battle, wrong texrects.","user":{"login":"standard-two-simplex","id":12202580,"avatar_url":"https://avatars.githubusercontent.com/u/12202580?v=3","gravatar_id":"","url":"https://api.github.com/users/standard-two-simplex","html_url":"https://github.com/standard-two-simplex","followers_url":"https://api.github.com/users/standard-two-simplex/followers","following_url":"https://api.github.com/users/standard-two-simplex/following{/other_user}","gists_url":"https://api.github.com/users/standard-two-simplex/gists{/gist_id}","starred_url":"https://api.github.com/users/standard-two-simplex/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/standard-two-simplex/subscriptions","organizations_url":"https://api.github.com/users/standard-two-simplex/orgs","repos_url":"https://api.github.com/users/standard-two-simplex/repos","events_url":"https://api.github.com/users/standard-two-simplex/events{/privacy}","received_events_url":"https://api.github.com/users/standard-two-simplex/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":51,"created_at":"2016-07-03T14:05:28Z","updated_at":"2016-08-21T13:55:18Z","closed_at":null,"body":"Ogre battle has a few texrects that are incorrectly displayed.\r\n\r\nGLideN64\r\n![ogrebattle64-000](https://cloud.githubusercontent.com/assets/12202580/16545711/83be0e26-4133-11e6-823b-d9063a29e77c.png)\r\n\r\nGLideN64, with dsdx and dtdy values hacked.\r\n![ogrebattle64-003](https://cloud.githubusercontent.com/assets/12202580/16545713/95a1c678-4133-11e6-83bc-d920bc3ba65e.png)\r\n\r\nThe problematic textures are related to the text box (see first picture):\r\n 1 - The small on the left, too short.\r\n 2 - The big one in the middle, wrong color in the bottom.\r\n 3 - The small one on the right, the curve is slightly wrong.\r\n 4 - The triangular shaped one, the bottom is wrong.\r\n\r\nAfter some testing, I noticed that if dsdx and dtdy are force to 1, the textures display correctly. This makes me think that the problem lies with the texture mapping. I measured the dsdx and dtdy values in _TexRect(u32 w0, u32 w1, bool flip) in RDP.cpp. The results are given in s5.10 fixed point format / floating point format.\r\n\r\n 1 - dsdx: 0x0491 / 1.141602, dtdy: 0x0410 / 1.015625 \r\n 2 - dsdx: 0x0403 / 1.002930, dtdy: 0x0410 / 1.015625  \r\n 3 - dsdx: 0x0465 / 1.098633, dtdy: 0x0410 / 1.015625 \r\n 4 - dsdx: 0x0491 / 1.141602, dtdy: 0x0454 / 1.082031 \r\n\r\nThese are weird values. Normally, a game designer would use integers or inverses of integers, so the value has a logical meaning (number of texture texel per number of screen pixel). I have only seen this types on number for animations where a rectangle shrinks.\r\n\r\nAs for why a N64 renders correctly, here are a few theories I can think of:\r\n -  There might be some condition under which the N64 ignores the dsdx, dtdy values given by the display list and uses 1. I have read the documentation and tried many things, with no success whatsoever.\r\n - dsdx and dtdy might be supposed to be masked. Those rectangles need a mask of 0xFF00, i.e. use only the topmost 8 bits (s5.2 fixed point) and rest 0, to behave correctly. However, paper mario needs at least the topmost 10 bits. Unless this mask is specified by a register and be chosen by the game designer, it doesn't seem likely to be happening.\r\n - For some reason the plugin has wrong dsdx, dtdy values. This would mean that the w2 and w3 are wrong, which I believe they come from the display list. I don't understand _getTexRectParams() though.\r\n\r\n@gonetz What's your opinion on this regard?\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/gonetz/GLideN64/issues/comments/241259067","html_url":"https://github.com/gonetz/GLideN64/issues/1047#issuecomment-241259067","issue_url":"https://api.github.com/repos/gonetz/GLideN64/issues/1047","id":241259067,"user":{"login":"standard-two-simplex","id":12202580,"avatar_url":"https://avatars.githubusercontent.com/u/12202580?v=3","gravatar_id":"","url":"https://api.github.com/users/standard-two-simplex","html_url":"https://github.com/standard-two-simplex","followers_url":"https://api.github.com/users/standard-two-simplex/followers","following_url":"https://api.github.com/users/standard-two-simplex/following{/other_user}","gists_url":"https://api.github.com/users/standard-two-simplex/gists{/gist_id}","starred_url":"https://api.github.com/users/standard-two-simplex/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/standard-two-simplex/subscriptions","organizations_url":"https://api.github.com/users/standard-two-simplex/orgs","repos_url":"https://api.github.com/users/standard-two-simplex/repos","events_url":"https://api.github.com/users/standard-two-simplex/events{/privacy}","received_events_url":"https://api.github.com/users/standard-two-simplex/received_events","type":"User","site_admin":false},"created_at":"2016-08-21T13:55:18Z","updated_at":"2016-08-21T13:55:18Z","body":"I was reviewing your implementation of the idea and realized that I had overlooked something. I hadn't noticed that you set texrect dimensions as texture coordinates and then multiplied that with delta. It is a clever idea because you can more or less control how the rasterizer will set the texture coordinates for a pixel: it will be in the middle of the pixel more or less.\r\n\r\nBy applying a floor and using the texelFetch() function you had in comments (instead of texture which was giving some accuracy issues), I managed to make a clean implementation of the point sample case. It seems quite accurate compared with the correction method. The downside is that I had to implement clamping, mirroring and wrapping of the texture coordinate manually before calling texelFetch(), so I needed to pass the tile attributes as uniforms.\r\n\r\nI need to clean the code, make it available for tile 1 as well and refactor a little bit so that the bilinear cases (standard or 3 point) can easily be derived. I think that using texelFetch() instead of texture() will help that case as well. I'll try to upload this code by tuesday. "}}
{"actor":{"display_login":"standard-two-simplex"}}