-
-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "rendering overview" document #501
Conversation
This makes the section more obvious, and the page itself an overview of the graphics at a high level—the *rendering* process will be described separately in one of the upcoming commits.
Move related information there, to avoid burying it in the middle of hardware reg documentation. Will reorganise and clean it up next.
There might be value in moving the "LCD Status" regs to after this page, since they pertain exclusively to info explained in this overview page. |
src/Rendering.md
Outdated
::: tip NOTE | ||
1. Determine the tile (background or window) that The Pixel is within. (This is affected by horizontal scrolling and/or the window!) | ||
2. If that tile has **not** been considered by a previous OBJ yet: | ||
1. Count how many of that tile's pixels are to the right of The Pixel. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The wording "to the right" sounds exclusive, but I believe the logic here is inclusive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The subtraction below should have been adjusted to account for that. Is it correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it's not, because then the maximum is 7 pixels; minus 3 = 4; plus the "flat" 6 = 40, but the maximum stated above is 11. So probably that the line below should be "Subtract 2." instead?
src/Rendering.md
Outdated
|
||
::: tip NOTE | ||
1. Determine the tile (background or window) that The Pixel is within. (This is affected by horizontal scrolling and/or the window!) | ||
2. If that tile has **not** been considered by a previous OBJ yet: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe the OBJ rendering order has been discussed at this point, so "previous OBJ" may be confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a footnote attached to "previous"?
Since pixels are emitted from left to right, OBJs overlapping the scanline are considered from leftmost <link to OAM page, "X position" anchor> to rightmost, with ties broken by the OAM order (lowest address first).
src/Rendering.md
Outdated
|
||
::: tip NOTE | ||
1. Determine the tile (background or window) that The Pixel is within. (This is affected by horizontal scrolling and/or the window!) | ||
2. If that tile has **not** been considered by a previous OBJ yet: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a footnote attached to "previous"?
Since pixels are emitted from left to right, OBJs overlapping the scanline are considered from leftmost <link to OAM page, "X position" anchor> to rightmost, with ties broken by the OAM order (lowest address first).
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I opened #503 about the todo
Related but separate from #379.
The existing "rendering" section is renamed to "graphics" to make it more obvious, and so that the new overview document can be called "rendering", as it's intended to describe the actual rendering process.
The motivation for making this page separate, is to gather a lot of the more general info about the rendering process, which is currently scattered across other pages (e.g. STAT) and thus harder to come by.
It placement at the end of the list is because it is not necessary to understand this process to get most work done; understanding of the rendering process only starts getting useful when getting into raster effects, I think.
I am publishing this fairly early so feedback can be gathered on the principle itself; I do intend to keep that PR's scope small, so I can actually carry it to the finish line... heh.