View Single Post
  #6  
Old 8th July 2017, 01:41 AM
SuperTurboTurkeyStuffer SuperTurboTurkeyStuffer is offline
Junior Member
 
Join Date: Jul 2017
Posts: 16
Default

Quote:
Originally Posted by Frank74 View Post
The only thing that might be a problem is accurate N64 software depth buffer. Required for Body Harvest collision detection. RDB should probably say Use GLideN64 if it's not possible to fix.
GLideN64 has a more accuracy hardware depth buffer that has some serious problems, so it has essentially been mothballed. Gonetz fell back on the Glide64 software depth buffer. It's a lot faster because there's no RAM/VRAM syncing, and it's accurate enough for most purposes.

Body Harvest was fixed by a massive VI/framebuffer refactor where Gonetz completely rewrote how the plugin handles video interface emulation and calculates framebuffer sizes. This had a plethora of positive effects including fixing height calculation for PAL games, and fixing an endless list of games where buffers were written at the wrong size to RAM, resulting in graphical corruption, crashes, or odd behavior.

GLideN64 is doing a lot of things accurately/mostly accurately that Glide64 handles via broken heuristics and hacks. Resident Evil 2, for example, emulates near perfectly on GLideN64 because GLideN64 can correctly calculate buffer sizes. Glide64 can't. And I don't think it ever will, without resorting to a massive rewrite in which case the reality presents itself -- why completely rewrite this plugin? Self-education and improvement aside, why so much effort for something that will never be as good as GLideN64?

Gonetz abandoned Glide64 because it was a dead end. Even though using gln64 as a base was a dubious decision, it allowed GLideN64 to improve so many areas of accuracy. GLideN64 is more accurate than Nintendo's own VC in places.

Also, I see people talk about how Glide64 is ostensibly "faster" than GLideN64. As though we're all gonna ignore how we turned off framebuffer to RAM on pretty much every game because it was prohibitively expensive. (Perfect Dark is a mess on Glide64.) GLideN64 is the exact opposite. FB to RAM is enabled for everything, pretty much, because it's a huge accuracy improvement that doesn't destroy performance like it does on Glide64.

Quote:
Originally Posted by zilmar View Post
the way the code is being refactored the wrapper basically becomes a backend which means it is already separated with backends, having 2, ogl and ogl es. If I wanted to do I could then use Angle for that, or write a native D3D one.

Lots of complaints I see about N64 emulation being bad is often unsupported gfx card features, I fear taking up like Gliden64 as the default while it will make it better for some, maybe the majority, It will make it worse for others. There is already enough complaints that N64 emulation is really bad with out making it worse for a group of people, (a lot larger group then what is effected by using glide64 or jabo's plugin)
There will always be people complaining. You can't please everyone. Some people believe that N64 emulators shouldn't require hardware any more advanced than UltraHLE used. This is delusional, but what can you do? GLideN64 was refactored earlier this year to remove direct API use. There's nothing stopping the creation of a DX11 or Vulkan backend for the plugin.

I would argue that the negative reputation of N64 emulation stems more from pretty everything being broken on Jabo/Glide64, than from a small and vocal minority who don't see any need for N64 emulation to meaningfully improve. If you're going to really improve CPU/RSP emulation, for example -- perhaps removing the COUNT hack -- you are going to piss off these people who care more about extreme legacy hardware than basic accuracy. They'll accept any hack, no matter how dirty, before they'll accept accuracy improvements that carry a performance penalty.

Last edited by SuperTurboTurkeyStuffer; 8th July 2017 at 02:12 AM.
Reply With Quote