Standardize Texture Handling #18
Labels
No Label
Alpha Release Requirement
Bugfix
Demo Target
Documentation
Major Feature
Minor Feature
priority:tier1-active
priority:tier2-foundation
priority:tier3-future
Refactoring & Cleanup
system:animation
system:documentation
system:grid
system:input
system:performance
system:python-binding
system:rendering
system:ui-hierarchy
Tiny Feature
workflow:blocked
workflow:needs-benchmark
workflow:needs-documentation
No Milestone
No project
No Assignees
1 Participants
Notifications
Total Time Spent: 7 hours 47 minutes
Due Date
john
7 hours 47 minutes
No due date set.
Dependencies
No dependencies set.
Reference: john/McRogueFace#18
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Notes say:
23 refactor: Standardize PyTextureObject [depend on RAII feature] - no more bare pointers on the Python types; standardized method for get/set
This issue is for an overhaul of all the references to PyTextureObject. Banish the raw pointers and get a grip on the Python and IndexTexture ownership throughout the lifecycle
WIP:
47d0e34a17WIP:
bfd33102d1WIP:
afd4ff1925What's left to close this?
as of commit
84a8886da2, old functionality is all working and there are no more bare pointers in the Python objects. There's two ways forward from here:.tp_alloctrick": create a newPySomethingObjectand fill in itsdatamember with ashared_ptr) belongs inside thePyTextureclass as static methods, whether I do it now or later.UI.hmegafile apart ( #43 ) or when I clean up all of the Python type member variable stuff ( #56 ).I'm going to push to the feature branch, clock out, and think about it a bit.
WIP
2cf8f94310I have to say I kind of love this new structure(?!)
mcrfpydefnamespace, moved to the C++ class's header, but is now just a tidy pile of assocations from.tp_whatevertoPyClass::whatever.There's an untested definition of
tp_hash/__hash__inPyTexture. I am going to wire up just a little bit more of this, because I have no way to pull the texture object off of a Sprite/Grid. But if they're created with the same texture thentexture1 is texture2should now work. Loading the same file twice won't share a texture (because it actually won't!) but loading one texture and assigning it to everything would check out.WIP
d7228172c4rest of tonight's to-do list:
mcrfpydefnamespace shenanigans done while debuggingalmost ready to merge.