04-09-2015, 07:17 PM -
Notice: That's somehow f*cking long, but please do not TL;DR. Reading this is easier than reading the doc..
To OP: Well you could help edit this, or even use this as a start of how-to on github.
# Brief
There may be some guys wandering around the project, had (almost) no luck finding something good enough to commit.
In fact programming isn't that f*cking hard/cool/blabla, especially for one learned C.
Grammar is just grammar, language features are just features; those are not very relevant to what you do.
For most cases I experienced, that is the depth that how much you understand the project arrangement/sources/hardware/applications/blabla(ha).. make sense.
# How to get started? The easiest way?
I wouldn't just tell you to read this,this,this, learn assembly/C/C++/Shell/blabla.. I do understand how you would feel when you've been forced to read quite plenty (plus difficult?) documents. But you should have learned C/C++ to take the first steps. And I suggest C, because that is easier than C++.
Now then, where to start?
You could try a easier task: finding mistakes/bugs/typos. That seems always easier than writting your own code, and you can get some info of the project - thus would help you when you are seriously developing (ha).
Since RPCS3 isn't any small project that would be easily read throughout. There is luckily a path for you - Travis Logs.
# Travis log, Clang builds.. Find your task
I've fixed Travis to let it continue build RPCS3 instead of dropped out after LLVM. Even there may be some error I made it just continue to compile those code, and generate warnning/error messages.
And I suggest the 'clang build logs' (those ****.1 jobs - according to the travis.yml setting), because it is more sensitive than gcc's (at least by default settings). So you would find plenty weird compilation messages.. Oh wait, please remember to pass all those ones related to LLVM/wxWidgets first.. Most of the compilation messages are already studied by others, just Google for those, such as. Just Google "not equal to a null pointer is always" or "-Wtautological-pointer-compare"(Yep warning mark) for it.
If you wanna read those logs offline, just save the log file to disk and use any terminal-like (such as xterm/gnome-terminal/mintty/Msys2/blabla, when your term have termcap/other) and cat/more (oh I tried less but failed Orz) it.
# After that, prepare to fix it
Okey once you know how to correct it, grab your Git and build tools, to test yourself locally.
RPCS3 can now only be run under 64-bit OSes. Oh sorry.
For windows you would need Msysgit and VS2013 (and TortoiseGit), and network. indeed I don't want to say Msysgit, there is PortableGit which don't need any compilation before use - just extract it to a fair place - find the 7z package from MSYSGIT. Or else you can just get your "Git for windows" which would include Github UI and Msysgit. Then you would have a little time setting up your git environment - don't ask me just, Google for it.
For Linux and Unix users that is fair easier, just follow what is said on RPCS3 project README.
Then don't forget to register a github account (this is sufficient for you to push/create pull).
# Just some notes about coding
Clone the source, and get its submodules (git submodule init --update).. DO YOUR OWN BRANCH! Create a branch named it anything you want and then git checkout it, do not just edit on master branch - to avoid data loss (ha).
Make your changes, follow the guide/FAQ to compile it. If compilation failed try fix or ask others.
And don't forget to push your data to your remote fork whenever you solved some problems.. The local repo is quite easy to be destroyed by user (ha). You can get to know about git in detail yourself if eager to use its advanced features.
# Be ready to pull, if all ok
Then? if you make sure all ok, and where you changed should not crash the whole down (Note: rpcs3 supports WIN/LINUX/OSX now, so please not add a architecture/OS specified changed to all sections - you can use some macro to limit that). Push all branches you have to remote, and get to your repo on github to create pull for it.
I suggest you not just pull, because of a single little mistake - and also please don't merge many features into one single pull. These two cases would make reviewing your code more difficult, thus delay the time your commit being merged.
You can discuss about your edit on issue and IRC to get reviewed.
# Merged?
Once the pull is merged, your code entered the main RPCS3 repository. You can delete the merged branch, and start to rebase - to be prepared for work again. Have your good time fighting against new features/bugs/typos.~
# About implementations
When you have some knowledge, you may want to try to implement something that is not present.
You may wanna track who implemented what, and I suggest you add all those activate contributors' branches to your git remote-branches. And use command line/shell with a single command: git pull --progress --all -v -p. This is pretty easy to fetch all.
To find where is not implemented, you could use grep/Astrogrep/ag/etc to search for "TODO" and "Stub". Also you can check those implemented against the API List you could know (Want it? look at this post's bottom), or when the whole module is not implemented.
Try follow the API/actual behavior to implement it. If you don't know what it behave you can ask for help on IRC, maybe need to make a couple test.
Implemented job would also be reviewed before merged. But thanks for the hardwork, first.
# The end
You can follow other's guide to reach further in development. The IRC is on Freenode, at #rpcs3. Don't be afraid to ask questions about development. Well be polite (you may be banned, if you're super annoying - so far there has been only one case in 3 years, so don't worry). And finally about myself. I'm from China, student, and i'm a *little(?)* busy to anticipate development well. So if you have some questions ask other first - I am not a best choice - you may even can not find me on IRC/Github/Forum months.. Sorry.
To OP: Well you could help edit this, or even use this as a start of how-to on github.
# Brief
There may be some guys wandering around the project, had (almost) no luck finding something good enough to commit.
In fact programming isn't that f*cking hard/cool/blabla, especially for one learned C.
Grammar is just grammar, language features are just features; those are not very relevant to what you do.
For most cases I experienced, that is the depth that how much you understand the project arrangement/sources/hardware/applications/blabla(ha).. make sense.
# How to get started? The easiest way?
I wouldn't just tell you to read this,this,this, learn assembly/C/C++/Shell/blabla.. I do understand how you would feel when you've been forced to read quite plenty (plus difficult?) documents. But you should have learned C/C++ to take the first steps. And I suggest C, because that is easier than C++.
Now then, where to start?
You could try a easier task: finding mistakes/bugs/typos. That seems always easier than writting your own code, and you can get some info of the project - thus would help you when you are seriously developing (ha).
Since RPCS3 isn't any small project that would be easily read throughout. There is luckily a path for you - Travis Logs.
# Travis log, Clang builds.. Find your task
I've fixed Travis to let it continue build RPCS3 instead of dropped out after LLVM. Even there may be some error I made it just continue to compile those code, and generate warnning/error messages.
And I suggest the 'clang build logs' (those ****.1 jobs - according to the travis.yml setting), because it is more sensitive than gcc's (at least by default settings). So you would find plenty weird compilation messages.. Oh wait, please remember to pass all those ones related to LLVM/wxWidgets first.. Most of the compilation messages are already studied by others, just Google for those, such as
Code:
/home/travis/build/RPCS3/rpcs3/rpcs3/Crypto/unself.cpp:611:6:
warning: comparison of array 'klicensee_key' not equal to a null pointer is always true [-Wtautological-pointer-compare]
if (klicensee_key != NULL)If you wanna read those logs offline, just save the log file to disk and use any terminal-like (such as xterm/gnome-terminal/mintty/Msys2/blabla, when your term have termcap/other) and cat/more (oh I tried less but failed Orz) it.
# After that, prepare to fix it
Okey once you know how to correct it, grab your Git and build tools, to test yourself locally.
RPCS3 can now only be run under 64-bit OSes. Oh sorry.
For windows you would need Msysgit and VS2013 (and TortoiseGit), and network. indeed I don't want to say Msysgit, there is PortableGit which don't need any compilation before use - just extract it to a fair place - find the 7z package from MSYSGIT. Or else you can just get your "Git for windows" which would include Github UI and Msysgit. Then you would have a little time setting up your git environment - don't ask me just, Google for it.
For Linux and Unix users that is fair easier, just follow what is said on RPCS3 project README.
Then don't forget to register a github account (this is sufficient for you to push/create pull).
# Just some notes about coding
Clone the source, and get its submodules (git submodule init --update).. DO YOUR OWN BRANCH! Create a branch named it anything you want and then git checkout it, do not just edit on master branch - to avoid data loss (ha).
Make your changes, follow the guide/FAQ to compile it. If compilation failed try fix or ask others.
And don't forget to push your data to your remote fork whenever you solved some problems.. The local repo is quite easy to be destroyed by user (ha). You can get to know about git in detail yourself if eager to use its advanced features.
# Be ready to pull, if all ok
Then? if you make sure all ok, and where you changed should not crash the whole down (Note: rpcs3 supports WIN/LINUX/OSX now, so please not add a architecture/OS specified changed to all sections - you can use some macro to limit that). Push all branches you have to remote, and get to your repo on github to create pull for it.
I suggest you not just pull, because of a single little mistake - and also please don't merge many features into one single pull. These two cases would make reviewing your code more difficult, thus delay the time your commit being merged.
You can discuss about your edit on issue and IRC to get reviewed.
# Merged?
Once the pull is merged, your code entered the main RPCS3 repository. You can delete the merged branch, and start to rebase - to be prepared for work again. Have your good time fighting against new features/bugs/typos.~
# About implementations
When you have some knowledge, you may want to try to implement something that is not present.
You may wanna track who implemented what, and I suggest you add all those activate contributors' branches to your git remote-branches. And use command line/shell with a single command: git pull --progress --all -v -p. This is pretty easy to fetch all.
To find where is not implemented, you could use grep/Astrogrep/ag/etc to search for "TODO" and "Stub". Also you can check those implemented against the API List you could know (Want it? look at this post's bottom), or when the whole module is not implemented.
Try follow the API/actual behavior to implement it. If you don't know what it behave you can ask for help on IRC, maybe need to make a couple test.
Implemented job would also be reviewed before merged. But thanks for the hardwork, first.
# The end
You can follow other's guide to reach further in development. The IRC is on Freenode, at #rpcs3. Don't be afraid to ask questions about development. Well be polite (you may be banned, if you're super annoying - so far there has been only one case in 3 years, so don't worry). And finally about myself. I'm from China, student, and i'm a *little(?)* busy to anticipate development well. So if you have some questions ask other first - I am not a best choice - you may even can not find me on IRC/Github/Forum months.. Sorry.