McRogueFace/src/PyColor.cpp

219 lines
6.5 KiB
C++
Raw Normal View History

Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
#include "PyColor.h"
#include "McRFPy_API.h"
Iterators, other Python C API improvements closes #72 ref #69 - this resolves the "UICollection" (not "UIEntityCollection", perhaps renamed since the issue opened) and "UIEntityCollection" portion. The Grid point based iterators were not updated. **RPATH updates** Will this RPATH setting allow McRogueFace to execute using its included "lib" subdirectory after being unzipped on a new computer? The change from "./lib" to "$ORIGIN/./lib" improves portability. The $ORIGIN token is a special Linux/Unix convention that refers to the directory containing the executable itself. This makes the path relative to the executable's location rather than the current working directory, which means McRogueFace will correctly find its libraries in the lib subdirectory regardless of where it's run from after being unzipped on a new computer. **New standard object initialization** PyColor, PyVector - Fixed all 15 PyTypeObject definitions to use proper designated initializer syntax - Replaced PyType_GenericAlloc usage in PyColor.cpp and PyVector.cpp - Updated PyObject_New usage in UIEntity.cpp - All object creation now uses module-based type lookups instead of static references - Created centralized utilities in PyObjectUtils.h **RAII Wrappers** automatic reference counting via C++ object lifecycle - Created PyRAII.h with PyObjectRef and PyTypeRef classes - These provide automatic reference counting management - Updated PyColor::from_arg() to demonstrate RAII usage - Prevents memory leaks and reference counting errors **Python object base in type defs:** `.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0}` PyColor, PyTexture, PyVector, UICaption, UICollection, UIEntity, UIFrame, UIGrid **convertDrawableToPython** replace crazy macro to detect the correct Python type of a UIDrawable instance - Removed the problematic macro from UIDrawable.h - Created template-based functions in PyObjectUtils.h - Updated UICollection.cpp to use local helper function - The new approach is cleaner, more debuggable, and avoids static type references **Iterator fixes** tp_iter on UICollection, UIGrid, UIGridPoint, UISprite UIGrid logic improved, standard **List vs Vector usage analysis** there are different use cases that weren't standardized: - UICollection (for Frame children) uses std::vector<std::shared_ptr<UIDrawable>> - UIEntityCollection (for Grid entities) uses std::list<std::shared_ptr<UIEntity>> The rationale is currently connected to frequency of expected changes. * A "UICollection" is likely either all visible or not; it's also likely to be created once and have a static set of contents. They should be contiguous in memory in hopes that this helps rendering speed. * A "UIEntityCollection" is expected to be rendered as a subset within the visible rectangle of the UIGrid. Scrolling the grid or gameplay logic is likely to frequently create and destroy entities. In general I expect Entity collections to have a much higher common size than UICollections. For these reasons I've made them Lists in hopes that they never have to be reallocated or moved during a frame.
2025-05-31 08:58:52 -04:00
#include "PyObjectUtils.h"
#include "PyRAII.h"
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
PyGetSetDef PyColor::getsetters[] = {
{"r", (getter)PyColor::get_member, (setter)PyColor::set_member, "Red component", (void*)0},
{"g", (getter)PyColor::get_member, (setter)PyColor::set_member, "Green component", (void*)1},
{"b", (getter)PyColor::get_member, (setter)PyColor::set_member, "Blue component", (void*)2},
{"a", (getter)PyColor::get_member, (setter)PyColor::set_member, "Alpha component", (void*)3},
{NULL}
};
PyColor::PyColor(sf::Color target)
:data(target) {}
PyObject* PyColor::pyObject()
{
Iterators, other Python C API improvements closes #72 ref #69 - this resolves the "UICollection" (not "UIEntityCollection", perhaps renamed since the issue opened) and "UIEntityCollection" portion. The Grid point based iterators were not updated. **RPATH updates** Will this RPATH setting allow McRogueFace to execute using its included "lib" subdirectory after being unzipped on a new computer? The change from "./lib" to "$ORIGIN/./lib" improves portability. The $ORIGIN token is a special Linux/Unix convention that refers to the directory containing the executable itself. This makes the path relative to the executable's location rather than the current working directory, which means McRogueFace will correctly find its libraries in the lib subdirectory regardless of where it's run from after being unzipped on a new computer. **New standard object initialization** PyColor, PyVector - Fixed all 15 PyTypeObject definitions to use proper designated initializer syntax - Replaced PyType_GenericAlloc usage in PyColor.cpp and PyVector.cpp - Updated PyObject_New usage in UIEntity.cpp - All object creation now uses module-based type lookups instead of static references - Created centralized utilities in PyObjectUtils.h **RAII Wrappers** automatic reference counting via C++ object lifecycle - Created PyRAII.h with PyObjectRef and PyTypeRef classes - These provide automatic reference counting management - Updated PyColor::from_arg() to demonstrate RAII usage - Prevents memory leaks and reference counting errors **Python object base in type defs:** `.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0}` PyColor, PyTexture, PyVector, UICaption, UICollection, UIEntity, UIFrame, UIGrid **convertDrawableToPython** replace crazy macro to detect the correct Python type of a UIDrawable instance - Removed the problematic macro from UIDrawable.h - Created template-based functions in PyObjectUtils.h - Updated UICollection.cpp to use local helper function - The new approach is cleaner, more debuggable, and avoids static type references **Iterator fixes** tp_iter on UICollection, UIGrid, UIGridPoint, UISprite UIGrid logic improved, standard **List vs Vector usage analysis** there are different use cases that weren't standardized: - UICollection (for Frame children) uses std::vector<std::shared_ptr<UIDrawable>> - UIEntityCollection (for Grid entities) uses std::list<std::shared_ptr<UIEntity>> The rationale is currently connected to frequency of expected changes. * A "UICollection" is likely either all visible or not; it's also likely to be created once and have a static set of contents. They should be contiguous in memory in hopes that this helps rendering speed. * A "UIEntityCollection" is expected to be rendered as a subset within the visible rectangle of the UIGrid. Scrolling the grid or gameplay logic is likely to frequently create and destroy entities. In general I expect Entity collections to have a much higher common size than UICollections. For these reasons I've made them Lists in hopes that they never have to be reallocated or moved during a frame.
2025-05-31 08:58:52 -04:00
PyTypeObject* type = (PyTypeObject*)PyObject_GetAttrString(McRFPy_API::mcrf_module, "Color");
if (!type) return nullptr;
PyColorObject* obj = (PyColorObject*)type->tp_alloc(type, 0);
Py_DECREF(type);
if (obj) {
obj->data = data;
}
return (PyObject*)obj;
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
}
sf::Color PyColor::fromPy(PyObject* obj)
{
PyColorObject* self = (PyColorObject*)obj;
return self->data;
}
sf::Color PyColor::fromPy(PyColorObject* self)
{
return self->data;
}
void PyColor::set(sf::Color color)
{
data = color;
}
sf::Color PyColor::get()
{
return data;
}
Py_hash_t PyColor::hash(PyObject* obj)
{
auto self = (PyColorObject*)obj;
Py_hash_t value = 0;
value += self->data.r;
value << 8; value += self->data.g;
value << 8; value += self->data.b;
value << 8; value += self->data.a;
return value;
}
PyObject* PyColor::repr(PyObject* obj)
{
PyColorObject* self = (PyColorObject*)obj;
std::ostringstream ss;
sf::Color c = self->data;
ss << "<Color (" << int(c.r) << ", " << int(c.g) << ", " << int(c.b) << ", " << int(c.a) << ")>";
std::string repr_str = ss.str();
return PyUnicode_DecodeUTF8(repr_str.c_str(), repr_str.size(), "replace");
}
int PyColor::init(PyColorObject* self, PyObject* args, PyObject* kwds) {
//using namespace mcrfpydef;
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
static const char* keywords[] = { "r", "g", "b", "a", nullptr };
PyObject* leader;
int r = -1, g = -1, b = -1, a = 255;
if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|iii", const_cast<char**>(keywords), &leader, &g, &b, &a)) {
PyErr_SetString(PyExc_TypeError, "mcrfpy.Color requires a 3-tuple, 4-tuple, color name, or integer values within 0-255 (r, g, b, optionally a)");
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
return -1;
}
//std::cout << "Arg parsing succeeded. Values: " << r << " " << g << " " << b << " " << a <<std::endl;
//std::cout << PyUnicode_AsUTF8(PyObject_Repr(leader)) << std::endl;
// Tuple cases
if (PyTuple_Check(leader)) {
Py_ssize_t tupleSize = PyTuple_Size(leader);
if (tupleSize < 3 || tupleSize > 4) {
PyErr_SetString(PyExc_TypeError, "Invalid tuple length: mcrfpy.Color requires a 3-tuple, 4-tuple, color name, or integer values within 0-255 (r, g, b, optionally a)");
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
return -1;
}
r = PyLong_AsLong(PyTuple_GetItem(leader, 0));
g = PyLong_AsLong(PyTuple_GetItem(leader, 1));
b = PyLong_AsLong(PyTuple_GetItem(leader, 2));
if (tupleSize == 4) {
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
a = PyLong_AsLong(PyTuple_GetItem(leader, 3));
}
}
// Color name (not implemented yet)
else if (PyUnicode_Check(leader)) {
PyErr_SetString(PyExc_NotImplementedError, "Color names aren't ready yet");
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
return -1;
}
// Check if the leader is actually an integer for the r value
else if (PyLong_Check(leader)) {
r = PyLong_AsLong(leader);
// Additional validation not shown; g, b are required to be parsed
} else {
PyErr_SetString(PyExc_TypeError, "mcrfpy.Color requires a 3-tuple, 4-tuple, color name, or integer values within 0-255 (r, g, b, optionally a)");
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
return -1;
}
// Validate color values
if (r < 0 || r > 255 || g < 0 || g > 255 || b < 0 || b > 255 || a < 0 || a > 255) {
PyErr_SetString(PyExc_ValueError, "Color values must be between 0 and 255.");
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
return -1;
}
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
self->data = sf::Color(r, g, b, a);
return 0;
}
PyObject* PyColor::pynew(PyTypeObject* type, PyObject* args, PyObject* kwds)
{
auto obj = (PyObject*)type->tp_alloc(type, 0);
//Py_INCREF(obj);
return obj;
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
}
PyObject* PyColor::get_member(PyObject* obj, void* closure)
{
Squashed commit of the following: [alpha_streamline_1] the low-hanging fruit of pre-existing issues and standardizing the Python interfaces Special thanks to Claude Code, ~100k output tokens for this merge 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> commit 99f301e3a0e9e81ad28c9e1d410390c32dfd933c Author: John McCardle <mccardle.john@gmail.com> Date: Sat Jul 5 16:25:32 2025 -0400 Add position tuple support and pos property to UI elements closes #83, closes #84 - Issue #83: Add position tuple support to constructors - Frame and Sprite now accept both (x, y) and ((x, y)) forms - Also accept Vector objects as position arguments - Caption and Entity already supported tuple/Vector forms - Uses PyVector::from_arg for flexible position parsing - Issue #84: Add pos property to Frame and Sprite - Added pos getter that returns a Vector - Added pos setter that accepts Vector or tuple - Provides consistency with Caption and Entity which already had pos properties - All UI elements now have a uniform way to get/set positions as Vectors Both features improve API consistency and make it easier to work with positions. commit 2f2b488fb54da12c39c0010dbd83cb9f6c429b01 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Jul 5 16:18:10 2025 -0400 Standardize sprite_index property and add scale_x/scale_y to UISprite closes #81, closes #82 - Issue #81: Standardized property name to sprite_index across UISprite and UIEntity - Added sprite_index as the primary property name - Kept sprite_number as a deprecated alias for backward compatibility - Updated repr() methods to use sprite_index - Updated animation system to recognize both names - Issue #82: Added scale_x and scale_y properties to UISprite - Enables non-uniform scaling of sprites - scale property still works for uniform scaling - Both properties work with the animation system All existing code using sprite_number continues to work due to backward compatibility. commit 5a003a9aa587eb8ee4b79ac67ca8f342ab62e2d2 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Jul 5 16:09:52 2025 -0400 Fix multiple low priority issues closes #12, closes #80, closes #95, closes #96, closes #99 - Issue #12: Set tp_new to NULL for GridPoint and GridPointState to prevent instantiation from Python - Issue #80: Renamed Caption.size to Caption.font_size for semantic clarity - Issue #95: Fixed UICollection repr to show actual derived types instead of generic UIDrawable - Issue #96: Added extend() method to UICollection for API consistency with UIEntityCollection - Issue #99: Exposed read-only properties for Texture (sprite_width, sprite_height, sheet_width, sheet_height, sprite_count, source) and Font (family, source) All issues have corresponding tests that verify the fixes work correctly. commit e5affaf317665395135c936bc4a6b840ae321765 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Jul 5 15:50:09 2025 -0400 Fix critical issues: script loading, entity types, and color properties - Issue #37: Fix Windows scripts subdirectory not checked - Updated executeScript() to use executable_path() from platform.h - Scripts now load correctly when working directory differs from executable - Issue #76: Fix UIEntityCollection returns wrong type - Updated UIEntityCollectionIter::next() to check for stored Python object - Derived Entity classes now preserve their type when retrieved from collections - Issue #9: Recreate RenderTexture when resized (already fixed) - Confirmed RenderTexture recreation already implemented in set_size() and set_float_member() - Uses 1.5x padding and 4096 max size limit - Issue #79: Fix Color r, g, b, a properties return None - Implemented get_member() and set_member() in PyColor.cpp - Color component properties now work correctly with proper validation - Additional fix: Grid.at() method signature - Changed from METH_O to METH_VARARGS to accept two arguments All fixes include comprehensive tests to verify functionality. closes #37, closes #76, closes #9, closes #79
2025-07-05 17:30:49 -04:00
PyColorObject* self = (PyColorObject*)obj;
long member = (long)closure;
switch (member) {
case 0: // r
return PyLong_FromLong(self->data.r);
case 1: // g
return PyLong_FromLong(self->data.g);
case 2: // b
return PyLong_FromLong(self->data.b);
case 3: // a
return PyLong_FromLong(self->data.a);
default:
PyErr_SetString(PyExc_AttributeError, "Invalid color member");
return NULL;
}
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
}
int PyColor::set_member(PyObject* obj, PyObject* value, void* closure)
{
Squashed commit of the following: [alpha_streamline_1] the low-hanging fruit of pre-existing issues and standardizing the Python interfaces Special thanks to Claude Code, ~100k output tokens for this merge 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> commit 99f301e3a0e9e81ad28c9e1d410390c32dfd933c Author: John McCardle <mccardle.john@gmail.com> Date: Sat Jul 5 16:25:32 2025 -0400 Add position tuple support and pos property to UI elements closes #83, closes #84 - Issue #83: Add position tuple support to constructors - Frame and Sprite now accept both (x, y) and ((x, y)) forms - Also accept Vector objects as position arguments - Caption and Entity already supported tuple/Vector forms - Uses PyVector::from_arg for flexible position parsing - Issue #84: Add pos property to Frame and Sprite - Added pos getter that returns a Vector - Added pos setter that accepts Vector or tuple - Provides consistency with Caption and Entity which already had pos properties - All UI elements now have a uniform way to get/set positions as Vectors Both features improve API consistency and make it easier to work with positions. commit 2f2b488fb54da12c39c0010dbd83cb9f6c429b01 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Jul 5 16:18:10 2025 -0400 Standardize sprite_index property and add scale_x/scale_y to UISprite closes #81, closes #82 - Issue #81: Standardized property name to sprite_index across UISprite and UIEntity - Added sprite_index as the primary property name - Kept sprite_number as a deprecated alias for backward compatibility - Updated repr() methods to use sprite_index - Updated animation system to recognize both names - Issue #82: Added scale_x and scale_y properties to UISprite - Enables non-uniform scaling of sprites - scale property still works for uniform scaling - Both properties work with the animation system All existing code using sprite_number continues to work due to backward compatibility. commit 5a003a9aa587eb8ee4b79ac67ca8f342ab62e2d2 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Jul 5 16:09:52 2025 -0400 Fix multiple low priority issues closes #12, closes #80, closes #95, closes #96, closes #99 - Issue #12: Set tp_new to NULL for GridPoint and GridPointState to prevent instantiation from Python - Issue #80: Renamed Caption.size to Caption.font_size for semantic clarity - Issue #95: Fixed UICollection repr to show actual derived types instead of generic UIDrawable - Issue #96: Added extend() method to UICollection for API consistency with UIEntityCollection - Issue #99: Exposed read-only properties for Texture (sprite_width, sprite_height, sheet_width, sheet_height, sprite_count, source) and Font (family, source) All issues have corresponding tests that verify the fixes work correctly. commit e5affaf317665395135c936bc4a6b840ae321765 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Jul 5 15:50:09 2025 -0400 Fix critical issues: script loading, entity types, and color properties - Issue #37: Fix Windows scripts subdirectory not checked - Updated executeScript() to use executable_path() from platform.h - Scripts now load correctly when working directory differs from executable - Issue #76: Fix UIEntityCollection returns wrong type - Updated UIEntityCollectionIter::next() to check for stored Python object - Derived Entity classes now preserve their type when retrieved from collections - Issue #9: Recreate RenderTexture when resized (already fixed) - Confirmed RenderTexture recreation already implemented in set_size() and set_float_member() - Uses 1.5x padding and 4096 max size limit - Issue #79: Fix Color r, g, b, a properties return None - Implemented get_member() and set_member() in PyColor.cpp - Color component properties now work correctly with proper validation - Additional fix: Grid.at() method signature - Changed from METH_O to METH_VARARGS to accept two arguments All fixes include comprehensive tests to verify functionality. closes #37, closes #76, closes #9, closes #79
2025-07-05 17:30:49 -04:00
PyColorObject* self = (PyColorObject*)obj;
long member = (long)closure;
if (!PyLong_Check(value)) {
PyErr_SetString(PyExc_TypeError, "Color values must be integers");
return -1;
}
long val = PyLong_AsLong(value);
if (val < 0 || val > 255) {
PyErr_SetString(PyExc_ValueError, "Color values must be between 0 and 255");
return -1;
}
switch (member) {
case 0: // r
self->data.r = static_cast<sf::Uint8>(val);
break;
case 1: // g
self->data.g = static_cast<sf::Uint8>(val);
break;
case 2: // b
self->data.b = static_cast<sf::Uint8>(val);
break;
case 3: // a
self->data.a = static_cast<sf::Uint8>(val);
break;
default:
PyErr_SetString(PyExc_AttributeError, "Invalid color member");
return -1;
}
Squashed commit of the following: [standardize_color_handling] closes #11 Check the abandoned feature branch for PyLinkedColor, a time-expensive but now abandoned feature to link a color value to a UIDrawable. There are some TODOs left in the PyColor class, but that can go under cleanup. I'm way over time on this, so I'm taking a small victory :) commit 572aa526058ae012f622393eae01c65cbc8dc05e Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:18:26 2024 -0400 More color table updates commit 01706bd59d9b62fe1ea8f8dcce0929da738490dd Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 30 21:13:31 2024 -0400 Color wrapup... Cutting PyLinkedColor to simplify my cursedly mortal, finite existence commit 3991ac13d6471e491cbccf2ddb8d36bad528b2f7 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 23:50:50 2024 -0400 Still having segfaults with LinkedColor and captions (specifically outline color, but that might not be the actual cause). PyColor shaping back up in simplified form. commit 06e24a1b27c2f1ec520537f3a5b9b08d68d07829 Author: John McCardle <mccardle.john@gmail.com> Date: Thu Mar 28 20:53:49 2024 -0400 LinkedColor now reflecting changes to the linked color value. Needs set method + RGBA / color properties commit 41509dfe9640a67f924c5f843fe6bceb0cdb8f78 Author: John McCardle <mccardle.john@gmail.com> Date: Wed Mar 27 21:10:03 2024 -0400 Addressing issues with PyColor by splitting behavior off into PyLinkedColor commit 13a4ddf41b41dfc123a00468377b4f8fae0da845 Author: John McCardle <mccardle.john@gmail.com> Date: Tue Mar 26 23:02:00 2024 -0400 Build runs again. PyColor objects are being instantiated, with bugs and no test of color changing commit 1601fc7faba53e8d0d5814688b80e5cbfec2a700 Author: John McCardle <mccardle.john@gmail.com> Date: Mon Mar 25 20:48:08 2024 -0400 Still doesn't compile, but now the issue is in UI.h overcoupling. Progress! commit 13672c8fdbe7f3db385c93234331bb16267ef18b Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 21:19:37 2024 -0400 Dabbling around this morning; still not building commit 79090b553f08af7dd03892c2153073d8457a566d Author: John McCardle <mccardle.john@gmail.com> Date: Sun Mar 24 08:36:06 2024 -0400 Unsaved changes from last night commit 2cac6f03c601de4591dbd8205418a1cbfe7e7e9f Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:07:10 2024 -0400 untested PyColor base implementation commit 3728e5fcc8bd745ef0268312a808fab6c82d7d91 Author: John McCardle <mccardle.john@gmail.com> Date: Sat Mar 23 23:06:36 2024 -0400 Color naming prototype
2024-03-30 21:20:40 -04:00
return 0;
}
PyColorObject* PyColor::from_arg(PyObject* args)
{
Iterators, other Python C API improvements closes #72 ref #69 - this resolves the "UICollection" (not "UIEntityCollection", perhaps renamed since the issue opened) and "UIEntityCollection" portion. The Grid point based iterators were not updated. **RPATH updates** Will this RPATH setting allow McRogueFace to execute using its included "lib" subdirectory after being unzipped on a new computer? The change from "./lib" to "$ORIGIN/./lib" improves portability. The $ORIGIN token is a special Linux/Unix convention that refers to the directory containing the executable itself. This makes the path relative to the executable's location rather than the current working directory, which means McRogueFace will correctly find its libraries in the lib subdirectory regardless of where it's run from after being unzipped on a new computer. **New standard object initialization** PyColor, PyVector - Fixed all 15 PyTypeObject definitions to use proper designated initializer syntax - Replaced PyType_GenericAlloc usage in PyColor.cpp and PyVector.cpp - Updated PyObject_New usage in UIEntity.cpp - All object creation now uses module-based type lookups instead of static references - Created centralized utilities in PyObjectUtils.h **RAII Wrappers** automatic reference counting via C++ object lifecycle - Created PyRAII.h with PyObjectRef and PyTypeRef classes - These provide automatic reference counting management - Updated PyColor::from_arg() to demonstrate RAII usage - Prevents memory leaks and reference counting errors **Python object base in type defs:** `.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0}` PyColor, PyTexture, PyVector, UICaption, UICollection, UIEntity, UIFrame, UIGrid **convertDrawableToPython** replace crazy macro to detect the correct Python type of a UIDrawable instance - Removed the problematic macro from UIDrawable.h - Created template-based functions in PyObjectUtils.h - Updated UICollection.cpp to use local helper function - The new approach is cleaner, more debuggable, and avoids static type references **Iterator fixes** tp_iter on UICollection, UIGrid, UIGridPoint, UISprite UIGrid logic improved, standard **List vs Vector usage analysis** there are different use cases that weren't standardized: - UICollection (for Frame children) uses std::vector<std::shared_ptr<UIDrawable>> - UIEntityCollection (for Grid entities) uses std::list<std::shared_ptr<UIEntity>> The rationale is currently connected to frequency of expected changes. * A "UICollection" is likely either all visible or not; it's also likely to be created once and have a static set of contents. They should be contiguous in memory in hopes that this helps rendering speed. * A "UIEntityCollection" is expected to be rendered as a subset within the visible rectangle of the UIGrid. Scrolling the grid or gameplay logic is likely to frequently create and destroy entities. In general I expect Entity collections to have a much higher common size than UICollections. For these reasons I've made them Lists in hopes that they never have to be reallocated or moved during a frame.
2025-05-31 08:58:52 -04:00
// Use RAII for type reference management
PyRAII::PyTypeRef type("Color", McRFPy_API::mcrf_module);
if (!type) {
return NULL;
}
// Check if args is already a Color instance
if (PyObject_IsInstance(args, (PyObject*)type.get())) {
return (PyColorObject*)args;
}
// Create new Color object using RAII
PyRAII::PyObjectRef obj(type->tp_alloc(type.get(), 0), true);
if (!obj) {
return NULL;
}
// Initialize the object
int err = init((PyColorObject*)obj.get(), args, NULL);
if (err) {
Iterators, other Python C API improvements closes #72 ref #69 - this resolves the "UICollection" (not "UIEntityCollection", perhaps renamed since the issue opened) and "UIEntityCollection" portion. The Grid point based iterators were not updated. **RPATH updates** Will this RPATH setting allow McRogueFace to execute using its included "lib" subdirectory after being unzipped on a new computer? The change from "./lib" to "$ORIGIN/./lib" improves portability. The $ORIGIN token is a special Linux/Unix convention that refers to the directory containing the executable itself. This makes the path relative to the executable's location rather than the current working directory, which means McRogueFace will correctly find its libraries in the lib subdirectory regardless of where it's run from after being unzipped on a new computer. **New standard object initialization** PyColor, PyVector - Fixed all 15 PyTypeObject definitions to use proper designated initializer syntax - Replaced PyType_GenericAlloc usage in PyColor.cpp and PyVector.cpp - Updated PyObject_New usage in UIEntity.cpp - All object creation now uses module-based type lookups instead of static references - Created centralized utilities in PyObjectUtils.h **RAII Wrappers** automatic reference counting via C++ object lifecycle - Created PyRAII.h with PyObjectRef and PyTypeRef classes - These provide automatic reference counting management - Updated PyColor::from_arg() to demonstrate RAII usage - Prevents memory leaks and reference counting errors **Python object base in type defs:** `.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0}` PyColor, PyTexture, PyVector, UICaption, UICollection, UIEntity, UIFrame, UIGrid **convertDrawableToPython** replace crazy macro to detect the correct Python type of a UIDrawable instance - Removed the problematic macro from UIDrawable.h - Created template-based functions in PyObjectUtils.h - Updated UICollection.cpp to use local helper function - The new approach is cleaner, more debuggable, and avoids static type references **Iterator fixes** tp_iter on UICollection, UIGrid, UIGridPoint, UISprite UIGrid logic improved, standard **List vs Vector usage analysis** there are different use cases that weren't standardized: - UICollection (for Frame children) uses std::vector<std::shared_ptr<UIDrawable>> - UIEntityCollection (for Grid entities) uses std::list<std::shared_ptr<UIEntity>> The rationale is currently connected to frequency of expected changes. * A "UICollection" is likely either all visible or not; it's also likely to be created once and have a static set of contents. They should be contiguous in memory in hopes that this helps rendering speed. * A "UIEntityCollection" is expected to be rendered as a subset within the visible rectangle of the UIGrid. Scrolling the grid or gameplay logic is likely to frequently create and destroy entities. In general I expect Entity collections to have a much higher common size than UICollections. For these reasons I've made them Lists in hopes that they never have to be reallocated or moved during a frame.
2025-05-31 08:58:52 -04:00
// obj will be automatically cleaned up when it goes out of scope
return NULL;
}
Iterators, other Python C API improvements closes #72 ref #69 - this resolves the "UICollection" (not "UIEntityCollection", perhaps renamed since the issue opened) and "UIEntityCollection" portion. The Grid point based iterators were not updated. **RPATH updates** Will this RPATH setting allow McRogueFace to execute using its included "lib" subdirectory after being unzipped on a new computer? The change from "./lib" to "$ORIGIN/./lib" improves portability. The $ORIGIN token is a special Linux/Unix convention that refers to the directory containing the executable itself. This makes the path relative to the executable's location rather than the current working directory, which means McRogueFace will correctly find its libraries in the lib subdirectory regardless of where it's run from after being unzipped on a new computer. **New standard object initialization** PyColor, PyVector - Fixed all 15 PyTypeObject definitions to use proper designated initializer syntax - Replaced PyType_GenericAlloc usage in PyColor.cpp and PyVector.cpp - Updated PyObject_New usage in UIEntity.cpp - All object creation now uses module-based type lookups instead of static references - Created centralized utilities in PyObjectUtils.h **RAII Wrappers** automatic reference counting via C++ object lifecycle - Created PyRAII.h with PyObjectRef and PyTypeRef classes - These provide automatic reference counting management - Updated PyColor::from_arg() to demonstrate RAII usage - Prevents memory leaks and reference counting errors **Python object base in type defs:** `.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0}` PyColor, PyTexture, PyVector, UICaption, UICollection, UIEntity, UIFrame, UIGrid **convertDrawableToPython** replace crazy macro to detect the correct Python type of a UIDrawable instance - Removed the problematic macro from UIDrawable.h - Created template-based functions in PyObjectUtils.h - Updated UICollection.cpp to use local helper function - The new approach is cleaner, more debuggable, and avoids static type references **Iterator fixes** tp_iter on UICollection, UIGrid, UIGridPoint, UISprite UIGrid logic improved, standard **List vs Vector usage analysis** there are different use cases that weren't standardized: - UICollection (for Frame children) uses std::vector<std::shared_ptr<UIDrawable>> - UIEntityCollection (for Grid entities) uses std::list<std::shared_ptr<UIEntity>> The rationale is currently connected to frequency of expected changes. * A "UICollection" is likely either all visible or not; it's also likely to be created once and have a static set of contents. They should be contiguous in memory in hopes that this helps rendering speed. * A "UIEntityCollection" is expected to be rendered as a subset within the visible rectangle of the UIGrid. Scrolling the grid or gameplay logic is likely to frequently create and destroy entities. In general I expect Entity collections to have a much higher common size than UICollections. For these reasons I've made them Lists in hopes that they never have to be reallocated or moved during a frame.
2025-05-31 08:58:52 -04:00
// Release ownership and return
return (PyColorObject*)obj.release();
}