Emulator

Dolphin 3.0?? Will it be released soon? It would be nice =)

Another thing: The OpenCL option should probably be completely disabled for the release since it's totally obsolete meanwhile.

If possible, don't add useless comments like the one above; you'll receive notice of it soon enough. Don't add stuff if you don't/can't contribute to this issue.

About the points mentioned by NeoBrain:
d) shouldn't be there if we're going for stable; adding new features is most likely to introduce new regressions. And I'd say we have enough features for now.
Better focus on stability, as thats what one would expect from a release.

I didn't mean to add new features, I meant to work on stabilizing the features which have been added since 2.0 (just like you said) rather than introducing new ones.

Err, nvm, for some reason i read that as "try to get as many features added to stable as possible" o_O

If possible, a fix for issue 3892 would be nice in a stable release on OS X. Contrary to the issue's title, most other games (not just Twilight Princess) are affected, making many of them essentially unplayable.

Only regressions are blockers for a release, we can't fix all of the 500 issues in our database. And as far as I can see, this isn't a regression.

No further posts asking when the release will come or if some stupid bug will be fixed, kthxbai.

issue 4270 is translation/string format related.

4276 and 4277 are blockers.

OpenCl is still useful if you have a good gpu and a sucky cpu.
I still believe the MIC support should be cleaned into a semi working state if possible (and maybe the GBA link better checked?)

If we disable LLE on missing files, can we make it default if those files exists?

nakeee: As long as the opengl backend is as slow as it is I don't think we should make LLE the default even if the needed files are present.

Neobrain: I think we need a formal sound section in game properties, sample rate options, backend, lle/hle, audio throttle. Pretty much every dsp option should be there I think.

LLE can be default, when last bug that affects zelda ucode games is found and users
have faster computers = not yet = i agree with glennricster

Talking about regressions, I've "selected" some issues that are about them (of course each one has a different priority level):
issue 3566
issue 4060
issue 4107
issue 4141
issue 4185
issue 4236
issue 4252

@LM: I think LLE is more complete than HLE therefore LLE should be default and HLE should be a fast options for games where LLE is too slow

but for now LLE is too slow in almost every (at least Wii) game;-)

I believe fixing issue 4090 is important before a release as well, all active features should be functional in a stable release :P

What about speed regressions? With marcos latest fifo work there has been some speed regressions. He actually fixed speed issues after his initial rework of the fifo code, but then performance regressed once again when he did another rework of the fifo code.

Wario World doesn't work correctly in latest revisions since the late 6xxx revisions, I'll test to see if a particular commit is responsible and report back.

it depends on why it is slower now.
A lot of time making something work correctly means doing more calculations which is slower. I think that unless it's a major speed regression it shouldn't be a blocker
(Major both in the speed and the number of games it affect).

Well in ZTP I was getting 28 FPS - 30 FPS in Hyrule Field without the speed hack on my Core i7 950 rig, but now I only get 20 FPS - 22 FPS. Other users are reporting decreased speed in other games. Marco said there was more to do and that performance regressions would be fixed, I just don't think he got around to it yet.

Another issue is that EFB to Ram performance seems slower than before, not just myself reporting this, but others as well. SSAA is also borked, currently Naturalviolence is working with Neobrain on that.

There might be more blockers/regressions out there than are commonly aware. Given the current number of issues still marked "new". Someone needs to weed through those, there are probably many duplicates.

As for branching the code, I may not be a developer but I generally disapprove of branching. There is such a thing as a feature freeze which generally works out better. Once 3.0 is out the door, everyone can commit all the things they worked on.

branching worked fine on the last release, but of course things need to be a bit more stable before. I think the biggest problem is the FIFO. Anyone is working on getting the regressions there fixed?

The only problem with branching last time IMO was that we branched off too early and thus lots of important fixes didn't get ported back. That's why I suggested branching off only one week before release or sth like that.

The longer before you branch the longer you need to convince people to keep feature freeze. And in a project like dolphin with tons of random contributers it's not so easy. That is why we branched early last time, people got annoyed over the freeze and insisted they want to commit their work.

With 2.0, branching was just fail. Pretty much every commit that went into trunk was also committed to branch. In the end, the only difference between branch and trunk was the version label.

I'd also say we don't need one this time around. It's not like there would be many new features to be worked on (especially right now) that would warrent for a split.

Sorry to repeat myself, but I would like to stress the importance of two issues that I don't see in the blocked section: one is issue 4185 that (in my opinion) must absolutely be fixed before the new 3.0 release, because having a Wii emulator that can't emulate properly real Wiimote would be somewhat "funny", and issue 4236, for sure less important, but think about a person that uses for the first time Dolphin, seeing that it always crashes on close without any reason, what would he think of the global quality of the emulator? in this case is more a matter of style, while in issue 4185 is particularly a matter of usability...

I suggest that until release any FIFO release will go through marco.
And also that every ogl/dx will go through rodolf/neo.
Any other sensitive stops we need to keep an extra eye on?
Billard handling input related changes?

the las weeks, the work keep me away from dolphin, next week i hame some free time so i will dedicate it to buxfixing if someone please could make a list of graphic related glitches i will take a look at them.

Issue 4060 is pretty important and might be easy to fix since it was just recently broken.

FWIW, I've got a fix pending for Issue 4090. Only needs to be tested by NaturalViolence...

@rodolf opengl speed regression is my favorite

The OpenGL plugin is generally in a horrible state according to NaturalViolence...
Also, what about pixel depth/lighting, do they work with OGL, yet? See issue 4271.

I forgot to mention there is a regression/issue with Super Mario Galaxy 2. When you step on the platform of the spaceship to view the overworld map to choose a galaxy, there is a scrunched duplicate of the video/animation at the top of the screen.

Not sure how to explain it, but it can be seen at the top of the screen by anyone by stepping on the platform of the spaceship in SMG2. This happens with DX9, not sure if it also happens with OGL and DX11.

Sounds like a clearscreen issue....neobrain will be thrilled....

@Rodolfo
For the love of god fix http://code.google.com/p/dolphin-emu/issues/detail?id=4060

I've been waiting a long time (months) for you to comeback and start fixing some of this stuff.

If you have time after that: http://code.google.com/p/dolphin-emu/issues/detail?id=4271

Hello guys!

Just wanted to mention a problem and that I have struggled long and can not find a solution.

Lessons so kind and fix this:¶

http://code.google.com/p/dolphin-emu/issues/detail?id=4226¶

Please add support for wiimote speaker in HLE or make LLE faster than ever if possible, It'll be great.

souravs...: No feature requests here!
NaturalViolence: I already suggested both of these :P
Also, this isn't a ClearScreen issue but rather an UpdateViewport one.. not sure if that one is fixable, I had some local patches for it but that bug kinda is a mess to work with.

I forgot to mention another regression.

Sonic Adventure 2: Battle locks up or freezes after a few minutes of playing on the City Escape Level and crashes after a minute in the Metal Harbor level. This seems like a JIT regression, I'm not sure though.

The regression mentioned above with Wario World is also likely a JIT regression.

Create an issue for any regressions, please. That way we can just add them to the blocking list rather than having to look through all the comments...

Issue 4185 is definitely a regression, but it is not yet in the blocking list...

@Xtreme

Sounds like you're experiencing the same issue as me just with a different game.
http://code.google.com/p/dolphin-emu/issues/detail?id=4286

So far I have

1. A crash with 64 bit builds on some games that occurs randomly/after awhile
2. A crash that occurs with the single core option, and the fact that I get no slowdown from using it
3. A crash that occurs when moving to a new level and loading data from the disc is to slow

I feel like I'm the only one experiencing a slow unstable mess with recent revisions.

Since we are discussing Dolphin 3.0, I'd like to add a non-tech related suggestion...It doesn't has anything to do with the emulator itself, but with the logo/ui.

We all know that Dolphin stable releases are a major point in the emulator, and we try to get the best of the svn until now. Since we're making something that important, I'd like to suggest to change that old-web 2.0 styled glossy logo to something more stylish and better from a design-wise point.

I uploaded a mockup pic here:
http://i54.tinypic.com/2094q6f.png

This is a logo I made a while ago for dolphin, as we know, dolphin started as a Gamecube emulator and that's why the logo would be nice if it had something related to it... along with a nice dolphin, you know, people loves dolphins ;). I have the psd source if someone wants the thing to improve it or change anything

The thing is, Im not asking for my logo to be used, if someone can do something better I'd glad to give my opinion about it. My point is just to change the logo to something else that would help the emulator to get a better and "cooler" look along the cleaner UI. The frontend on an emulator like this one should be clean and new-looking. I know this is not a competition either, but the pcsx2 people changed the design a while ago too, again, to something more stylish ;)

Again, to me, a stable release is something that should be clean, bug-free (or at least, the most we can) and fresh.

Meh, I personally prefer the current logo over your design..

Anyway, I don't regard any logo discussions as release-critical (over-polishing IMO, it's not like we're releasing some big awesome one-dot-zero stuff...)
=> Move any logo discussions to a separate issue, please.

Oh, Ok. I created issue 4307 for all the logo discussions, I know its kinda over-polishing, but still its an stable release... its kinda important too :)

http://code.google.com/p/dolphin-emu/issues/detail?id=4184

Should be removed. MSAA in openGL works perfectly for me. The user must have mis-configured their graphics settings (probably changed it in default but not the game profile).

I also believe http://code.google.com/p/dolphin-emu/issues/detail?id=4286 should be added now that dozens of others on the forums and googlecode have reported these same crashes in many other games.

Issue 4315 is a regression, breaks fullscreen mode.

I'm not sure if this has been done before, but isn't this sort of thing the reason that git was invented for?

Assuming we moved the project to git, we could easily have everyone submit their changes against 2.0 then selectively pull changes that fix problems covered under the 3.0 feature freeze.

This will also allow commits to effortless rebase their patches after the freeze.

We already thought about moving to git, but the discussion didn't really get to a result. The major arguments against git are that it requires developers to learn how to use it and that Google Code doesn't support Git (which is bad, since otherwise GC is a really nice platform, and we really don't want to use several different web services for repository hosting and issue tracking and other stuff..).
Anyway, this is off topic so don't spam this issue please :)

Issue 4226 is not in block list!!

Moving to git is complicated, especially since google code doesn't support git at all.
And we release like once a year. Is it worth the effort?

@willian I don't think every game issue should become a blocker.

Sorry, but I think that having language translations would be great in 3.0 release. A lot of translations are good enough (and mine is almost perfect) to be part of the next release. But I think that YOU, Dolphin developpers, don't care/want translations to be part of the project. Proof? Language files have been ejected from this project to go to an external one. Reason: too many build for language files updates. Seriously.... One commit or less per week, come on...

What else...

• Fix recent slowdowns and lags,
• make LLE as fast as possible (and fix the sound coming from the Wiimote),
• try to remove unused graphics options (final user is just lost in the video backend options: there are way too many options, making hundreds of possibilities and tries to make a game work the best possible)
• try to fix Virtual console games issues (no sound or no video, for example).

Just my 2 cents.

Anyway, great job!

1. apparently having those translation updates pissed off many devs when we had them in the main repo.
2. who decides which translations are "good enough"? Many translations for the more common languages are horrible from what I heard (at least it sure is true for the german one, I certainly do NOT want that one in a stable release).
3. we don't want to have the release delayed by a translation freeze
4. maintaining separate translations for release AND unstable is just a mess.
5. well. I (and most other devs) actually really don't care/want translations to be part of the project. But claiming that this attitude is the reason why we moved translations to a separate repo is just plain stupid, go somewhere else with your conspiracy theories, please...
6. slowdowns aren't necessarily regressions and thus not release critical
7. making LLE fast neither is release critical
8. we already thought about removing as many options as possible, but it just pisses off the power users... conclusion was that no matter how you do it, some people will always be too stupid to use Dolphin, so let's at least make it comfortable to use for the few who know how to use it...

erm, yeah.. that'd be my 2 cents then I guess.

Looks more like 2 euros there ^^
Don't take away my ooooooooptioooooooons :>

I can understand that you want to keep your options. But maybe a "Main" group box could be added, just to tell end (stable-release) users: "Hey, you might first look those options to fix your issue.".

NeoBrain, I remember how full of hatred you are against me and my ideas (perhaps I am not the only one?). I just can't understand why one commit per week or 2 commits a month could piss of developpers, please explain. We've seen even worse in 7500 commits.

Who decides which translations are "good enough"? Why not making a vote in the corresponding forum??? And if you don't like the german translation, why don't you do it yourself or help them? That would be more constructive than saying that this translation is kind of bullshit.

Good to see how "superior" you think you are, NeoBrain, by saying "some people will always be too stupid to use Dolphin". Just take an option in the Advanced graphics options, and explain it too a neophyte: lots of Dolphins users are not programmers, whatever you think.

However, I gave some ideas. Please ask NeoBrain not to kill me. Thanks.

Let's just put all the translations that people consider "good" in 3.0, and keep the rest of the translations around so that they'll been in SVN builds? That should make everyone happy, right?

Whether the files live in the main Dolphin SVN or in a separate one is just a question of organization. It doesn't mean that translations are not important. This way we can give people access to modify the translations directly without automatically giving them full access to the main repository. I don't know how much we have actually been using this capability though.

hrydgard: No, we (I) haven't utilized that capability at all yet. Would you like administrative access to that repository by the way?

I agree though. Keep the translations that are good. I think some of them are. Pascal's French translations seem good. I don't know French, but I do know that Pascal has worked hard on them. It would be a shame to throw out the hard work that a lot of individuals have put into these translations.

NeoBrain: I have to say that I think you are the main proponent against the translations. A few others have some minor qualms with them (like godisgovernment, rightfully so, because of the wide string issues). But your issue seems to be against the German translation, and I think Pascal is right. You should fix those.

glen, you'll get a wave of issues about bad translations, missing words etc.
People will not know that it's on a different project.
IMHO the translations should be distributed in a separate package and not together with the official binaries.

I agree with hrydgard, and thanks for explaining.
But translators don't have (yet) access to update their language in the repository. But I'm sure glen will deal with this the best (and the more secure) he can.
nakeee, I think hrydgard (and me ;p ) is right: package the known good languages with the release.

About the advanced settings that final users doesn't use: I think that an option for hiding advanced settings must be added and be set up by default, as is on Project 64 emulator.

@pascal:
"NeoBrain, I remember how full of hatred you are against me and my ideas (perhaps I am not the only one?)."
Erm, not really.. not sure how you got that impression.. if we already talked once I don't remember that discussion :P

"I just can't understand why one commit per week or 2 commits a month could piss of developpers, please explain. We've seen even worse in 7500 commits."
idk, some people said so. Anyway, the others have named some more sensible other reasons as well now.

"Who decides which translations are "good enough"? Why not making a vote in the corresponding forum???"
That was actually my plan, but others then brought up the idea to not ship translations at all...

"And if you don't like the german translation, why don't you do it yourself or help them? That would be more constructive than saying that this translation is kind of bullshit."
Yeah, I'll put it right at the bottom of my 100 other TODO list items.. seriously, I can't code the whole emulator myself, especially since I barely have time to finish anything dolphin related these days. Fwiw, the german translation is so bad that fixing it would be more work than doing it from scratch.

"Good to see how "superior" you think you are, NeoBrain, by saying "some people will always be too stupid to use Dolphin"."
It's not only my opinion, several others will agree with me on that.. there's been several attempts to make Dolphin more user friendly and it only ends up with some noob showing up who doesn't manage to get ANYTHING done by himself. Or with the change pissing off power users.

"Just take an option in the Advanced graphics options, and explain it too a neophyte: lots of Dolphins users are not programmers, whatever you think." Erm, how should I phrase this.. advanced options are meant to be used by advanced users.

"However, I gave some ideas. Please ask NeoBrain not to kill me. Thanks."
You know, you're taking this way too personal...

@glenn:
"NeoBrain: I have to say that I think you are the main proponent against the translations."
Not sure where you got that idea from, I had actually planned to create a forum poll to decide which translations are at release-quality, but then someone said "nah, let's better not ship any translations at all". I don't really care if we ship them or not, but if we do they should at least be done properly. And the german translation definitely is NOT release-worthy. Also, as I have stated numerous times, I can't afford wasting my time on fixing the german translation (erm, since I do not really care about it either). Guess it'd be best to just revert it to the initial release, that one was incomplete but at least was done properly. From there I could translate the most important strings if I'm bored sometime (committing rights would be nice for that)..

Fwiw, I like nakee's idea about shipping translations in a separate package.

I don't like the idea of shipping translations in a separate package. It is standard practice to ship translations together with an application. It also really doesn't make sense in the sense that there is a gui option that is useless without them.

NeoBrainX: Start a forum as you suggested and find which translations are in good shape. Also, to get older version of the Germain translations you will have to go back to older svn versions of dolphin itself before the translations were moved to another repository.

I don't like the idea of shipping translations in a separate package eather.
About the advanced options, the thing is that some of these needs to be enabled (or disabled) to make a game work properly, which cannot be teached to a non-advanced user.
Although the Wiki is just amazing, a lot of users won't even know it exists. As settings provided in the Wiki are good, I suggest to add a button "Use recommended settings" for each game profile (which would be based on the game's ini file), which would replace user's (or default) options in the Video settings.

Yeah, but.. how do you explain what XFBs are to an end user, without having a tooltip as large as the video config dialog itself?

And note that the game profiles ARE already based on the game's ini file.. :P

Come to think of it, users don't even need to know what XFBs are since they're supposed to be enabled by default in the game inis anyway.

"8. we already thought about removing as many options as possible, but it just pisses off the power users... conclusion was that no matter how you do it, some people will always be too stupid to use Dolphin, so let's at least make it comfortable to use for the few who know how to use it..."

This right here is a major flaw. A better UI and cleaner easier more streamlined interface is better for everyone all around. Move as many options as you can. It only makes the emulator better in the long run for "stupid users" and also better for "power users". I mean if the "power users" are so smart they'll learn to adapt to a better interface, where stupid people will always be stupid, but a better configuration process will help them.

In the end it's better for everyone. Sure I can handle the way things are now just fine, but the way things are now can and should be a LOT better.

And as far as XFB and anything else missing a tooltip goes, it's better to add a tooltip no matter what.

It's a lot easier and better overall to tell someone who asks "What is this?" to read the tooltip than to say "You dont need to worry about it." (which, if you didnt need to worry about it, why is it there? You just come off like a douche) or type a long description of what it is every time. Not having it only adds to your stress and the users confusion.

So stop being silly and add it.

Well. Go ahead and write a tooltip text for this one, then:
http://dl.dropbox.com/u/10060691/XFBs.txt

I think that the end user is more interested in the result of an option instead of knowing what's technically behind it...so I would just say that XFB could help in reducing or eliminating screen flickering, and that furthermore real XFB could help in displaying missing movies.

Yeah. That, or it fixes something completely unrelated.
Just the same for "emulate efb format changes" or the "VBeam" stuff, we told people when to enable it and they still have no real idea. Because it's not as simple as "enable it if ...".

Whatever.. if anyone feels like wasting their time trying to make dolphin more user friendly, he's free to do so ;)

Here's one:

"In some games, the CPU needs direct access to the image before it is rendered to the screen. Turn this off if you can play your game with no bugs (see below).
Virtual [Performance, quality]: Implements limited XFB implementation while still allowing for a high-resolution image.
Real [Accuracy, Recommended]: Renders the XFB to RAM to allow the CPU direct access, but the image will be native quality. Use this if there are missing videos and/or flickering."

That's the general idea I got from it. I'm no technical writer but this seems to be a good tooltip right here. Feel free to change the wording or the "recommended" setting, I just thought I'd contribute.

Issue 4107 is a bad OpenGL regression (but is someone caring about it?)

I think 4348 should be added as a blocker as well.

@neobrain

Remove 4091 from the list, it's a pointless optimization and you know it. Commit your SSAA patch and I will pronounce 4090 fixed.

Also I still encounter issue 4286 even with the latest svn. I'm willing to bet it's affecting other games as well I just haven't had time to test it enough.

damn dyslexia

Issue 4043 or issue 4187? Who knows how many games these are affecting, and something as important as saving too.

issue 4336 has rendered Metroid Prime 2 unplayable and possibly other games. Would like to see this fixed for 3.0 release.

Ok I will see the posibbles FIFO issues reported in these days, SpiderTE...@gmail.com: Could you describe "massive FIFO errors"? Anyway, I won't code big changes in the fifo until release, if that can broke other games. Only fix obviusly bugs if in my experience I dont think that can affect the rest of the code.

Thanks Marco for looking into the FIFO issues. I understand that it might break other games by fixing one, so if this misses release then no worries. Would rather like to see a stable release for more games then few all because of one game.

This is probably a silly question but I still ask it: What about fixing compiler warnings? Currently, there are 64 warnings for the 32-bit build and 89 warnings for the 64-bit build, on VS2010.

That should not be a blocker pascal. Compiler warnings won't matter to a person downloading 3.0, only people who compile from the repo.

There's already still 6 blockers that I don't even feel are crutial to a big, stable release. But that's just me. :) Let's let them just finish this off so we can get back to having new, frequent, exciting commits back in action again!!

I'm going to fix or at least provide workarounds for issue 4090, issue 4091, issue 4346 and will cleanup the video config dialog before release.
It's just a matter of when I've got some time to do that work...

Issue 1485 is pretty annoying, though. It should totally be fixed in a 3.0
If it's not really fixable, there should at least be an option to disable the wiimote speaker which seems to be a workaround.

@neobrain

You should also take a look into possibly adding:
http://code.google.com/p/dolphin-emu/issues/detail?id=4402

Also skid has now confirmed that he experiences this issue too, not just me: http://code.google.com/p/dolphin-emu/issues/detail?can=2&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&sort=&id=4286

Issue 4091 does not seem like it should block a release.

1. it'll probably take some time to impletement
2. this will cause a lot of churn and new bugs causing a less stable release or just cause more delays in getting 3.0 out.
3. doesn't seem "vital" at all to me. Just a "nice to have" function at some point, but not a blocker.

Yeah, and more important for a stable release might be to fix random crashes (just had Dolphin crashing while playing Kirby's Epic Yarn). However, I guess those are tough to "find" and fix, eh?

@Marcel

From what I can tell most of the random crashes in many games are caused by the recent fifo commits, either 7157/8 or 7185. I still haven't had time to track it down but it's one of those.

4091 will stay since you're totally misunderstanding the effort and risk of fixing that issue. (I won't elaborate on this)

Broken SSAA got worked around in some of my commits...

Isn't issue 4091 what the texcache-rewrite branch is currently doing? Or am I just retarded and it's something completely different altogether?

4509 should be a block: http://code.google.com/p/dolphin-emu/issues/detail?id=4509

Are the remaining issues being worked on? Otherwise, this freeze could take quite a while I guess O_O

Issue 4413 should be fixed by reverting one specific commit.
No idea about issue 4390, it's not a hard blocker anyway though imo.
Still waiting for someone to add an option to workaround issue 4185, I really don't feel like wasting my time to do this, where others would probably be able to implement that in a matter of minutes.
About issue 4107... no idea, I still don't understand on what hardware/OS/Cg version combination the issue arises. Guess we'll ship with the broken stuff, maybe we'll soon be able to drop Cg anyway.
And then there's issue 4091... I'm kinda working on this, just lacking time.

Yeah, I don't get it why no one is just adding an option to disable the wiimote speaker...I know, devs rather like things properly fixed, but if no one knows how to fix it, a workaround would be good enough for now, I guess.

Thanks for the update!

I've starred all those issues to show my support for fixing them so this block can be removed and Dolphin can move on. The project's growth has stagnated and has made hardly any progress for 2½ months. If it weren't for the texcache-rewrite branch it'd look like nothing was going on. When was the last time one of the blocking issues on the list was closed?

@neobrain: Not sure what other devs are doing on Issue 4185 (the wiimote disconnect bug), but I think I speak for everyone here when I say we would be extremely appreciative if you could spend some of your time to at least just give us this option back. As we all know, playing games with real wiimotes has been fubar for many months because of this and we've seen no traction on this. We want our emu back since using old revisions forces us to make a lot of sacrifices in terms of our game's playability/stability. We shouldn't have to do that. The emu is fine now, we just need to turn off the incomplete wiimote speaker!!

This is a major, HUGE regression that users keep on reporting constantly. GodisG reported they were close to getting it to work properly... but that was two months ago now. Not sure where we stand, but regardless, I see no reason why we can't have an option PERIOD! People might want to turn this off becuase they don't want to hear it or it slows things down for them becuase of their ancient hardware. And for the rest of us, we can just use it to turn off speaker so we can play our games properly until a real fix occurs down the line. A simple clearn solution that again should exist any way to give the user more control over their Dolphin experience.

Please get this option in here and we can have one less blocker here, so we can just get 3.0 out the door and move on. It's been a quarter of the year now without much progress - only 3.0 cleanup and touch-ups. Nolen's work is awesome, but for now is incomplete and branched. Later on, this would be sweet but I'm not sure if the plan is to get this in for release or not. I don't see it as a "blocker" though, along with some others there on that list.

Bring the excitement back and keep these other devs interested in contributing to a project that's not just on indefinete lockdown. I don't remember this happening for 2.0 nor do I see anything to this extent on other projects like PSX2 that tries to put out stable official releases. It's fine to have a list of blockers, but if they never get addressed, what's the point?

From IRC:

shuffle2: Billiard: i think i'm just going to disable all the real wiimote speaker code and say fuck it
shuffle2: k?
Billiard: shuffle2: i suppose
no_cluez: shuffle2: whats so hard about just adding an option for it? oO
Billiard: options are against his religion, why won't you respect his beliefs
shuffle2: 1) options suck 2) that still won't fix it
no_cluez: it's better than leaving some games completely unusuable with real wiimote and better than dropping the whole speaker emulation
no_cluez: especially if it cant be fixed, like you said
shuffle2: nope
shuffle2: speaker still sounds like shit
shuffle2: i'll just put it in the emulated mixer and remove the real wiimote stuff
shuffle2: and mayyyybe fix it later. but probably not

...
So, probably no wiimote speaker emulation for 3.0. But at least it's going to be no further problem anymore.

Am I right in thinking shuffle2 is the only one that feels that way? That really doesn't make any sense, don't remove functionality. Options suck? Okay, let's take out all configuration options for everything, and just force EFB to RAM all the time.

Wiimote speaker works well in some games (like for example Wii Sports) and has problems in others; I think that removing this feature is a non-sense, it's like sayng that HLE Audio emulation must be eliminated because sometimes it has some problems.
The solution is very simple: just disable Wiispeaker by default and let the user enable it for the games where it works well.

2 more off the list today leaving only 3! Almost there guys! Great work!

I really think that Issue 4532 should be a 3.0 release blocker, as it is a regression probably due to the fix of Issue 4185.

And what about issue 4549? Unfortunately r7318 seems to have caused some unwanted troubles...

NeoBrain, the new rumble issue (4532) with real Wiimotes is not a blocker?
The Wiimote doesn't stop to rumble (or vibrates too long) if we disable the Wiimote speaker.

Strange that issue 4498 does not appear on the list on the left yet neobrain clearly added it and it hasn't been fixed yet.

I accidently added it since I confused it with another issue.
It's not a blocker since it seems to be a general AA issue, rather than a regression or sth.

Cheat search doesn't work at all now. Gives me an exception whenever I search, and it used to half work back in 2.0. Can someone reproduce this?

Create a separate bug report if you're sure it's not your fault, this isn't a place to discuss issues.

@crashda
Go to the forums for help. Cheat search continues to work just fine here. Issue with your setup/config most likely. No blocker.

@crashdance

Ah, right, THAT issue... Yes, I can reproduce it, mainly by clicking the "New Scan" button with the Data Size set to "8-bit".
At some point, while filling "CheatSearchTab::search_results" with the initial search data, a C++ exception occurs.
To me, it looks like we create/allocate so many items that C++ can't track them all... It seems to work okay with 16-bit and 32-bit searches...

(hopefully I will fill an issue later...)

@crashdance

For me, it turns out that adding calls to std::vector::reserve(...), as I did in r7596, has made 8-bit searches more efficient (no automatic re-allocation) and more usable (no memory-related exceptions). Can you confirm that it works for you now?

(I am not sure if further optimization is good in order to be able to support searching in EXRAM/MEM2 as well in the future, but it doesn't matter as far as 3.0 is concerned.)

I don't know if I'd consider it ready for a release candidate. The real wiimote rumbling getting stuck seems like a pretty major issue to me.

Seriously guys. After having deleted like 20 comments now:
DON'T POST ANYTHING HERE IF IT ISN'T PRODOCTIVE in terms of improving the release.
THANKS.
It's just annoying to receive an email for each "OMGz no blockers left, WILL WE HAVE RELEASE NOW?!?!?" comment.
Release will be done when it's done.
[/rant]

Issue 4595 is a regression, minor GUI problem and probably relatively simple to fix.

I don't see why we should make 2115 block release, it's been there for ages and hasn't been resolved, are you close to fixing it or what?

Close this issue?