View Single Post
  #3  
Old 18th August 2017, 05:44 AM
zilmar zilmar is offline
Core Team
Alpha Tester
Project Supporter
Administrator
 
Join Date: Jun 2005
Posts: 988
Default

Quote:
Originally Posted by HatCat View Post
Voted for:

You've mentioned this before and I still have no idea what you're really talking about.

If angrylion's RDP does the LLE in software and z64gl/GlideN64/"PJ64Video" do the LLE in hardware then I don't really see what's missing or being requested here.

Maybe you're saying PJ64 Glide doesn't have LLE. If it doesn't then what's the point of having a software LLE implementation as accurate as angrylion's inside of PJ64 Glide64 when the two code bases are entirely inverted? If you were saying make a LLE version somehow based off PJ64 Glide's HLE code, that would make more sense. But just taking something as accurate as angrylion's RDP and putting that in for the LLE mode of PJ64 Video is just putting 2 DLLs in 1...the purpose of an LLE implementation of PJ64 Video should be to have something similar enough to the HLE one to the point where it is at least the same plugin in both cases, if anything so the HLE can be debugged using the LLE.

Project64 video has a version of LLE processing based on z64. It does not work very well.

I am talking about two versions of LLE processing, one using hardware and one using software. The software version should be similar to angry lions version and write to the rdram. The hardware version should use OGL and be more similar to the current LLE implementation/hle version.
Reply With Quote