Standardize Texture Handling #18

Closed
opened 2024-03-09 18:52:22 +00:00 by john · 6 comments
Owner

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

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
john added the
Alpha Release Requirement
Bugfix
Major Feature
Refactoring & Cleanup
labels 2024-03-09 18:52:22 +00:00
john added this to the All Datatypes Behaving milestone 2024-03-13 12:59:20 +00:00
john added this to the The Datatype Overhaul project 2024-03-13 13:06:39 +00:00
john started working 2024-03-16 14:51:40 +00:00
Author
Owner

WIP: 47d0e34a17

WIP: 47d0e34a17
john stopped working 2024-03-16 15:35:48 +00:00
44 minutes 8 seconds
john started working 2024-03-16 17:26:41 +00:00
Author
Owner

WIP: bfd33102d1

WIP: bfd33102d1
john stopped working 2024-03-16 18:53:28 +00:00
1 hour 26 minutes
john started working 2024-03-17 01:00:08 +00:00
Author
Owner

WIP: afd4ff1925

WIP: afd4ff1925382622abf79db132b6123ee33b946b
john stopped working 2024-03-17 01:53:51 +00:00
53 minutes 43 seconds
john started working 2024-03-17 20:09:38 +00:00
Author
Owner

What'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:

  • Option 1, start working on retrieving / swapping textures as a property of the other Python objects now. That behavior ("the .tp_alloc trick": create a new PySomethingObject and fill in its data member with a shared_ptr) belongs inside the PyTexture class as static methods, whether I do it now or later.
  • Option 2, consider this closed and do that stuff when I break the UI.h megafile 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.

*What's left to close this?* as of commit 84a8886da2570a8087f83141f0d41fef65073d99 , old functionality is all working and there are no more bare pointers in the Python objects. There's two ways forward from here: * Option 1, start working on retrieving / swapping textures as a property of the other Python objects now. That behavior ("the `.tp_alloc` trick": create a new `PySomethingObject` and fill in its `data` member with a `shared_ptr`) belongs inside the `PyTexture` class as static methods, whether I do it now or later. * Option 2, consider this closed and do that stuff when I break the `UI.h` megafile 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.
john stopped working 2024-03-17 20:40:45 +00:00
31 minutes 7 seconds
john started working 2024-03-21 00:20:53 +00:00
Author
Owner

WIP 2cf8f94310

I have to say I kind of love this new structure(?!)

  • The Python class methods are static methods in the C++ class.
  • The Python typedef is still in mcrfpydef namespace, moved to the C++ class's header, but is now just a tidy pile of assocations from .tp_whatever to PyClass::whatever.

There's an untested definition of tp_hash / __hash__ in PyTexture. 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 then texture1 is texture2 should 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.

image

WIP 2cf8f9431025b3eecb67422e98ec95e3f2b4038f I have to say I kind of love this new structure(?!) * The Python class methods are static methods in the C++ class. * The Python typedef is still in `mcrfpydef` namespace, moved to the C++ class's header, but is now just a tidy pile of assocations from `.tp_whatever` to `PyClass::whatever`. There's an untested definition of `tp_hash` / `__hash__` in `PyTexture`. 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 then `texture1 is texture2` should 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. ![image](/attachments/b48db241-6211-4b8e-8db5-6b95a74b06ae)
790 KiB
john stopped working 2024-03-21 01:25:39 +00:00
1 hour 4 minutes
Author
Owner

WIP d7228172c4

rest of tonight's to-do list:

  • clean up comments
  • reverse mcrfpydef namespace shenanigans done while debugging
  • delete PyTexture original implementation from UI.h

almost ready to merge.

WIP d7228172c4d5455159cd91782b49304a971bb444 rest of tonight's to-do list: * clean up comments * reverse `mcrfpydef` namespace shenanigans done while debugging * delete PyTexture original implementation from UI.h almost ready to merge.
john added spent time 2024-03-22 01:42:48 +00:00
2 hours 50 minutes
john started working 2024-03-22 02:09:20 +00:00
john closed this issue 2024-03-22 02:26:11 +00:00
john stopped working 2024-03-22 02:26:11 +00:00
16 minutes 51 seconds
Sign in to join this conversation.
No Assignees
1 Participants
Notifications
Total Time Spent: 7 hours 47 minutes
john
7 hours 47 minutes
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: john/McRogueFace#18
No description provided.