mirror of
https://github.com/tildearrow/furnace.git
synced 2024-12-17 22:10:12 +00:00
3.3 KiB
3.3 KiB
Contributing
contributions to Furnace are welcome!
Getting ready
log into your Github account, and click the Fork button in the header of the project's page.
then open a terminal and clone your fork:
git clone git@github.com:USERNAME/furnace.git
(replace USERNAME
with your username)
Working
Code
bug fixes, improvements and several other things accepted.
the coding style is described here:
- indentation: two spaces
- modified 1TBS style:
- no spaces in function calls
- spaces between arguments in function declarations
- no spaces in operations except for
||
and&&
- no space between variable name and assignment
- space between macro in string literals
- C++ pointer style:
void* variable
rather thanvoid *variable
- indent switch cases
- preprocessor directives not intended
- if macro comprises more than one line, indent
- prefer built-in types:
bool
signed char
orunsigned char
are 8-bit- when the type is
char
, always specify whether it is signed or not. - unspecified
char
is signed on x86 and unsigned on ARM, so yeah. - the only situation in where unspecified
char
is allowed is for C strings (const char*
).
- when the type is
short
orunsigned short
are 16-bitint
orunsigned int
are 32-bitfloat
is 32-bitdouble
is 64-bitlong long int
orunsigned long long int
are 64-bit- avoid using 64-bit numbers as I still build for 32-bit systems.
- two
long
s are required to make Windows happy.
size_t
are 32-bit or 64-bit, depending on architecture.
- in float/double operations, always use decimal and
f
if single-precision.- e.g.
1.0f
or1.0
instead of1
.
- e.g.
- prefer
NULL
overnullptr
or any other proprietary null. - don't use
auto
unless needed. - use
String
forstd::string
(this is typedef'd in ta-utils.h). - prefer using operator for String (std::string) comparisons (a=="").
some files (particularly the ones in src/engine/platform/sound
and extern/
) don't follow this style.
you don't have to follow this style. I will fix it after I accept your contribution.
additional guidelines:
- in general strongly avoid breaking compatibility.
- do not touch loadFur/saveFur unless you know what you're doing!
- new fields must be at the end of each block to ensure forward compatibility
- likewise, the instrument read/write functions in DivInstrument have to be handled carefully
- any change to the format requires a version bump (see
src/engine/engine.h
). - do not bump the version number under any circumstances!
- if you are making major changes to the playback routine, make sure to test with older songs to ensure nothing breaks.
- I will run a test suite to make sure this is the case.
- if something breaks, you might want to add a compatibility flag (this requires changing the format though).
- do not touch loadFur/saveFur unless you know what you're doing!
Demo Songs
just put your demo song in demos/
! be noted there are some guidelines:
- avoid Nintendo song covers.
- avoid big label song covers.
Finishing
after you've done your modifications, commit the changes and push. then open your fork on GitHub and send a pull request.
I don't know how to use Git but I want to contribute with a demo song
you can also contact me directly! find me here.