Go Back   Project64 Forums > General Discussion > Site News

Reply
 
Thread Tools Display Modes
  #1  
Old 7th July 2017, 05:59 AM
zilmar zilmar is offline
Core Team
Alpha Tester
Project Supporter
Administrator
 
Join Date: Jun 2005
Posts: 974
Default Zilmar refuses to adopt GLideN64 and he's extremely obtuse about why (here is why!)

I am a supporter of GlideN64 and like the work they are doing but I do not seeing it getting added to project64 any time soon. I know they have been making leaps and bounds accuracy-wise and yet I still am not using it and instead going with a fork of glide64. Even tho according to some Glide64 is a crumbling pile of hacks that should have been shelved a decade ago.

I did look at the option to add GLideN64 as additional option that users could use, even if was not the default. Two major reason stop me adding it as an option.
  1. It is extremely bloated, the plugin is like 10mb, which is like double the rest of the emulator.
  2. The build process is horrible, after spending a couple hours trying to build I gave up. I did not want to add all the crap needed to build it to my build machine. (https://github.com/gonetz/GLideN64/w...ource-(Windows))
Now talking about the default plugin. When I first added glide64 the plan was to replace Jabos video plugin. I do not want Jabo's plugin being used, most cause it is closed source and can not be fixed.

But glide64 just never worked as well for me on my computer and from other people I talked to that was the same, so I did not want to make the default usage worse. For the 2.4 release I do plan to have glide64 as the default (forked as Project64-video, to stop any brand confusion).

the other point, why use glide64 as a base and not gliden64 (the names are so close, brand confusion). Why even have my own video plugin.

If i just focus on the emulator and leave the gfx to some one else, what I did back in the early days, leaving all the gfx to Jabo, then I could just use GLideN64 build it as part of the build step and move on. But if I want to actually work on it and move in a completely different direction then this causes problems with doing it on someones else's project.

My focus I want really to be on the ability for LLE, I would like to see perfect LLE video possible from the plugin, like what angrylions one does, but this I want for testing, not really for end users. Forking GLideN64 and doing the work there just causes more fragmentation and does not really help. Things like Higher system requirements as well I do not like, I can live with if I have to but I prefer to try it getting working on lower end machines (which may not be possible). The other thing with having my own fork/gfx plugin in is that I can have better integration with project64. The plugin will be designed to just work with Project64 I do not have to worry about breaking compatibility with other emulators.
Reply With Quote
  #2  
Old 7th July 2017, 07:02 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2013
Posts: 1,953
Talking

Keep up the good work my man . The scene needs a variety, not some monopoly where many users get left out..

Anyway, these negative people don't listen, so don't let them discourage you .

I will gladly devote my time into help making Project64-video better. I can help with both HLE and LLE . There needs to be a good plugin with low system requirements imo.
Reply With Quote
  #3  
Old 7th July 2017, 10:15 AM
magmarock64 magmarock64 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2009
Posts: 193
Default

Is GlideN64 in it's current state compatible with PJ64 can we add it ourselves?
Reply With Quote
  #4  
Old 7th July 2017, 01:17 PM
Frank74's Avatar
Frank74 Frank74 is online now
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Aug 2013
Location: UK
Posts: 700
Default

The HLE ucodes being done in GLideN64 can eventually be ported to Project64-Video anyway. A couple have already been ported. Rogue Squadron HLE coming soon, it's just been backed.

A few fixes/hacks have already been ported over, example the Winback square fix. Which apparently is doing what the ucode should be doing anyway, so it doesn't break anything else in the game.

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.

Last edited by Frank74; 7th July 2017 at 01:30 PM.
Reply With Quote
  #5  
Old 7th July 2017, 07:24 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2013
Posts: 1,953
Talking

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.
This should most likely be able to get ported without issues, since it's code that runs on CPU . Maybe I will look into it at some point.
Reply With Quote
  #6  
Old 8th July 2017, 01:41 AM
SuperTurboTurkeyStuffer SuperTurboTurkeyStuffer is offline
Junior Member
 
Join Date: Jul 2017
Posts: 11
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
  #7  
Old Yesterday, 02:41 AM
Wally123's Avatar
Wally123 Wally123 is offline
Senior Member
 
Join Date: Jul 2013
Location: Freedonia
Posts: 143
Default

Quote:
Originally Posted by magmarock64 View Post
Is GlideN64 in it's current state compatible with PJ64 can we add it ourselves?
You can definitely install it yourselves. The GlideN64 devs have provided various builds. zilmar, the reason it is 10MB in size is because a Glide wrapper is hard coded into the plugin's dynamic link library file. It does not wrap 3DFx Glide API to Direct X, it wraps it to OpenGL. Though I personally use nGlide for that, it helps to have the redundancy.

https://github.com/gonetz/GLideN64/releases
__________________
"I find television very educating. Every time somebody turns on the set, I go into the other room and read a book."

~Groucho Marx

Last edited by Wally123; Yesterday at 02:45 AM. Reason: Speeling...grammor
Reply With Quote
  #8  
Old Yesterday, 10:57 PM
oddMLan's Avatar
oddMLan oddMLan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2009
Location: Parappa Town
Posts: 210
Default

GLideN64 doesn't use the Glide API at all, in any shape or form. The actual reason it is 10MB is because of Qt, which is a very bloated GUI library. Compile the plugin without GUI and it's just 1.5MB

Last edited by oddMLan; Yesterday at 11:00 PM.
Reply With Quote
  #9  
Old 7th July 2017, 03:01 PM
Special Special is offline
Junior Member
 
Join Date: Apr 2015
Posts: 3
Default

Quote:
Originally Posted by zilmar View Post
But glide64 just never worked as well for me on my computer and from other people I talked to that was the same, so I did not want to make the default usage worse.
Zilmar, mind sharing your computer specs? It sounds like you run an ancient stone tablet, and who are these people you've "talked too?" it's 2017, I don't think it's a good idea to support ancient devices (within reason) anything XP and below should not even be a consideration at this point, Vista too honestly, Windows 7 should be the cut off point. The old builds aren't going away so they can use those if you so choose.
Reply With Quote
  #10  
Old 7th July 2017, 05:16 PM
RiotFire RiotFire is offline
Alpha Tester
Project Supporter
Junior Member
 
Join Date: Nov 2005
Posts: 2
Default

Speaking as a user who uses both PJ64 (development snapshots) and development versions of GlideN64, it is my favorite plugin in terms of graphics rendering. The only problem I've had which is not really plugin related was missing polygons outside the 4:3 area in Banjo-Tooie when using the 16:9 'hack' to force it to display the sides -- but I'm sure that's just the game doing that regardless. It does tend to be more resource heavy though, but not in a way that causes problems, at least for me.

Also, I use texture packs when available (using GlideN64 to load them, and not PJ64's options panel).

For verbosity in case anyone is wondering, the games I frequently play using GlideN64 and PJ64 are Banjo-Tooie, Blast Corps, Wave Race 64, and Conker's Bad Fur Day.

I have a pretty old PC compared to what's available now. I built it in 2011. CPU is like 3 generations behind and GPU even moreso.

Intel i7-2600k
AMD Radeon HD 6970 x 2 (Partial OpenGL 4.5 support, full OpenGL 4.4, no Vulkan, no DX12 -- and AMD stopped providing driver updates about a couple years ago for this and other pre-GCN cards sadly)
32 GB of DDR3 RAM (4 x 8GB)
Windows 8.1 x86-64

Just wanted to report my experience with it.

Also, I think it's awesome news that you are focusing on LLE. Thanks for your continued efforts.
__________________
4 x 8GB Corsair DDR3 RAM (32GB)
Intel i7-2600k D2 Stepping @ 4.8gHz
Asus Maximus IV Extreme-Z
AMD Radeon HD 6970 X 2 [CrossFireX]

Last edited by RiotFire; 7th July 2017 at 05:24 PM.
Reply With Quote
Reply
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 12:58 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.