Emulator

"Adding batch build files."

Why not use msbuild instead of calling devenv? Also, please put all the scripts in a subdirectory to avoid having a lot of files in Source/.

"Changing reported iso file size for sparse and compressed files"

I'm not sure if st_blocks unit size == 512 is a valid assumption to make, especially with 4K sectors disks. Is there any reference to the fact that st_blocks always counts 512 bytes blocks?

• Random "// TODO: fix this" comments in 0680e0052ec5?
• Why would we want OSD messages to be in the logfile? If any info is missing in a log file (hint: i see no reason why it would), make the corresponding code log it instead of using OSD messages.
• I don't agree that Release builds need a "restart in debug mode" option. I don't see any need for this option at all, but if anything it shouldn't be in non-developer builds.
• afdfeaeebe34, again, has lots of different changes in one file... what's so hard to keep stuff in separate commits, especially when working with Git?
• possibly other stuff, but too lazy to check which change in 0680e0052ec5 affects which files.

Also, given your past contributions to Dolphin I'm kinda opposed against merging any of your changes back, but that's just my personal opinion.

I really like what i see on 970514485071.

In 0680e0052ec5 why did you add "if (!IsUsingWiimote(0))" to movie.cpp at line 1015? It seems unnecessary. It won't actually change anything, since as far as i'm aware, there are no multi disc wii games, and as of now, recording gc controller and wiimote at the same time doesn't work anyway (or does it, and it was just that check which you disabled that was causing it to stop?). Still, it doesn't make sense to break support for changing discs while playing back gc+wiimote at the same time, even if it'll never be used. Also, even if we did want to do that, why not just use "if (!tmpHeader.bWii)"?

Other than that, i can't wait to try wiimote recording.

Okay. I won't go into explaining obvious stuff to you again. Either you're not understanding stuff on purpose or you should think about my comments some more, because it's really not that hard to grasp what I'm talking about.

I agree, but even without disc change support it's an improvement.

Sure, but is there some reason we need to disable it? It should just work as is for wii games, so long as it uses a gc controller (since i never implemented it for wiimote recording).

given your past contributions to Dolphin I'm kinda opposed against merging ... your changes
What contributions?

The problems specifically in this issue on your last merge request.
http://code.google.com/p/dolphin-emu/issues/detail?id=5041

"I think all your crazy patches need to be split up in to separate patch files since a lot of the changes affect many different things."
-- That one.

"Seconding what Sonicadvance1 said... You've changed all kinds of unrelated things, what about first integrating m+ and then talk about the other stuff?
Also, your committing style is a bit worrying.. d7d99b4a7111 for example changes all kinds of unrelated stuff, if anyone were to find a regression in there it'd be awkward to find out what's wrong if one's not familiar with the code."
-- That one.

"For what it's worth, I agree. The motion plus functionality is what's important. Other preference changes is only one person's opinion at this point. Trying to get the best possible motion plus feature alone is what should be the focus."
-- That one.

"JPeterson: From the looks of things, nothing is ever going to get done here until you separate the emulated motion plus code form the rest of what you've done there. If you do not wish to do that, that's fine, but I wouldn't expect anything to ever be added to master otherwise."
-- That one.

"Please separate the changes marked with * out into their own branch:

Improved Wiimote emulation.
Emulated Wiimote cleanup.
Re-add wiimote packets sniffer.
RawInput mouse backend.
*General cleanup and additions.
*Non-modal input dialogs.
*Resizable and by default larger cheat options dialog. Gekko codes moved to first tab.
*Graphics hotkeys cleanup.
Support for IR calibration from isoini database.
*Additional isoini save options
*Add option to load savestate by date saved, and overwrite oldest savestate.
*Savestate cleanup.
*Benchmarking from .dtm.
*Demo loading cleanup
*Hotkey cleanup.
*Resources cleanup.
*Build cleanup.

We can merge the ones marked with * at a later stage."
-- That one.

"JP: The point of splitting is to make it easier reviewable, so its not better to wait, because thats what we did for the past month since you opened this issue.
The faster you split them up the faster people can (and will) review it - and the faster it will also make its way into master."
-- That one.

"Still has too much unnecessary stuff in it.
Just looking over the first changes: Randomly commenting out code, adding unused parameters."
-- That one.

Too much unnecessary crap all merged in to one branch. One pull request per feature. Don't ball it all up in to a single patch that has everything in it. It makes it a pain in the ass to review especially considering if we don't want /everything/ you've done.

There are tons of things that I could continue on about, but I can't take my entire day doing it.

John: There are at least 5 solid developers that have given their opinions already between this thread and the original and they've all told you the same thing. I don't know what other opinions you're looking for...

I'll handle this. There are some nice changes in here I'd like to keep. No sense trashing them all because the author is being a bit silly, when it's not that hard to deal with.

Remembering all his previous commits, just can say Please DON't merege this...

You don't want useful stuff to be merged because you don't like the author? Doesn't that seem just a bit petty?

Think whatever you want about this changes, but i saw when a hundred commits first is some huge thing and each next is trying to fix previous one and makes things even worse than before, what can i say? Yes i don't like this author.

I see 8 commits, none of which fix anything broken in a previous commit, but ok.

If this is the same guy i think itt is, back in the SVN days of Dolphin Emu he use to make hundreds of commits in one go that created more problems then fixed, and like Autoran1 said, it ended up being lots of commits fixing his previous commits, hence why he actually ended up being removed as a committer. If your going to commit to the master branch these make sure you do go over them with a fine comb and make sure they do neccesary things and not just bulking up the code for no real reason.

and on another note, looking at his changes, he seems to introduce alot of windows only code / ends up ifdef'ing a lot of the code which for a mutli system emulator really isn't the best thing

Looking at it further, it shouldnt be disregarded completely.
http://code.google.com/r/jpeterson57-dolphin/source/detail?r=1909c33939855e9b696c891f0d3d9f596f2abfa0&name=master <-- the wiimote changes in here are definitely worth keeping, sooo Wiimote.cpp , EmuSubroutines.cpp , WII_IPC_HLE_Device_usb.cpp

Yeah, those are the changes i care about.

Save oldest state doesn't work. If 8 slots are already being used, it just saves to slot -1.

I don't have a github account, and i'm not making one just to discuss this, sorry.

It mostly works now, but still fails miserably when using it rapidly (like, faster than once per second). I've also seen instances of saving to slot -1 when holding down the hotkey.

Turns out i'm just too lazy to go through all of this mess. I merged a couple of your commits, and i'd still like to merge the hotkey one, if you fix it, but otherwise i just don't care to go through the rest. If you want to clean up the commits to be more manageable, maybe i'll change my mind.

The merge request branch is moved from Google Code to https://github.com/mirror/dolphin-emu/pulls