[absoIute]

with help from alpha's csv + @Nwo5-trg

[dankmeme01]

Part of me honestly wonders whether this really should be included in Enums.hpp, as it's a relatively large 4k line file and amount of mods interacting with objects is small

[absoIute]

i doubt it'd make any meaningful difference to compile times considering the content

[RayDeeUx]

this is fine in theory, i just feel like this could be reduced to the ones people actually focus on (legacy color triggers, invisible blocks introduced in 1.6, sawblade objects [since those dont have a more granular game object type besides Hazard], jump orbs, jump pads, portals [speed/gamemode/size/mirror/teleport], coins) as a starting point and then let everyone else add onto that baseline as time goes on.

yes, object type enums exist for jump pads/orbs/portals/etc, but enabling "No Touch" changes their object type to Decoration and comparing objects based on object ID feels far more robust than comparing against m_savedObjectType

[RayDeeUx]

this is fine in theory, i just feel like this could be reduced to the ones people actually focus on

adding all the triggers ever to this list as well, since no one wants to memorize those triggers by numeric object ID alone

[absoIute]

that's what i was originally suggesting, but who are we to dictate what objects people are allowed to make mods for

[dankmeme01]

i doubt it'd make any meaningful difference to compile times considering the content

imo still unnecessary cost, but I wouldn't mind it included in <Geode/Geode.hpp> or (generated?) <Geode/Bindings.hpp> or anything else in that tree.

Enums.hpp is included in every binding file so this means you'll be forcing parsing those 4k lines of variables in every header and tu that needs to use any gd class.

[iAndyHD3]

Also consider the cost on CI

[absoIute]

tru dat

[absoIute]

i'm still unsure about this being a bunch of constexprs instead of an enum. if this is merged what would the case for m_objectID to still be an int?

comparisons & storage would obviously move to the enum, and there's not really a reason to be doing math operations on them (apart from range comparisons? in which case we could provide a <=> overload)

[absoIute]

To verify affects on compile times, I benchmarked different approaches with hyperfine (5 warmup, 20 benchmarked runs):

Current approach (ObjectIDs.hpp separate include):

                mean     ±       σ          min     …     max
  Wall Time   1495.6 ms  ±    18.9 ms    1455.7 ms  …  1537.1 ms

Include ObjectIDs.hpp in Enums.hpp directly:

                mean     ±       σ          min     …     max
  Wall Time   1494.3 ms  ±    13.0 ms    1464.2 ms  …  1523.9 ms

Include ObjectIDs.hpp in Enums.hpp directly, and turn it into an enum class:

                mean     ±       σ          min     …     max
  Wall Time   1463.9 ms  ±    22.1 ms    1419.7 ms  …  1507.3 ms

Specs:
Macbook Pro, 14-inch, 2025
Apple M5, 16GB memory
macOS 27.0.1

As I understand, there is no discernible affect on compile times between approaches.

Using the enum class in members would improve readability of inlines and would encourage all devs to use the enum over magic numbers, which seems like a no-brainer.

[dankmeme01]

note: as this is a breaking change now, it will have to wait for v6 / 2.209. until then, more debate could be had for which option is better (namespace vs enum)

[RayDeeUx]

@absoIute would love to see those tests repeated on the specific github runners used for github actions for a more realistic comparison

[absoIute]

i really don't think benchmarking github runners would be that reliable

[qimiko]

i'm voting for the GameVar setup
it's not really a type that exists in the game, and forcing people to cast back and forth to call game functions and interact with members would be more annoying than helpful. officially, robtop uses c-style enums for object ids, so that choice would represent that the best. this would also make it possible to not include it as part of bindings, which solves the potential compilation cost outside of inlines that require it

[absoIute]

while I do think the issue of casting is overstated (from my experience functions that require an int objectID are seldom called) and inconsistent with how Geode treats other added enums (e.g. GJActionID), I've reverted it to the constexpr-style enum and removed Enums.hpp include to put compile time woes to bed. additionally, all unnamed pixel objects have been removed so they can be added later without breaking anything