{"action":"created","issue":{"url":"https://api.github.com/repos/gonetz/GLideN64/issues/748","labels_url":"https://api.github.com/repos/gonetz/GLideN64/issues/748/labels{/name}","comments_url":"https://api.github.com/repos/gonetz/GLideN64/issues/748/comments","events_url":"https://api.github.com/repos/gonetz/GLideN64/issues/748/events","html_url":"https://github.com/gonetz/GLideN64/issues/748","id":110028529,"number":748,"title":"GLideN64 current state / Project goals (Oct. 2015)","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":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-10-06T15:03:38Z","updated_at":"2015-10-06T23:47:30Z","closed_at":null,"body":"This should give an impression of the current state of GLideN64 (how I see it). There are many things that can be done. I must admit it would take years to achieve all of this but maybe some goals can be reached at some point. I think GLideN64 should move in this direction. Feel free to agree/disagree.\r\n\r\n* framebuffer: implement accurate framebuffer emulation (copy to RDRAM). The current framebuffer emulation method should just be a performance hack\r\n* N64 depth compare: Too slow and has synchronisation issues. Barely usable currently\r\n* pixel coverage: not emulated\r\n* CPU reads/writes to/from color/depth buffer: dolphin found a good solution to this but it's probably hard to implement. But I'm pretty sure this can't be solved properly without the emulator's help\r\n* VI: pretty much complete\r\n* Noise: pretty much complete but some performance issues\r\n* mip-mapping: looks perfect in Perfect Dark few problems in other games. This can not be perfect because of hardware limitations? Maybe only per game settings can help here.\r\n* blender: implement shader based blending\r\n\r\nHLE: \r\n* missing microcodes: T3DEX (Last Legion UX, Virtual Pro Wrestling), Battle for Naboo, Indiana Jones, Rogue Squadron, Stunt Racer, WDC (same microcode?)\r\n* games use modified microcodes(?): Hey you Pikachu, Blast Corps, Winback, Turok Engine games (point lightning)\r\n\r\nLLE:\r\n* implement fog\r\n* mip-mapping not working\r\n* bad performance (compared to z64gl)\r\n\r\nadditional tasks:\r\n* fix bugs/remove hacks\r\n* fix problems with deprecated legacy code\r\n* lower hardware requirements and disable functionality if not supported\r\n* optimize\r\n* anything else?\r\n"},"comment":{"url":"https://api.github.com/repos/gonetz/GLideN64/issues/comments/146036071","html_url":"https://github.com/gonetz/GLideN64/issues/748#issuecomment-146036071","issue_url":"https://api.github.com/repos/gonetz/GLideN64/issues/748","id":146036071,"user":{"login":"AmbientMalice","id":10704701,"avatar_url":"https://avatars.githubusercontent.com/u/10704701?v=3","gravatar_id":"","url":"https://api.github.com/users/AmbientMalice","html_url":"https://github.com/AmbientMalice","followers_url":"https://api.github.com/users/AmbientMalice/followers","following_url":"https://api.github.com/users/AmbientMalice/following{/other_user}","gists_url":"https://api.github.com/users/AmbientMalice/gists{/gist_id}","starred_url":"https://api.github.com/users/AmbientMalice/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/AmbientMalice/subscriptions","organizations_url":"https://api.github.com/users/AmbientMalice/orgs","repos_url":"https://api.github.com/users/AmbientMalice/repos","events_url":"https://api.github.com/users/AmbientMalice/events{/privacy}","received_events_url":"https://api.github.com/users/AmbientMalice/received_events","type":"User","site_admin":false},"created_at":"2015-10-06T23:47:30Z","updated_at":"2015-10-06T23:47:30Z","body":"A think the biggest, most pressing FB issue is the fact there's something wrong with the framebuffer emulation that breaks PAL games and causes crashes for a wide range of games if FB to texture is used. Crashes are bad.\r\n\r\n>N64 depth compare: Too slow and has synchronisation issues. Barely usable currently\r\n\r\nIt's a wildly inconsistent performance hog. I wouldn't call it \"barely usable\" since it does work fairly well for certain titles, but the sudden performance dips and the fact it breaks a lot of titles means it needs work.\r\n\r\n>pixel coverage: not emulated\r\n\r\nI have a vague idea of what pixel coverage is in a normal graphics context, but I'm still unclear on how an N64 emulator would implement pixel coverage and make use of it.\r\n\r\n>blender: implement shader based blending\r\n\r\nThis would *potentially* fix a remarkable number of bugs, and would be a massive leap forward for N64 emulation. I guess it's just a matter of someone biting the bullet and coding the thing.\r\n\r\nLLE doesn't just have bad performance - it crashes like crazy with FB enabled, has broken depth buffer, and fails to render particles and other 2D objects in a lot of games.\r\n\r\nThe other thing likely covered under \"fix bugs/remove hacks\" is GLideN64's texture bugs. Stuff like https://github.com/gonetz/GLideN64/issues/471 affects a LOT of games.\r\n\r\nThere's also super weird stuff like Starcraft 64's backgrounds that don't render unless you load a save state."}}