[UNOFFICIAL] Ishiiruka-Dolphin Custom Version

[Tino]

let me Answer to this.
* Speed: on older systems is faster than master
* Acuracy: is not as acurate as master yet but i'm working on it.
* Custom textures, infinitelly faster than master in handling custom textures, and support for compressed textures to allow playability in customized games.
* Support for older operative systems: xp still partially suported.
* Foucs on improve game experience over acuracy: yes lets be honest i want to play, and my kids use the original console all day, so i have only the pc left

[JMC47]

Tino: I really find it interesting that D3D9 Final is faster on older computers, but slower in pretty much every benchmark I try aside from insanely high IR stuff. Degasus said that maybe it's due to the way processors multi-thread some OGL stuff, but I really don't know.

To the other points: Accuracy won't matter for most games, so that's understandable to do a sacrifice on accuracy for personal favorites to get more speed. Custom Textures suck (for performance) in master for all intents and purposes currently, can't argue with that. It'll probably be handled in a way that's better once it's planned out.

Focus on improving game experience over accuracy: I think this is a really, really short sighted goal; that will result in a lot of issues. Look at older Dolphin versions which prioritized performance over speed. Every time they fixed something in one game, it broke something in another. You are having a little bit of issues with that here. I don't think it's a bad goal, but that's a very thin line to walk on. Wish you the best of luck, though.

[Tino]

JMC47: for you first point, of course in benchmark master will be faster, is simple because core emulation has improved a lot since my last merge of the core, so there the advantage is clear. And in the graphic area is really simple, opengl and dx11 handle state changes in a way that is more cpu consuming than dx9, our graphic emulation causes a lot of state changes, so is just plain math, with older hard cpu makes a real difference. Most of the other developers have really powerful machines so they can't see how their changes affects people with older machines.
About the final point: here you are right and wrong at the same time. you are right that short sighted goal but, in can take that path because there is a complete team of developers focusing in the other path, improving accuracy, and the quality of emulation, in that way while everyone are doing their job, i do what I like, my changes and optimization can easily be merged to master, my code day by day is becoming more like master, but from a different perspective, more optimized and focused on backward compatibility.
As I already say I’m not fighting against master, that is silly one programmer can win against a group, I’m just complementing it.

[JMC47]

Sounds like a fun goal. Hopefully everything works out like this. I'll definitely test when I can. I'm just worried about seeing the whole hack fixes causing breaks in other problems. I totally understand being able to just implement stuff in your own fork to see if it's faster, even if it's not code that could be used in master as well.

By backward compatibility, you mean Windows XP right?

[Tino]

no, i mean doing a shader generator enviroment that is capable of handling float output and integer output, xp support is really just partial because with no x86 path there will be no reason to suport xp

[JMC47]

Well, I know it's probably not a huge concern for you, but OpenGL and D3D11 really don't do much at all. Though, I don't see why people would use your branch to use OGL or D3D11.

[Tino]

JMC47: I forguet to ask, can you point what you consider hack fixes? because the latest regresions i have where just plaing coding errors of the type "please stop coding at 2 am after a long day of work".
the rest of my code is plain floating point math, and particular case optimizations.

---

The last wories me, ogl and dx11 works on my system so if that is not true for you, then I have a have a device dependant bug.

[JMC47]

I'm not pointing out anything in particular, it's just something I've seen happen throughout the years with tons of emulators. I'm not saying everything you do is a hack; please don't take it that way.

Not emulating TEV with integers is technically a hack though

[Tino]

If you have integers available, then emulating integers with floats is a hack, but if you don't have support for integers there are no alternative ways.
Technically emulation is a hack because you are implementing support for a specific architecture, in others that don't support the code natively

[JMC47]

Emulation confirmed hack, deprecate immediately.

More seriously, why work with the older architecture if it doesn't support necessary features for accurate emulation? Why not work on optimizing other parts of the graphics code and emulation? I know there are always personal reasons, but at some point benefits have to outweigh them.