I have a humble request, Tino. Can you implement the 3D options in Ishiiruka? 3D Vision is bugged without them since 4.0-4480. Since that build, increasing convergence made the HUD, shadows and other effects go away to the sides. Nvidia tried to correct it with the 347.52 drivers (Dolphin now has a profile), and it made the HUD and other effects stay in their correct place, but it made a new bug appear (super incorrect depth in the ground near the camera). Playing with 3D Vision enabled in the Dolphin options is now the most correct and bugless way to play in 3D in recent builds.
I love your builds and thank you very much for them
.
(03-06-2015, 10:08 PM)masterotaku Wrote: [ -> ]I have a humble request, Tino. Can you implement the 3D options in Ishiiruka? 3D Vision is bugged without them since 4.0-4480. Since that build, increasing convergence made the HUD, shadows and other effects go away to the sides. Nvidia tried to correct it with the 347.52 drivers (Dolphin now has a profile), and it made the HUD and other effects stay in their correct place, but it made a new bug appear (super incorrect depth in the ground near the camera). Playing with 3D Vision enabled in the Dolphin options is now the most correct and bugless way to play in 3D in recent builds.
I love your builds and thank you very much for them .
Thanks
.
Is not that i don't want to is just my lack of time. i just whant to stabilize and fix some issues before i move to implemente 3d support.
Nice. v293 works without issues (no black screens or crashes).
So Ishiiruka is now using the correct fallback for vertex loaders instead of trying to use unsupported instruction sets (S-SSE3 and newer) on older CPUs.
This is why I really like the idea of Open Source.
You don't need to be a software developer to contribute to a project.
Even advanced users with very little or no programming experience can browse / look at the source, find and debug issues.
P.S. A lot of Ishiiruka and master/dev build users are still waiting for this feature:
https://forums.dolphin-emu.org/Thread-skip-efb-access-from-cpu-hotkey
the problem was not that they where trying to use incorrect instruction sets, the error was that in machines that have no ssse3 support the code was trying to access the fallback member of the translator, but the translator itself was the falback so m_traslator member was null and there you have a beautifull crash
.
yup opensource projects are the best, you have a ton of reviewers and testers and that is priceless for the development projects.
Anyone else having a strange issue with Rogue Leader? The top half of the screen gets frozen for a second then moves on... starts already at the Lucas Arts dancing trooper intro. Doesn't happen with master.
It's not totally new; I already had it a few days ago, but I thought it had something to do with those other issues that have been fixed now.
Thanks for fixing that crash issue, sorry i wasnt able to explain the config, but yes i am using ini per game.
(03-07-2015, 02:21 AM)Tino Wrote: [ -> ]Is not that i don't want to is just my lack of time. i just whant to stabilize and fix some issues before i move to implemente 3d support.
OK, thanks. Just knowing that it's in plans is comfortingÂ
 .
Is anyone else using DX9? I thought its faster than DX11 but why is that so and why was it dropped in official builds?Â
dx9 is not faster than dx11, dx9 is less cpu consuming so in lower spec machines it will run faster than dx11, but with a better cpu dx11 uses the gpu far better than dx9 so you will get better framerate at higher IR. It was dropped in master because they consider that is was holding back the other backends, I considered that that was not necesarry true, it was just neccesary a little more work to keep compatibility.
my idea is simple, i will keep it as long as it is usefull for someone
(03-09-2015, 12:34 AM)Tino Wrote: [ -> ]dx9 is not faster than dx11, dx9 is less cpu consuming so in lower spec machines it will run faster than dx11, but with a better cpu dx11 uses the gpu far better than dx9 so you will get better framerate at higher IR. It was dropped in master because they consider that is was holding back the other backends, I considered that that was not necesarry true, it was just neccesary a little more work to keep compatibility.
my idea is simple, i will keep it as long as it is usefull for someone
I have a i5 4210U and a GTX 850M, I think its not low end but not high spec either. I tested it with Twilight Princess Wii 1080p without framerate limit I get 132% when looking at the entire Gerudo Desert in DX11 and 165% in DX9, so it's quite a improvement for me and I don't see any graphical benefits too. Should I have to worry, I mean the API won't be  supported anymore so it won't get updates for bugs? Or does fixing graphical bugs in new dolphin builds apply for all APIs?Â
I want to thank you for your builds too. The option fast EFB access really helps a lot. In the official builds with Gamecube games I have Skip EFC access always active since it does nothing but improves FPS and of course I get fullspeed in every situation in the most demanding GC games so thats cool. In Wii games however, I have to disable it since it has problems with IR, and of course because of that I have lower FPS. Games like Super Mario Galaxy are still playable but not always fullspeed, however with fast EFB and DX9 in your builds they remain to have full speed in every situation with the pointer working. So thanks! You should be part of the official dolphin team!
A question, I think DX12 will be revolutionary for emulating since it reduces CPU overhead dramatically. Will dolphin official or your future builds use DX12? Also, Haswell and Broadwell are supporting AVX2, can you integrate it in your build or is it not possible?
Thanks!