Hello Tino,
thank you (and the other developers) for your amazing work!
Your Ishiiruka Version is the only one i can use on my HTPC with an i3 2100 (not overclocked)!
Some games need "trial & error" in the configuration to run them smooth, but after that its like using a real GC/Wii.
(Sorry for my bad english, its not my native tongue)
Greets,
Dedales
(02-26-2015, 12:11 AM)Dedales Wrote: [ -> ]Hello Tino,
thank you (and the other developers) for your amazing work!
Your Ishiiruka Version is the only one i can use on my HTPC with an i3 2100 (not overclocked)!
Some games need "trial & error" in the configuration to run them smooth, but after that its like using a real GC/Wii.
(Sorry for my bad english, its not my native tongue)
Greets,
Dedales
thanks to you for reporting back, if you have more info in games that where dificult to you to tweak please post it so other users can take benefit from your experience.
Hi, first i'd like to thank you for that dolphin fork.
I have a question about F ZERO pal, i tried the first cup but the game rebooted after the third race with those settings:
![[Image: qRfm2Kn.jpg]](http://i.imgur.com/qRfm2Kn.jpg)
Dual core and idle skip are checked too.
Is there something wrong ?
the build is the 271(5575151)
Nothing wrong, f-zero is a great example of some things that still are not correctly emulated. f-zero send some big fifos to the graphic pipeline, and then it controls the time they take, if something takes longer that what is spected it restart the game, with predictive fifo and wait for shader compilation the effects of the reset are reduced to a minimun in the case they are caused by shader cache miss but there are still some situattions when the time consumed in a specific fifo is long and then the reset happends. Please test using full async shaders and predictive fifo and let me know if the issue persists.
@ morgoth32: Dude, the internet almost burst when you posted that picture
Ok thanks for info.
PS: image will be smaller next time i post =)
To be honest, the endless bugginess of this project and Tino having so much trouble fixing them, makes me worry about the viability of this project. I get the feeling that it can only get worse if the codebase is already so damaged compared to normal Dolphin.
Looking from an outside perspective, I would restart development, because Ishiiruka contains scores of strange bugs, and has been that way for months. How did they get introduced in the first place? I (subjectively) feel like this branch's code is lower quality, judging from how many strange unsolvable bugs there are.
The lack of continuous testing (due to being a secondary branch, and no pull-request system) (how are Ishiiruka-specific changes reviewed?) may explain the bugginess.
(02-26-2015, 04:23 AM)jimbo1qaz Wrote: [ -> ]To be honest, the endless bugginess of this project and Tino having so much trouble fixing them, makes me worry about the viability of this project. I get the feeling that it can only get worse if the codebase is already so damaged compared to normal Dolphin.
Looking from an outside perspective, I would restart development, because Ishiiruka contains scores of strange bugs, and has been that way for months. How did they get introduced in the first place? I (subjectively) feel like this branch's code is lower quality, judging from how many strange unsolvable bugs there are.
The lack of continuous testing (due to being a secondary branch, and no pull-request system) (how are Ishiiruka-specific changes reviewed?) may explain the bugginess.
Well, it's under active development so it's only natural that regressions happen. It's not a standard fork as tino is manually merging upstream changes so perhaps certain things got omitted. It's difficult to keep track and dissect individual commits this way so perhaps rebasing and backing out certain changes would help. It would also be easier for dolphin devs to review the code. It's up to tino though.
(02-26-2015, 04:23 AM)jimbo1qaz Wrote: [ -> ]To be honest, the endless bugginess of this project and Tino having so much trouble fixing them, makes me worry about the viability of this project. I get the feeling that it can only get worse if the codebase is already so damaged compared to normal Dolphin.
Looking from an outside perspective, I would restart development, because Ishiiruka contains scores of strange bugs, and has been that way for months. How did they get introduced in the first place?
I (subjectively) feel like this branch's code is lower quality, judging from how many strange unsolvable bugs there are.
The lack of continuous testing (due to being a secondary branch, and no pull-request system) (how are Ishiiruka-specific changes reviewed?) may explain the bugginess.
What bugs exactly? Don't just take a dump on Ishiiruka: ELABORATE. Or else you sound exactly like that negative-Nancy Dogway.
I have the smoothest performance by far (on a powerful system) compared to any version of master; no (or very little) cache stuttering. It's a fantastic feature.
Many games I only play ONCE (single player adventures for example); so what good is it when the second playthrough is so much smoother -when cache has build up- in master..? Exactly.
Other games still work better with DX9, like DKC returns. I like being able to choose DX9 - even if it's outdated.
In the end it comes down to this: appreciate all the hard work Tino is doing & have a blast using his builds (I know I do) AND give constructive feedback, like decent bug-reports. Or just stick to master & leave this alone.
every single bug that was reported here with the required detail to alow me to reproduce it has been fixed. most of the bugs that are still present comes from two main areas, hardware problems, like the old nvidia vs amd problems, or from the inacuracy in integer emulation with floats that is keep to support dx9 backend, for example nes games. I put the best from my side to fix things, and at this point in time, most of the bugs i have in the graphical part can be easily fixed by merging integer path from master, and audio issues are mostly fixed in my last commit, the rest of issues are shared with master. so i don't see a big problem as my codebase is now 95% compatible with master.