• Login
  • Register
  • Dolphin Forums
  • Home
  • FAQ
  • Download
  • Wiki
  • Code


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Emulator Discussion and Support › Development Discussion v
« Previous 1 ... 22 23 24 25 26 ... 115 Next »

Noob coder looking for intro to Dolphin for development
View New Posts | View Today's Posts

Pages (2): 1 2 Next »
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
Noob coder looking for intro to Dolphin for development
03-29-2017, 11:57 PM
#1
badfeelinboutthis
Unregistered
 
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!
Reply
03-30-2017, 01:02 AM
#2
Gir Offline
Chaotix
****
Posts: 310
Threads: 21
Joined: Mar 2012
Can you code "hello world" in C++ ?
Find
Reply
03-30-2017, 01:27 AM
#3
JosJuice Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 8,693
Threads: 7
Joined: Oct 2014
(03-30-2017, 01:02 AM)Gir Wrote: 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.

(03-29-2017, 11:57 PM)badfeelinboutthis Wrote: 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.

(03-29-2017, 11:57 PM)badfeelinboutthis Wrote: 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.)

(03-29-2017, 11:57 PM)badfeelinboutthis Wrote: 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.
Find
Reply
03-30-2017, 02:09 AM
#4
badfeelinboutthis
Unregistered
 
(03-30-2017, 01:27 AM)JosJuice Wrote: 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.

(03-30-2017, 01:27 AM)JosJuice Wrote: 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.

(03-30-2017, 01:27 AM)JosJuice Wrote: 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.

(03-30-2017, 01:27 AM)JosJuice Wrote: 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?

(03-30-2017, 01:27 AM)JosJuice Wrote: 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.

(03-30-2017, 01:27 AM)JosJuice Wrote: 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.
Reply
03-30-2017, 02:32 AM
#5
KHg8m3r Offline
Doesn't sleep, just Dolphin and Robots
*******
Posts: 5,860
Threads: 4
Joined: Sep 2013
oh MATLAB...........
Find
Reply
03-30-2017, 02:34 AM (This post was last modified: 03-30-2017, 02:35 AM by JosJuice.)
#6
JosJuice Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 8,693
Threads: 7
Joined: Oct 2014
(03-30-2017, 02:09 AM)badfeelinboutthis Wrote: 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.
Find
Reply
03-30-2017, 02:40 AM
#7
badfeelinboutthis
Unregistered
 
(03-30-2017, 02:34 AM)JosJuice Wrote: 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?
Reply
03-30-2017, 02:46 AM
#8
JosJuice Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 8,693
Threads: 7
Joined: Oct 2014
(03-30-2017, 02:40 AM)badfeelinboutthis Wrote: 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.
Find
Reply
03-30-2017, 02:49 AM
#9
badfeelinboutthis
Unregistered
 
(03-30-2017, 02:46 AM)JosJuice Wrote: Yeah, that's pretty much how it works.
Good, thanks for the info and advice, JosJuice!
Reply
03-30-2017, 08:27 PM
#10
degasus Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 1,827
Threads: 10
Joined: May 2012
(03-30-2017, 02:32 AM)KHg8m3r Wrote: 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.
Find
Reply
« Next Oldest | Next Newest »
Pages (2): 1 2 Next »


  • View a Printable Version
  • Subscribe to this thread
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma

Linear Mode
Threaded Mode