Skip to content
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

Merged
merged 8 commits into from
Sep 24, 2023
Merged

Add "rendering overview" document #501

merged 8 commits into from
Sep 24, 2023

Conversation

ISSOtm
Copy link
Member

@ISSOtm ISSOtm commented Aug 17, 2023

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.

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.
@ISSOtm ISSOtm marked this pull request as ready for review August 17, 2023 22:13
@ISSOtm
Copy link
Member Author

ISSOtm commented Aug 17, 2023

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.

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.

Copy link
Member Author

@ISSOtm ISSOtm Aug 17, 2023

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?

Copy link
Member Author

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:

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch!

Copy link
Member Author

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/Audio.md Outdated Show resolved Hide resolved
src/Rendering.md Outdated Show resolved Hide resolved
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:
Copy link
Member Author

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 Show resolved Hide resolved
avivace and others added 3 commits September 13, 2023 15:21
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
Co-authored-by: Eldred Habert <[email protected]>
Copy link
Member

@avivace avivace left a 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

@ISSOtm ISSOtm merged commit 2bfcdfa into gbdev:master Sep 24, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants