iris
00cc9309cb
de6e324bdseparate emu thread10d3daf86Roms List improvements95d202f37Let's make the rom list process on a separate thread so the emulator doesnt take ages to load.fc306967fWow the ROM Header was just completely busted. Game list view works nowbad1691eefuck this shit2b59e5f46game list in progressd26417b83remappable inputs in progressac4af8106inpute72abc240update readme430139dc9Qt6 frontend3080d4d45Fix this small bug too08cd13b85Cop0 unused functions do not actually pose a threat (as per manual). They don't do anything, so shall we.61bb4fb44make idle loop detection a little more specific with where the load goesb037de4c3SAZDFsdff12e81e73eneed to figure out why n64-systemtest loops indefinitely at some address that appears to be valid (i think it's me not invalidating the cache properly)204f0e13bidle skipping seems to work!cb8bb634asdkfjlasdf58e5c89c1Fix compilation issue on my machine (no idea)24fb2898eattempting more serious idle skipping214719577Place rsp.Step inside cached interpreter. Gains about 3 more fpsbb97dcc23mmmmm920b77d38wjkhasdfjhkasdf430ccdab4it's a start...4f42a673aCached interpreter plays Mario 64. Start looking into RSP as wellc9a030787idle skipping works!5fbda03cenew idea366637abaIdle skipping... maybe?609fa2fb0Cache instructions implemented but broken lmao. Commented out for nowe140a6d12- Stop using inheritance for CPU, instead use composition. - Introduce KAIZEN_JIT_ENABLED optional define instead of relying on __aarch64__ and the like. - More cache work68e613057prep cache impl811b4d809fix clang formatfda755f7didkd5024ebbfsmall MI refactor in preparation of (eventually) implementing the RDRAM interface properly694b45341Merge commit '206dcdedf195fb320913584180edb12c7731e396' as 'external/SDL'206dcdedfSquashed 'external/SDL/' content from commit 4d17b99d0a4d16e1cb4need to update sdl848b19920Fix compilation errordb61b5299Merge commit 'e94a94559f28e49678fbcf72199a5258137b0fe9' as 'external/imgui'e94a94559Squashed 'external/imgui/' content from commit 02e9b8cac52edb3757need to update imguic1a705e86Emulate weird JALR behaviour4b4c32f4bFix exception for "unusable COP1" in 4 instructions i missed accidentally (again)df5828142Bug putting 0s in the log everywheref8b580048Make isviewer a sink to file8241e9735Fix exception for "unusable COP1" in 4 instructions i missed accidentallyb29715f20small changesd9a620bc1make use of my new small utility library0d1aa938eAdd 'external/ircolib/' from commit 'ce3cd726c8df8388d554abf8bb55d55020eb4450'e64eb40b3Fuck git git-subtree-dir: external/ircolib git-subtree-split:de6e324bde
108 lines
4.9 KiB
Markdown
108 lines
4.9 KiB
Markdown
# Contributing to SDL
|
|
|
|
We appreciate your interest in contributing to SDL, this document will describe how to report bugs, contribute code or ideas or edit documentation.
|
|
|
|
**Table Of Contents**
|
|
|
|
- [Filing a GitHub issue](#filing-a-github-issue)
|
|
- [Reporting a bug](#reporting-a-bug)
|
|
- [Suggesting enhancements](#suggesting-enhancements)
|
|
- [Contributing code](#contributing-code)
|
|
- [Forking the project](#forking-the-project)
|
|
- [Following the style guide](#following-the-style-guide)
|
|
- [Running the tests](#running-the-tests)
|
|
- [Opening a pull request](#opening-a-pull-request)
|
|
- [Continuous integration](#continuous-integration)
|
|
- [Contributing to the documentation](#contributing-to-the-documentation)
|
|
- [Editing a function documentation](#editing-a-function-documentation)
|
|
- [Editing the wiki](#editing-the-wiki)
|
|
|
|
## Filing a GitHub issue
|
|
|
|
### Reporting a bug
|
|
|
|
If you think you have found a bug and would like to report it, here are the steps you should take:
|
|
|
|
- Before opening a new issue, ensure your bug has not already been reported on the [GitHub Issues page](https://github.com/libsdl-org/SDL/issues).
|
|
- On the issue tracker, click on [New Issue](https://github.com/libsdl-org/SDL/issues/new).
|
|
- Include details about your environment, such as your Operating System and SDL version.
|
|
- If possible, provide a small example that reproduces your bug.
|
|
|
|
### Suggesting enhancements
|
|
|
|
If you want to suggest changes for the project, here are the steps you should take:
|
|
|
|
- Check if the suggestion has already been made on:
|
|
- the [issue tracker](https://github.com/libsdl-org/SDL/issues);
|
|
- the [discourse forum](https://discourse.libsdl.org/);
|
|
- or if a [pull request](https://github.com/libsdl-org/SDL/pulls) already exists.
|
|
- On the issue tracker, click on [New Issue](https://github.com/libsdl-org/SDL/issues/new).
|
|
- Describe what change you would like to happen.
|
|
|
|
## Contributing code
|
|
|
|
This section will cover how the process of forking the project, making a change and opening a pull request.
|
|
|
|
### Forking the project
|
|
|
|
The first step consists in making a fork of the project, this is only necessary for the first contribution.
|
|
|
|
Head over to https://github.com/libsdl-org/SDL and click on the `Fork` button in the top right corner of your screen, you may leave the fields unchanged and click `Create Fork`.
|
|
|
|
You will be redirected to your fork of the repository, click the green `Code` button and copy the git clone link.
|
|
|
|
If you had already forked the repository, you may update it from the web page using the `Fetch upstream` button.
|
|
|
|
### Following the style guide
|
|
|
|
Code formatting is done using a custom `.clang-format` file, you can learn more about how to run it [here](https://clang.llvm.org/docs/ClangFormat.html).
|
|
|
|
Some legacy code may not be formatted, so please avoid formatting the whole file at once and only format around your changes.
|
|
|
|
For your commit message to be properly displayed on GitHub, it should contain:
|
|
|
|
- A short description of the commit of 50 characters or less on the first line.
|
|
- If necessary, add a blank line followed by a long description, each line should be 72 characters or less.
|
|
|
|
For example:
|
|
|
|
```
|
|
Fix crash in SDL_FooBar.
|
|
|
|
This addresses the issue #123456 by making sure Foo was successful
|
|
before calling Bar.
|
|
```
|
|
|
|
### Running the tests
|
|
|
|
Tests allow you to verify if your changes did not break any behaviour, here are the steps to follow:
|
|
|
|
- Before pushing, run the `testautomation` suite on your machine, there should be no more failing tests after your change than before.
|
|
- After pushing to your fork, Continuous Integration (GitHub Actions) will ensure compilation and tests still pass on other systems.
|
|
|
|
### Opening a pull request
|
|
|
|
- Head over to your fork's GitHub page.
|
|
- Click on the `Contribute` button and `Open Pull Request`.
|
|
- Fill out the pull request template.
|
|
- If any changes are requested, you can add new commits to your fork and they will be automatically added to the pull request.
|
|
|
|
### Continuous integration
|
|
|
|
For each push and/or pull request, GitHub Actions will try to build SDL and the test suite on most supported platforms.
|
|
|
|
Its behaviour can be influenced slightly by including SDL-specific tags in your commit message:
|
|
- `[sdl-ci-filter GLOB]` limits the platforms for which to run ci.
|
|
- `[sdl-ci-artifacts]` forces SDL artifacts, which can then be downloaded from the summary page.
|
|
- `[sdl-ci-trackmem-symbol-names]` makes sure the final report generated by `--trackmem` contains symbol names.
|
|
|
|
## Contributing to the documentation
|
|
|
|
### Editing a function documentation
|
|
|
|
The wiki documentation for API functions is synchronised from the headers' doxygen comments. As such, all modifications to syntax; function parameters; return value; version; related functions should be done in the header directly.
|
|
|
|
### Editing the wiki
|
|
|
|
Other changes to the wiki should done directly from https://wiki.libsdl.org/ ... Just click the "edit" link at the bottom of any page!
|