Skip to content

Conversation

@mzxrules
Copy link
Contributor

@mzxrules mzxrules commented Sep 6, 2024

Changes made in this pr are licensed under CC0.

This covers the documentation pass on gfxalloc.c I made in #1972. It'd be ideal if Gfx* tempGfxDisp; Gfx* lockedGfxDisp; could be combined into one struct, but there's one function where the regalloc simply doesn't work.

Gfx* Gfx_Open(Gfx* gfx);
Gfx* Gfx_Close(Gfx* gfx, Gfx* dst);
Gfx* Gfx_Open(Gfx* gfxDisp);
Gfx* Gfx_Close(Gfx* gfxDisp, Gfx* gfx);
Copy link
Collaborator

Choose a reason for hiding this comment

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

why "disp" ? afaik that stands for "display"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

opted for disp to make the distinction that the first argument should be a display buffer pointer (i.e. POLY_OPA_DISP) rather than any old Gfx*.

Comment on lines 1160 to 1163
Gfx* tempGfxDisp;
Gfx* lockedGfxDisp;

gfxP = Gfx_Open(sp1CC);
gSPDisplayList(OVERLAY_DISP++, gfxP);
tempGfxDisp = Gfx_Open(lockedGfxDisp = POLY_OPA_DISP);
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not convinced by the temp/locked naming scheme (nor "disp")

Copy link
Contributor

Choose a reason for hiding this comment

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

The Gfx_Open(lockedGfxDisp = POLY_OPA_DISP); is awful too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Gfx_Open(lockedGfxDisp = POLY_OPA_DISP); is unusual yes, but I'd argue that it makes sense to write unusual code to force POLY_OPA_DISP to appear inside the call to Gfx_Open in this case. If you think of the high level picture, that call to Gfx_Open is creating a side effect on POLY_OPA_DISP, it's taking all of the memory it has and giving it to something else.
When you have the assignment above Gfx_Open I feel that you lose a little bit of that connection.

@mzxrules
Copy link
Contributor Author

mzxrules commented Oct 1, 2024

I opted to create GFX_ALLOC_OPEN/GFX_ALLOC_CLOSE macros, since I think it makes the open/close process much cleaner

@Dragorn421
Copy link
Collaborator

Not a fan of this PR, unless there's newfound support for it I'd rather close it

@mzxrules
Copy link
Contributor Author

mzxrules commented Jun 7, 2025

It's a shame, because I feel it does a lot to clean up the clunkiness involved when allocating Gfx memory.

@fig02
Copy link
Collaborator

fig02 commented Jun 7, 2025

I feel like there are docs to be done here, they just arent to everyone's taste in their current state.
I think closing it will ultimately result in people forgetting about it for a long time, but we cant force anybody to do the work to make this agreeable 🤷

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.

5 participants