• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Asset - Extension Quality Structures - fixing the ds_* functions

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator

Links:
blog post (explanation) · itch.io page · marketplace page · documentation
Platforms: All
Versions: GMS1, GMS2
Price: $4.95 (itch), $6.99 (MP)

QS is an extension that corrects a number of issues with the current implementation of data structures in GameMaker:
  • Makes ds-related error messages more descriptive
    (e.g. if you are accessing a data structure that's already destroyed, you are told where it was destroyed from)
  • Shows errors/warnings in situations where GM fails silently or does undesirable actions
    (e.g. when mixing up data structure types)
  • Offers tools for figuring out memory leaks easier
    (you can view a list of currently active data structures per type and their origin of creation)
  • Offers tools for figuring out issues with JSON easier
    (e.g. circular references or forgetting to mark something for JSON)
  • Offers chained accessor functions
  • Can seamlessly revert to using built-in functions for zero overhead.
    (if you value both your sanity and performance)
All in all, it is designed as a definitive improvement as far as data structures go.
 
H

Homunculus

Guest
This is a great idea. Even when you are aware of all the issues you mention in the blog post, it's just so easy to get into memory or reference issues with data structures. Some of those issues are also really hard to debug.

It's a shame you lose accessors, but the benefits especially in data heavy projects probably outweigh this.

There's something I don't get though: why are you using an array reference as the data type marker, instead of a "constant" (like an enum)? I understand you probably don't want a string directly in there so the game doesn't get cluttered with the same strings copied over and over in every "quality structure", but isn't a number just as good to identify the type?
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
This is a great idea. Even when you are aware of all the issues you mention in the blog post, it's just so easy to get into memory or reference issues with data structures. Some of those issues are also really hard to debug.
Thank you!

It's a shame you lose accessors, but the benefits especially in data heavy projects probably outweigh this.
It's possible to auto-replace common-case accessors via regex, and qs_get/qs_set "pay off" as soon as you have more than one level of access, but it is a singular inconvenience indeed.

There's something I don't get though: why are you using an array reference as the data type marker, instead of a "constant" (like an enum)? I understand you probably don't want a string directly in there so the game doesn't get cluttered with the same strings copied over and over in every "quality structure", but isn't a number just as good to identify the type?
Since comparing two array references will compare whether they are pointing at the exact same array in memory, they are "unique" - this way detection does not have false positives if an unrelated array comes by with a coincidentally matching value pattern (which would be the case with constants).

On the second half of the question, the memory does not get cluttered with strings - they are reference-counted (much like arrays) since 2015 or so, and even the reference is not copied to a new QS value because it's referencing the global "marker" array, not its contents. Thus your only memory overhead with QS is the stacktrace (when enabled), costing you about ~12 + 16 * (call depth) bytes per active QS in string references (any GML value is 16 bytes - 4 for type, 4 for flags, and 8 for value or reference).
 
Top