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: 987
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
Super Moderator
 
Join Date: Dec 2013
Posts: 1,972
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 offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Aug 2013
Location: UK
Posts: 828
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
Super Moderator
 
Join Date: Dec 2013
Posts: 1,972
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: 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
  #7  
Old 21st July 2017, 02:41 AM
Wally123's Avatar
Wally123 Wally123 is offline
Senior Member
 
Join Date: Jul 2013
Location: Freedonia
Posts: 159
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; 21st July 2017 at 02:45 AM. Reason: Speeling...grammor
Reply With Quote
  #8  
Old 21st July 2017, 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; 21st July 2017 at 11:00 PM.
Reply With Quote
  #9  
Old 27th July 2017, 02:44 AM
Wally123's Avatar
Wally123 Wally123 is offline
Senior Member
 
Join Date: Jul 2013
Location: Freedonia
Posts: 159
Default

Quote:
Originally Posted by oddMLan View Post
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
GlideN64 wraps Voodoo3 functions (Glide3x) to OpenGL. It even says so in the mission statement on Indiegogo

https://www.indiegogo.com/projects/g...phics-plugin#/

As for the "Bloated" GUI, it is far better to have everything self contained than it is to make users install all the required components of the GUI themselves. That and it makes it more compatible with the MupenPlus core for RetroArch. I do agree with zilmar that it is a tad bloated as a plugin, but as far as being able to be used in RetroArch, IMHO it is a fair price to pay for being cross platform between Mupen and Zilmar spec plugins.
__________________
"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; 27th July 2017 at 02:49 AM.
Reply With Quote
  #10  
Old 27th July 2017, 02:55 AM
loganmc10 loganmc10 is offline
Junior Member
 
Join Date: May 2017
Posts: 5
Default

Quote:
Originally Posted by Wally123 View Post
GlideN64 wraps Voodoo3 functions (Glide3x) to OpenGL. It even says so in the mission statement on Indiegogo
No, it says that Glide64 used Glide3x. Trust me, GLideN64 doesn't wrap any functions, it is written directly in OpenGL.
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:13 PM.


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