Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #41  
Old 18th May 2015, 02:00 AM
Ambient_Malice Ambient_Malice is offline
Senior Member
 
Join Date: Dec 2014
Posts: 179
Default

GLideN64 has suffered from poor priorities and management. For example, GLideN64 does not need bloom. GLideN64 does not need Dolphin's shader system. The only shader it truly needs is a post-processing AA method, preferably SMAA.

GLideN64 needs:
Broken LLE to be fixed. (Muh Turok. Muh Indiana Jones.)
An HLE software renderer/alternate fix for Snap/Body Harvest/etc.

LLE is an absolute mess. As a side effect, low level polygon stuff such as skies are broken in HLE, too.
Reply With Quote
  #42  
Old 18th May 2015, 02:39 AM
p_025 p_025 is offline
Member
 
Join Date: Oct 2008
Posts: 49
Default

Like I said, in practice, GLideN64 didn't quite turn out the way it ought to have. And I agree that postprocessing shaders are very unnecessary. That being said, I'm glad it's as good as it is, and I'm glad it's open source. Perhaps there will be enough interest to help development.
Reply With Quote
  #43  
Old 18th May 2015, 03:11 AM
Ambient_Malice Ambient_Malice is offline
Senior Member
 
Join Date: Dec 2014
Posts: 179
Default

I'm vaguely annoyed that the HLE dynamic lighting problems in Turok 2, Turok 3, and Armorines have been known for basically over a decade, yet basically zero effort has gone into fixing them.

This is what happens, I suppose, when HLE emulation relies on wonky reverse engineered ucodes that almost nobody can be bothered studying. (I suspect the missing lighting is ucode related, since it works perfectly in all LLE renderers.)
Reply With Quote
  #44  
Old 18th May 2015, 05:19 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Talking

I think some end users have unrealistic expectations. It's like people want a cycle accurate + pixel accurate + hd graphics + full speed !
Quote:
Originally Posted by p_025 View Post
That's all well and good, the problem (for me) is when a pixel accurate plugin is the only option, which means I can't use a certain enhancement I enjoy. For example, until very recently Jabo's video was the only one I knew of that had a widescreen hack. Wanna play this game that only works on Rice (for example)? TOO BAD SUCKAH, you either get big black bars on both sides of the screen, or stretchy graphics.

Wanna play this game that needs a pixel accurate plugin? I hope you like playing games in 240i.
There's always a price to pay, can't have everything. I feel like the demands are too heavy these days, hence why I believe some devs have poor priorities. I admit I do prefer high-res graphics. At the same time, in some cases, it's best to use a software render, due to the many challenges. For instance, I get better performance with Angrylion's plugin in some games, than I do with z64gl ;/ . It's nice to have a plugin where you don't have to deal with any known accuracy issues.

Someone just needs to optimize it.
Quote:
Originally Posted by p_025 View Post
Much of my interest in N64 emulation lately is due to netplay (so I am quite interested in fixing Fixed Audio Timing (or watching the progress of it anyway)). I liked GLideN64's approach. Shoot to be as accurate as you can and add complicated hacks and enhancements later. Though in practice I don't think he spent long enough on accuracy/compatibility. Still, it's good work.
Feel free to compile latest source, or download binary from emucr or someone.
Quote:
Originally Posted by Ambient_Malice View Post
GLideN64 has suffered from poor priorities and management. For example, GLideN64 does not need bloom. GLideN64 does not need Dolphin's shader system. The only shader it truly needs is a post-processing AA method, preferably SMAA.
I have to agree with this. I'd much rather see the remaining unsupported games get implemented in HLE.
Quote:
Originally Posted by Ambient_Malice View Post
GLideN64 needs:
Broken LLE to be fixed. (Muh Turok. Muh Indiana Jones.)
It needs to be more optimized too .
Quote:
Originally Posted by Ambient_Malice View Post
An HLE software renderer/alternate fix for Snap/Body Harvest/etc.
Would be cool to see an accurate HLE software renderer, but aint nobody got the time for that . It's too much.
Quote:
Originally Posted by Ambient_Malice View Post
I'm vaguely annoyed that the HLE dynamic lighting problems in Turok 2, Turok 3, and Armorines have been known for basically over a decade, yet basically zero effort has gone into fixing them.

This is what happens, I suppose, when HLE emulation relies on wonky reverse engineered ucodes that almost nobody can be bothered studying. (I suspect the missing lighting is ucode related, since it works perfectly in all LLE renderers.)
Much to my surprise, Gonetz doesn't really know the RSP too well. He was looking for an RSP expert, due to problems with Zelda MM.
Reply With Quote
  #45  
Old 18th May 2015, 07:41 AM
N64man N64man is offline
Junior Member
 
Join Date: Jun 2010
Posts: 25
Default

Quote:
cycle accurate + pixel accurate + hd graphics + full speed
I can imagine only several variants of it as possible: cycle accurate + full speed, cycle accurate + pixel accurate(for 2D) + full speed. Something like it.

- cycle accurate: dont sure right, but if it means work as on real console so, it will be good to emulate in reasonable limits(not like DICE for example or byuu's thoughts - http://arstechnica.com/gaming/2011/0...snes-emulator/ ).

- pixel accurate: I think it have point for 2D games and 2D elements. Plus text, probably.

- hd graphics: I see the point in high resolutions(more 640x480) only. HD packs in my opinion dont needed. Something like Doom source ports(Zandronum, for example), higan and DOSBox without any upscales except hardware2x, hardware3x.

- full speed: I think, the reason is obvious.

And agree with code optimization(and probably not code only).
Reply With Quote
  #46  
Old 18th May 2015, 02:08 PM
p_025 p_025 is offline
Member
 
Join Date: Oct 2008
Posts: 49
Default

Quote:
Originally Posted by RPGMaster View Post
Feel free to compile latest source, or download binary from emucr or someone.
Well I did compile the PJ64 source from a fresh Github checkout, not sure what I was thinking I could do with it, but there it is. I could do the same for the GLideN64 plugin, but same problem.

Not sure why you brought it up, really, does the source at the moment have fixes not included in the public release update? I was under the impression he was prioritizing GLES 2.0 support.
Reply With Quote
  #47  
Old 18th May 2015, 06:58 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Talking

Quote:
Originally Posted by p_025 View Post
Well I did compile the PJ64 source from a fresh Github checkout, not sure what I was thinking I could do with it, but there it is. I could do the same for the GLideN64 plugin, but same problem.

Not sure why you brought it up, really, does the source at the moment have fixes not included in the public release update? I was under the impression he was prioritizing GLES 2.0 support.
I actually just meant PJ64 . There have been some good improvements, since the release in April 1st .
Reply With Quote
  #48  
Old 18th May 2015, 09:56 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by RPGMaster View Post
For instance, I get better performance with Angrylion's plugin in some games, than I do with z64gl ;/ .
Got any examples of this?
Reply With Quote
  #49  
Old 18th May 2015, 10:48 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by HatCat View Post
Got any examples of this?
With z64gl, some menus are ridiculously slow, like in SD Hiryuu no Ken. Regular gameplay is still a bit faster on my end with Angrylion's with filters off. I'm sure at least part of the problem is my hardware.

In games like Rogue Squadron, z64gl has a higher max VI/s, but it dips below 60 more often than Angrylions for some reason ;/ . Of course I'm using 4MB and not 8MB though.
Reply With Quote
  #50  
Old 18th May 2015, 11:06 PM
p_025 p_025 is offline
Member
 
Join Date: Oct 2008
Posts: 49
Default

Quote:
Originally Posted by RPGMaster View Post
I actually just meant PJ64 . There have been some good improvements, since the release in April 1st .
Oh, well in that case I may pull the latest changes and check it out. I've avoided using the builds I've produced since using the same core is so important to netplay, and I haven't been sending new builds to my friends.

Netplay is finnicky enough as it is right now, with a quirky input plugin workaround. I'm surprised it works at all. But it's a pleasant surprise.
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 09:02 AM.


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