Emulator

Just some things to think about:

1. Getting hashless finished and merged for 4.0.

2. This is pretty severe for stability, I think this should be taken care of before 4.0. http://code.google.com/p/dolphin-emu/issues/detail?id=5493

3. Personally, I'd like to see the Triforce branch merged into master for 4.0. The Triforce branch is obviously not done yet, but it'd be nice to have MKGP2 functionality in 4.0.

I would nominate Issue 4128. It appears to be a regression that prevents two popular games from running anymore. Especially since the franchise reboot this summer will get people back into their spidey feety pajamas and wanting to play these games again. :P

I don't think 4128 is a regression. Can you give me a revision number that can run the game properly with Jit?

Adding the two known gx-optimization regressions to that list.

Skid said it here: http://forums.dolphin-emulator.com/showthread.php?tid=7939

If not already known and it is a regression, I can track this down.

motion +

Not going to happen unless someone provides patches that can be reviewed and applied easily to the current Dolphin Git.

ability to set and browse for a save directory so user/wii/titles doesn't have to be manually copied anymore when upgrading versions/revisions

there needs to be a hot key to disconnect the wiimote (real) can't remember how I produced it or why it happened (possibly savestates or dodgy BT dongle) but upon loading the game a specific way or loosing connection to the wiimote, dolphin would be unusable untill the wiimote was disconneced (changing the wiimote to non then back again and resyncing) and reconnected in the settings, a hot key to just disconnect the wiimote then using alt +f5 again would fix the issue.

simple fix for now unless I can remmeber how the issue worked exactly, was very fiddley. I assume i could reproduce it for other games if I tried.

@ebenezer and Linkinw
I have not had any issues like those - I always swap the exe to upgrade Dolphin versions and never had a real wiimote connection issue that "reconnecting" didn't fix. I have not seen others reporting these as well.

They're nice to haves but not blockers imo. Read Skid's post again. Regressions and critical bugs only.

@ebenezer
That is already possible, set the nand root on the paths page of the config

I'm adding issue 5493 as it seems like a regression from 3.0 (see comment 2).

Perhaps issue 5368 should be added too? It is a regression that seems to be fixed by d3d11_pixelmetrics branch (which is not yet merged to master).

wespipes, the latest information I have on the Spider-Man games is here:

http://forums.dolphin-emulator.com/showthread.php?tid=5799&pid=215074#pid215074

The short of it is that issue 4128 is not a regression.

Sorry for the spam but this is going to be one amazing release alright! The changes, especially regarding compatibility are big since 3.0.

In my opinion one of the worst regressions comparing to official 3.0 is the HLE Dsound regression of issue 5057

I also think there are many issues that should be closed (or at least should be asked if they're still happening).

I think the version should be 3.1 unless someone can offer a good reason to jump to 4.0.

The changelog seems important enough for a major release IMHO. I really dont care either way but would be +0 for 4.0.

Also, big version numbers are hype since Chrome have been doing it! :D

@skid:
According to LordVador it has regressed since 3.0. See the last few comments here: http://forums.dolphin-emulator.com/printthread.php?tid=7939&page=3

Would be nice to get it back to a "more" stable state but maybe not a blocker...

It's been over a year since 3.0. 4.0 seems to make more sense after that amount of time. 3.1 would have been a good idea to implement something small shortly after 3.0, but not a year later. That's my logic anyway.

1 year does not automatically equal a 1.0 jump imo BUT there have been a ton of changes. MS does do that with their software every release cycle (2yr. for a lot of it). So this isn't too crazy really. Maybe 3.5 would be a good comprimise?

tommyhl2.SS:

• Depending on the release date we'd aim for, I guess merging Hashless might not be a good idea, yet. Remember my (in comparison) trivial two texcache-cleanup branches caused some regressions which took me pretty long to fix (... mostly due to issue reproduction problems). delroth suggested to release as early as August, but merging Hashless might considerably delay that target.
• I'm not sure about Triforce, afaict the branch is just a bunch of hacks right now, isn't it? But then again, the existing support would be better than no support at all. I guess it wouldn't be a bad idea if we explicitely declared it as highly experimental support.

@kosta: I'll try to get pixel metrics support in a good shape in August. Adding issue 5368.

@others:

• Like already suggested, I also think there are enough changes to go from 3.0 to 4.0. Comparing the number of commits between 2.0 and 3.0 (~2500) with what we have now (735) it might not seem so, but remember that previously there have been lots of pointless-ish commits (lots of reverts, correction commits etc because we didn't use branches back then). Frankly speaking, I think there are too many changes to call it 3.1 but not quite really that many changes to call it 4.0. Plus, 3.5 names are just stupid :P It was also suggested to just use a year-based version scheme, but I don't really like randomly changing around versioning schemes.
  Anyway, I guess I'm fine with any decision on the versioning stuff.

NeoBrainX: Yeah, better to forget hashless since it's not ready. Hashless needs to be thoroughly tested, not rushed and thrown into a release. Triforce, either way, it's not vital.

Hashless appears to be more ready than any other branch out there. Speaking of ver. naming, IMO it doesn't really matter. High numbers are pretty popular these days(chrome, ff, etc) so why not go with that.

... deleted lots of off-topic comments. Piracy definitely is not an issue concerning whether we merge Triforce for release or not. If you really want to discuss this out go to the forums.

For reference, Linkinworm suggested this:
"maybe someone would look into this issue, http://code.google.com/p/dolphin-emu/issues/detail?id=5440 as dolphin is meant to be a wii emulator and does emulate these games, but something in the code is deleting the game saves, iv seen alot of people want VC support for quite along time."

I don't really see the practicality of playing VC games in Dolphin (use BSNES, man), but it does seem to be a serious and legitimate bug. Plus, I've heard of save issues on other Wii/WiiWare games - seems there's a problem somewhere with file I/O.

"NeoBrainX: Yeah, better to forget hashless since it's not ready. Hashless needs to be thoroughly tested, not rushed and thrown into a release. Triforce, either way, it's not vital."

Skid has been working on this branch for some time and there's been a lot of testing on it so far - probably more than your usual branch. I've personally tested 70+ games and only found a couple regressions. With today's new hashless build, looks like all the known issues have been resolved.

It's just a matter of maybe doing an 'official' test request to a bigger audience to ensure it's ready for integration. Those are some really, REALLY nice needed changes in there that we should take. Less options, more speed...win, win! It's definetely worth it.

And triforce should get in also. I haven't seen a single regression report nor have i seen any in my tests on this branch. Why would there be, it's pretty self containted - all it does is ADD support. Yes, its a bunch of hacks, but adding the ability to play a rare cool Mario game would make for some good headlines on the release info. I don't see why we wouldn't include this.

01:34:53 <@skid_au> hashless, i think forget about that for 4.0. will take too long to sort out

Hashless and ES_LAUNCH should both make it into the release. If they are not ready yet the release date should be postponed.

Hashless still has too much regressions (bugs or performance) to be merged any time soon, even if it has a lot of nice improvements. Let's not reproduce what happened with texcache-rewrite...

Ya, remember that 4.0 will not be the last Dolphin release.. there's no need to squeeze in any feature into the release, no matter how awesome it might be :p

The async-dvd branch shouldn't be added as a blocker? Ith fixed a lot of "momentary" freezes in all games that I own, and I didn't experience any regression...

Would be great if it could be merged, but for that I'd need a lot more testing. I'll post a follow up on the forum thread to get people to test it more.

For reference, I'll also finally tackle the issue mentioned in this thread... http://forums.dolphin-emulator.com/showthread.php?tid=22324

why not release a beta before the final version?

The latest Git builds can be considered beta. They're already there for you to use.

Here another issue that doesn't exist on 3.0

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

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

Adding an aram-dma-fixes regression to the blocker list.

I think that async-dvd, misc-opts, and efb-scaling-fixes can all be merged for 4.0. I'll test more of my games with all 3 of them to make sure, but the changes seem fine. Most people who use Dolphin are unfortunately not going to be very helpful as far as testing is concerned unless you merge to master. I'll do some more tests and report to the appropriate threads in the forums that wanted testing.

Thanks a lot axxer6 ;)

As a little update, I committed some mipmap fixes earlier today and will look into merging them soonish. About the actual mipmap bugs which are blocking the release, I fear we'll have to get the release done without a fix for /those/. Issue 5459 likely won't get fixed anytime soon either. No idea about issue 5493?

async-dvd definitely can't be merged without more work - it needs to become an option (maybe enabled by default), and I think I noticed some more crashes on Wii games (most likely because of the IPC multithreading changes).

misc-opts needs a lot more testing to be merged, especially games that were previously prone to issues with Jit FPU and paired singles implementation.

I think axx makes a good point. Unfortunately, there's about 20 branches and I'm not sure how much testing you're actually going to get on each one. How many are even broken because of all the changes in master? And I don't see much activity on the forum test requests either.

I'd propose ship 4.0 as soon as you can, and then after start merging some of these branches to Main to get more eyes on the "fixes"... or maybe just merging some branches together to consolodate some changes. It's just too many right now and it's kind of defeating the purpose. As Rodo said in his last commit, a lot of changes are just going to these branches to die. I COMPLETELY understand they need testing and you don't want to break main and constantly do reverts, BUT you might need to rethink the process a bit, comprimise and when the time is right, merge some stuff into master to get the feedback you need - it's kinda a catch22, but it is what it is. You'll have to be ready to address/revert things as necessary but at least you'll get results and at the end of the day, that is what matters.

Also, what about the Triforce branch? Aren't the changes very contained/isolated and not risky for regressions outside of running Triforce games?

@wespipes: We have a build bot at dolphin-emu.org which is doing branch builds whenever a dev requests one to be made. We're not expecting people to test each branch by themselves (because quite often branches don't need to be tested, really), but it would be really nice if people actually cared to test if they're asked to.

About your point of broken branches, that applies virtually to none of the branches, courtesy of git merging (you can just re-apply all patches on top of current master and fix conflicts for each one).

Merging branches together is a terrible idea because it completely destroys the purpose of branches.

About Rodolfo saying that commits die on branches, I strongly have to disagree. Especially since people obviously care about speedup a lot more than little fixes, testing willingness would've been much bigger for his "speedup branch". Also note that Rodolfo probably doesn't know about our build bot, so he likely also referred to the invalid point of people not even having access to a compiled build of his changes.

I really have no idea about the Triforce branch, I think the guy who works on it wants to get coin support applied before merging. It's not that much of a bad idea tho, just merge a feature once it's really complete.

would it be a good idea for 4.0 to make a scan that occurs every time dolphin is booted to check for new builds, so it can make upgrading or swapping builds more efficient. for example, when there is a new build available, it will open a window that tells you there is a new build, and there is also an info box that tells you what is the changes in it. also, it would be nice to have an option to choose what build you want to update to, if there is more then one option. any one think these ideas would work, could be used to expand on the replacing the .exe method for updating.

No feature request spamming here, please.

Issue 5368 is not going to get fixed before release.

I guess there's no need rushing the removal of any other options... Can do that after release, too.
Removing issue 5237 from blockers.

Dolphin 3.5 seems a more accurate version...

This ^^

Rush release for Christmas time?

Did you see the date on the first post? Hardly rushed. Things always have to get cut to make any kind of software release. As always with these "public" releases, I'll just be glad when it is over so development can get back to normal...though I guess with the new build structure, there probably won't be too much of a difference.

Release now plz, objections anyone?

Btw, could we finally agree on 3.5 or 3.9 now, please? :P
IMO the release is better than 3.1 but 3.9 is just silly :D

Well there are some changes that it would be a pity of not being released, but then again they will take a while (like ax hle changes, hashless, etc.). For a 3.5 it wouldn't be bad and it would still leave stuff to look forward for 4.0. Unless 4.0 is going to be released in a short while, i don't think 3.9 makes much sense as a jump from 3.0 since it implies that 4.0 will be released shortly, or it is pretty close to it.

I vote for 3.5 and I think it is a little "shame" or "stain" (don't know how to properly say it, so no offense to anyone) that the regression of issue 5368 won't be fixed in time for release (hope it will be for 4.0;-))

3.5 is better than 3.9 imho. Still, some regressions have to be fixed: for example, the transparent banners issues.

3.5 is better in my opinion... About the transparent banner issue, we could add an option to choose the background color, so, everyone will be happy and people wouldn't start complaining that transparent (or black) is better...

I have no idea why so many people think adding options for everything is a satisfying solution. No, it really is not.

we can just change the transparent banners back, either as part of some larger commit or by itself. anyone who doesn't like the black background can compile it with a different background themselves :p

That's what I've been doing, only I've been adding the black background back into my builds. For what it's worth, 3.5 is nice and lets ditch the transparent banners altogether. :)

I don't know if it's still time to add regressions, but Dolphin cannot be run on MacOS 10.6.x anymore... this is Issue 5723

Upgrade to 10.7. Unless someone in the dev team really wants to commit to 10.6 support for this new release, we'll just stop supporting 10.6 - it's a lot easier for us.

For what it's worth, this is probably worth checking out before the release.

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

Has misc_opts already been merged to master? And It would be nice to get Zelda SS issue 5682 fixed before a new release comes out.
There should be a 3.5 release before Christmas since 3.0 does not support real TR-Wiimotes but you cannot buy older versions anymore.

@delroth : but 10.6 is just a few years old ! And most MacOS users are using it...

As for 10.6 'support' I may help, if only someone could tell me how the application is supposed to be built. I tried on fresh installs of both 10.6 and 10.8 and none could build the repository, I had to change CMakeFiles by hand for the process to complete.

Once I finally got it to build on 10.6, it started properly as opposed to what can be downloaded from main site, but nothing appends when I launch a game : probably a wxWidgets build configuration issue, I suspect not related to 10.6 itself. I did not test my custom CMakeFiles on 10.8.

Nobody knows why it doesn't work. If you do, and you can find a way to fix it that doesn't break the app on 10.7 or 10.8, we will surely merge it.

Building on 10.6 might be broken soon anyway: the Retina Display support patches posted on the bug tracker break 10.6 build compatibility (but the app should still run on 10.6).

My question then is : how is the build bot setup so that it can build ?

Trying to build from master without any special setup searches for wxWidgets 2.9.4, fails and then uses embedded wxWidget3 which does not build (at list with MacOS). So I suspect there are specific installation process to perform before the build can proceed. (The obvious answer 'install wxWidgets 2.9.4' works build-wise, and the generated application can be launched, but none of the game the produces any output)

I probably can help, but I need at bit of help to understand what are the build requirements.

I've looked at the build process and I found the reason why the application does not compile on MacOS 10.6, or does crash when launching an application built with 10.7+.

The embedded wxWidgets as been comitted with pre-configured wxcocoa.h file that assumes some non-standard functions are available : wcscasecmp, wcsncasecmp, wcsdup, strnlen and wcsnlen.

Those functions, which are dynamically linked, or available on MacOS 10.7+ but not on MacOS 10.6. That's why the application can build on 10.7+ but then crashes on 10.6

Moreover, if you try to build Dolphin using a custom build of wxWidgets, the last build step fails because of write permissions. (The same step does not work when building from XCode for other reasons I have still to look into.)

Both problems are fixed in the provided patch.

Then remains the last problem : launching a game does nothing. I still don't know why, but maybe someone could help me now that the build succeeds !

I have created the issue 5762 for this problem. I also commented myself saying that building the application from 10.7+ make it also work within 10.6, and even better than if built from 10.6 because games then displays properly.