Noob coder looking for intro to Dolphin for development

[badfeelinboutthis]

Howdy folks, I'm new to emulator development (but not programming in general - former IT guy here), and I'm looking to get a developer's perspective on overall program flow of the emulator.  Is there a guide to this sort of info, or do I need to trace through the C++ source code from the top to figure this out?

I've followed the build guide for CMake and Visual Studio, and I've got a clone of the dolphin repo on my pc.  I've also got copies of some hardware descriptions that were suggested in the forums.  So I think I have the tools I need, I'm just lacking some info.

I also want to get a feel for the interaction of Visual Studio, Git/Github, and making/adding changes to the code.  Things like, if I sync my local Dolphin git repo to the online master, do I need to rebuild the associated project in VS?  And if I make changes, how do I get that turned into a pull request, and how does the review process for those work?  

If anyone can help me find/get this info, that would shorten my ramp-up time so I can get contributing.  Thanks for your time!

[Gir]

Can you code "hello world" in C++ ?

[JosJuice]

Can you code "hello world" in C++ ?

Well... They say that they're not new to programming, so I assume that part isn't going to be much of a problem.

Is there a guide to this sort of info, or do I need to trace through the C++ source code from the top to figure this out?

I don't think there is any general guide, though there is some interesting reading available here (6:3): https://www.alchemistowl.org/pocorgtfo/pocorgtfo06.pdf

If you're wondering about a specific part of Dolphin, feel free to ask about it, and hopefully someone will be able to explain it. Explaining all of Dolphin would be a lot of work, though.

Things like, if I sync my local Dolphin git repo to the online master, do I need to rebuild the associated project in VS?

You don't technically need to rebuild Dolphin after doing anything in particular, but if you've pulled down the latest changes, you'll need to rebuild Dolphin if you want to run the new code, since the exe file otherwise just will represent what the code was the last time you built Dolphin. (Or do you mean something else by "rebuild the associated project", like re-creating the Visual Studio project files? If so, that's probably not necessary, but please clarify what you mean if what I said above doesn't answer your question.)

And if I make changes, how do I get that turned into a pull request, and how does the review process for those work?

First, make sure that you have forked Dolphin on GitHub. Then, each time you want to make a pull request, make a local branch, make one or more commits in it, push it to your forked repository, then use the GitHub website to submit your new branch as a pull request.

The review process is basically that you wait and hope of people to comment on your PR, and if they want you to make any changes, you make those changes to your branch. Note that for small fix-up changes to PRs (like fixing lint failures or changing how a single line is expressed), we want you to amend/rebase commits and force push, not create new commits.

[badfeelinboutthis]

Well... They say that they're not new to programming, so I assume that part isn't going to be much of a problem.

I've done a few things in IDL and MATLAB in school, then had to pore through a bunch of FORTRAN and Python while working on weather forecast models, so while I'm more of a beginner in C++ (I do have C/C++ resources I reference), I've got the general programming thing down pretty well.

I don't think there is any general guide, though there is some interesting reading available here (6:3): https://www.alchemistowl.org/pocorgtfo/pocorgtfo06.pdf

Hoh?  Looks like quite the interesting read indeed.  I'll look over that carefully, thanks.

If you're wondering about a specific part of Dolphin, feel free to ask about it, and hopefully someone will be able to explain it. Explaining all of Dolphin would be a lot of work, though.

I figured as much.  As I get deeper into it I'm sure I'll have plenty of more detailed questions.

You don't technically need to rebuild Dolphin after doing anything in particular, but if you've pulled down the latest changes, you'll need to rebuild Dolphin if you want to run the new code, since the exe file otherwise just will represent what the code was the last time you built Dolphin. (Or do you mean something else by "rebuild the associated project", like re-creating the Visual Studio project files? If so, that's probably not necessary, but please clarify what you mean if what I said above doesn't answer your question.)

No, that was the info I was asking about in that question.  I'm also thinking in terms of code conflicts, where new commits/merges from other contributors change/affect something I'm working on after syncing/rebuilding.  Is there an agreed-on process for handling conflicts, or will I need to work things out on-the-fly with the other person involved?

First, make sure that you have forked Dolphin on GitHub. Then, each time you want to make a pull request, make a local branch, make one or more commits in it, push it to your forked repository, then use the GitHub website to submit your new branch as a pull request.

Got it, I'll go through the GitHub docs as well.

The review process is basically that you wait and hope of people to comment on your PR, and if they want you to make any changes, you make those changes to your branch. Note that for small fix-up changes to PRs (like fixing lint failures or changing how a single line is expressed), we want you to amend/rebase commits and force push, not create new commits.

Cool, works for me.

[KHg8m3r]

oh MATLAB...........

[JosJuice]

I'm also thinking in terms of code conflicts, where new commits/merges from other contributors change/affect something I'm working on after syncing/rebuilding.  Is there an agreed-on process for handling conflicts, or will I need to work things out on-the-fly with the other person involved?

The process is that when there is a conflict between master and your branches, you are responsible for solving the conflicts in your branches by rebasing them. There usually isn't any contact with the person who made the change in master that caused the conflicts, but in the rare case that it isn't just a simple conflict and you have trouble with understanding how your change can be implemented in the new version of master, you can usually ask them for explanations/suggestions.

Note that just fetching the newest code from GitHub won't cause any conflicts in itself, because the code you pulled down will be stored in your local copy of the master branch, and you will (hopefully!) be using separate branches for making changes rather than editing your local master branch. The conflicts will only occur when someone wants to merge one of your pull requests into master (though GitHub will always warn about any merge conflicts in pull requests even if nobody has tried to merge yet) or when you rebase one of your branches on top of master.

[badfeelinboutthis]

The process is that when there is a conflict between master and your branches, you are responsible for solving the conflicts in your branches by rebasing them. There usually isn't any contact with the person who made the change in master that caused the conflicts, but in the rare case that it isn't just a simple conflict and you have trouble with understanding how your change can be implemented in the new version of master, you can usually ask them for explanations/suggestions.

Note that just fetching the newest code from GitHub won't cause any conflicts in itself, because the code you pulled down will be stored in your local copy of the master branch, and you will (hopefully!) be using separate branches for making changes rather than editing your local master branch. The conflicts will only occur when someone wants to merge one of your pull requests into master (though GitHub will always warn about any merge conflicts in pull requests even if nobody has tried to merge yet) or when you rebase one of your branches on top of master.

OK, that makes sense.  So while changes are WIP, I rebase as needed and continue working on them.  Then when PR's are made, GitHub should identify any merge conflicts, which must obviously be resolved before merge.  Do I have that right?

[JosJuice]

OK, that makes sense.  So while changes are WIP, I rebase as needed and continue working on them.  Then when PR's are made, GitHub should identify any merge conflicts, which must obviously be resolved before merge.  Do I have that right?

Yeah, that's pretty much how it works.

[badfeelinboutthis]

Yeah, that's pretty much how it works.

Good, thanks for the info and advice, JosJuice!

[degasus]

oh MATLAB...........

He talked about matlab and fortran, and you've picked matlab? ...

badfeelinboutthis: The best place to get in contact with the dolphin team is on IRC: #dolphin-emu + #dolphin-dev @freenode.