|
|
![]() |
|
Thread Tools | Display Modes |
#51
|
||||
|
||||
![]()
I have some performance examples with GLideN64 of scaling at an excessive multiple of resolution such as 8x (albeit in a smaller 1024x768 window) that shows a type of place where it needs to be optimized.
This example can be compared to my issue post for Android rendering fullscreen at even a mere 4x multiple of resolution from the following issue post from around a year ago... https://github.com/gonetz/GLideN64/issues/1052 Here is both at an excessive 8x multiple (just to test) of Banjo-Tooie in front of a fire torch in the Treasure Chamber's top entrance within Mayahem Temple like I did on Android. Take note these are in Sync mode since Async runs even better now but still kinda lags so I thought Sync would be a better example. Tests are done on "GLideN64 rev cd8783b" which is at least newer than the public release. The first image is at a distance showing the object tested and its running pretty decently from it being 8x scaled. https://drive.google.com/open?id=0B1...jJQN3NlTEFBQ1k This next image below is the performance (look at GFX) when zoomed into that single fire torch. https://drive.google.com/open?id=0B1...XhSaHB3UHlrS3M A whopping 79% usage on GFX due to how a multiple scale of resolution impacts the performance. Granted,this is caused specifically by blending which is done via shading. With even the fastest settings on enabled frame buffer like disabled video card buffer copies to N64 and even with color buffer swaps using Recompiler (although without either cache setting enabled) it gets pretty slow by going a few frames below 30fps in a simple spot when zoomed into that single fire torch. When disabling framebuffer and torturously getting back to the area,it doesn't cause any lag at all when zoomed in. (neither does legacy blending) It probably gets much slower with the 60fps code (8007913F 0001) active. I will likely test again with a later build of PJ64 like I should've used to begin with to be more relevant,but I was requested to post these images in particular. Also should've got results with Async in pictures,but it was decent at a distance and only around 40% GFX usage when zoomed in,so conveniently cutting usage in half though still slowing down a little just below 30fps. Edit: Forgot to say that it reaches almost exactly that same amount around 81% usage on Async and 84% on Sync when viewing the large section of Hailfire Peaks (Icy Side) from in front of the oil rig ledge,the most natively laggy part of the game I could find. Making it not copy video card buffers to N64 has it at 70-77% usage. https://drive.google.com/open?id=0B1...TRKaFpXN1pwVjQ So,that tiiiiny single fire torch object has the same excess usage as a massive area being viewed at a great distance. Last edited by retroben; 10th July 2017 at 01:45 AM. |
#52
|
|||
|
|||
![]() Quote:
Quote:
Quote:
I assume performance is okay with the legacy blender? If so, it's not really a flaw, so much as a limitation of mobile hardware that has to be worked around with a less accurate blender. |
#53
|
||||
|
||||
![]() Quote:
![]() How should it be solved? Quote:
Quote:
|
#54
|
||||
|
||||
![]()
Vulkan can achieve better performance with lower overhead which would really help GLideN64 perform better if implemented well enough.
|
#55
|
|||
|
|||
![]() Quote:
Replace Jabo's audio with Azimer's plugin as soon as possible. I am inclined to think that in the case of the MORT/MusyX games, your PR was not at fault, and Jabo's audio plugin is at fault. People deserve good quality audio. N64 games deserve good quality audio. Azimer's seems like the best path, and although N64 audio is not computationally expensive, Azimer's HLE mode could be useful for low-end systems. As much as I love Cen64, I'm not convinced that kind of backwards compatibility was of any real benefit to the project as a whole. If anything, there's been a bit of false hope regarding how viable Cen64 will be on anything but very high end hardware. But that's a very debatable subject because there real significance of Cen64 IMO is its CPU/RSP accuracy, not its graphics emulation. Last edited by SuperTurboTurkeyStuffer; 10th July 2017 at 06:46 AM. Reason: added RPGMaster response |
#56
|
||||
|
||||
![]() Quote:
I do feel that higher priority should go towards ensuring good audio. I've tried to push my view in the past, but it seemed like a lot of people disagreed with me about the crackling and they seemed to feel like the audio was good where it was at. So I just kept to myself after that and would just offer advice to people who actually wanted better audio. Part of the problem was that development on Azimer's plugin seems to be relatively slow and then there's the fact that popular opinion among PJ64's fanbase, seems to be that Jabo's is fine/good enough. I agree with your standpoint regarding HLE audio. Not much of a performance boost, but I personally do find HLE coding to be fun ![]() Quote:
![]() Anyway, I get that low end hardware users will have more limited options. It's not like I expect pixel perfect emulation with OpenGL 1.5 or anything. I just think that there's still plenty of room for improvement for low-end hardware users. Rather than saying "forget them, they have no chance anyway", I'd rather at least attempt to make their experience better. Especially considering not everyone is playing one of those difficult games like Body Harvest or even Mario Tennis. Honestly I find it fun to challenge myself sometimes. |
#57
|
||||
|
||||
![]() Quote:
As for sound, it's a mixed bag, I like Azimer's way better for Konami games, Jabo's sound causes micro stuttering on my end, maybe because I use Realtek Audio with XAudio2, I don't know. Azimer however, works perfectly on all my Konami games. Clay Fighter, Killer Instinct, etc.
__________________
My rig: CPU: Intel Core i7 4470 3.4 GHz to 3.9 GHz Video card:: MSI nVidia GTX 970 4 GB GDDR5 OS: Windows 7 Professional 64-bit RAM: 16 GB DDR3 SDRAM 10600 HDD: 2 x Western Digital 1 TB HDDs Monitor: 23" Asus Full HD LED Oh, and Snes9x > Zsnes in every way |
#58
|
||||
|
||||
![]() Quote:
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 |
#59
|
||||
|
||||
![]()
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. |
#60
|
||||
|
||||
![]() Quote:
__________________
"I find television very educating. Every time somebody turns on the set, I go into the other room and read a book." ~Groucho Marx |