Sender | Message | Time |
---|---|---|
3 Jan 2024 | ||
anti8536 | 40 minutes | 16:06:08 |
anti8536 | Of just | 16:06:13 |
anti8536 | A black screen | 16:06:17 |
anti8536 | And names | 16:06:18 |
anti8536 | Every single time you beat the game | 16:06:24 |
Idiot B-56 | Sonic Colors Ultimate | 16:06:27 |
anti8536 | 16:07:18 | |
347online joined the room. | 22:42:33 | |
347online | Hi, I have semi-technical but entirely uninformed questions? It's my understanding development continues in GMS 1.4.x? Is that right? What if anything makes porting to GMS2 infeasible/ undesirable? Hopefully that makes sense(?) | 23:08:25 |
Chief Idiocy Officer | Oh man, the book I could write on that subject. Let me get home and I'll try to do a proper writeup for once. | 23:11:30 |
347online | Oh dear 😅 | 23:12:06 |
347online | That sounds wonderful, but also no pressure!!! 💝 | 23:12:18 |
347online | Do any current contributors have advice about what makes a good first issue in this repo specifically? | 23:24:57 |
347online | I'm sure general principles would apply, get one's feet wet with a small enhancement, etc. | 23:25:37 |
347online | * I'm sure general principles would apply, get one's feet wet with a small enhancement or bug, etc. | 23:26:31 |
kutsufatmo | True, but the game isn't that long either and I don't see the logic in being forced to view them for the 20th time after another playthrough | 23:29:52 |
347online | P.S. major shoutouts to the explicit call for code formatting-focused PRs | 23:30:18 |
347online | * P.S. major shoutouts to the explicit call for code formatting-focused PRs 💖 | 23:30:24 |
Idiot Supervisor changed their profile picture. | 23:49:45 | |
4 Jan 2024 | ||
sigma_male_. | 01:08:14 | |
anti8536 | 01:35:03 | |
Chief Idiocy Officer | # Okay, so why no GMS2? Lots of reasons, but they fall into four general categories: 1) Fundamental incompatibilities between GM:S 1.4 and GMS2 2) AM2R's reliance on specific quirks and behaviors of GM:S 1.4 3) Modding 4) The New Runtime I'll address what I can remember off the top of my head in each category, which will be posted as individual messages because I type a lot. | 02:34:44 |
Chief Idiocy Officer | # 1) Fundamental incompatibilities between GM:S 1.4 and GMS2 There are a lot of these; the ones listed are merely what I remember as major show-stoppers. If you don't want gross technical details you can skip this section and just think of it as "porting a game from GM:S 1.4 into GMS2 is mostly a lie." ## Tiles Tiles in GMS2 are fundamentally different from tiles in GM:S 1.4. There is no way to port old tile layers to new tile layers; instead, they are converted into completely unmaintainable pseudo-tile layers, where the old tiles are represented like individual image assets. They can be moved, deleted, and possibly copied, but cannot be added. This means that everything must be manually rebuilt from scratch... which may not seem like a huge deal for an art overhaul project, but every single piece of code that works with tiles must also be modified to suit the changes to tile layers. More importantly, it is completely impossible to place the new tiles outside of the room boundaries. This kills our ability to make widescreen graphics function at all unless single-width rooms are manually resized and a vast amount of positioning code is completely reworked. | 02:34:52 |
Chief Idiocy Officer | ## Object depth In GM:S 1.4, all object definitions (which I will henceforth refer to as classes because GameMaker nomenclature is completely asinine) include a definition for depth. In GMS2, this property has been completely removed to encourage use of the new layer system. This is generally a good change, but it is a vastly different design paradigm from GM:S 1.4. To make this work when porting, GameMaker creates a massive array-based data structure that maps classes to their depths and then references this in the compatibility version of instance_create() . This eats a ton of memory and is always present. You can - and should - try to replace it, but your two options are both bad: either you a) hardcode the depth into the creation event of every object (does not cooperate with the new layer system), or b) rewrite everything to use relative depths and layers. A is difficult to maintain - particularly because layers are pretty aggressive about choosing their own depths - and B is a vast, vast project that affects virtually every class in the game.## Layer alpha Layer alpha doesn't exist in GMS2. At all, in any reasonably accessible form. It used to be a property that you can directly manipulate in GM:S 1.4, which enabled the fadetiles system, but it doesn't exist in GMS2. Your only tolerable options are to write a fairly convoluted system that assigns a shader to the layer, or to use a slow iteration loop to manually set the alpha of every tile on the layer individually (if that even works, never bothered trying). | 02:35:00 |
Chief Idiocy Officer | Redacted or Malformed Event | 02:35:09 |
Chief Idiocy Officer | # 2) AM2R's reliance on specific quirks and behaviors of GM:S 1.4 These are much like section 1, but are less about intended features and more about changes to "non-guaranteed" behavior. You can skip this one too if you don't want technical. ## Collision order AM2R relies on the relatively straightforward fact that in GM:S 1.4, whatever object is created first will be detected first when doing a collision check against overlapping hitboxes. GMS2 does not guarantee this behavior and can change the collision order for overlapping hitboxes under several circumstances. This breaks a significant amount of the game's collision-based systems - particularly projectiles against doors - and is very non-trivial to solve for each involved component. It is also very difficult to troubleshoot as collision reordering can happen under a few different circumstances and they are in no way guaranteed to consistently shuffle the collision order. ## Room persistence This is by far one of the biggest showstoppers from a technical standpoint. AM2R's pause system does not truly pause the game; instead, it sets the current room as persistent to save its state and then moves to a different room for the pause menu. This is a (fairly) stable option for pausing the game in GM:S 1.4, but it has at least one behavioral change that makes it very unstable for AM2R: room persistence does not maintain a room's collision order. Pausing and unpausing the game is enough to trigger a collision reordering as described above, breaking many gameplay objects. | 02:45:39 |
Chief Idiocy Officer | Redacted or Malformed Event | 02:45:57 |
Chief Idiocy Officer | # 3) Modding A GMS2 port would destroy our modding community. A huge amount of what AM2R is today - and what it will be in the future - is because of what people were able to create with various modding tools. ## Modding tools GM:S 1.4 is in a unique position where the modding tools that exist for it are capable of effectively serving as an entire software development stack for GameMaker games. Literally any aspect of a GameMaker game can be created and implemented from scratch using the UndertaleModtool (UTMT); changes to the GMS2 format remove a large amount of modding tool compatibility, and if I recall correctly changes to how code is compiled and interpreted have removed the ability for modding tools to manipulate code altogether. If not now, this will certainly be the case in the New Runtime, which we'll talk about in section 4. So what, you ask, why can't they just use the GMS2 IDE? Good question. ## Using GMS2 Using GMS2 is simply not an option for a large portion of people who want to mod AM2R. For a long while, GMS2 was a subscription-only platform; I do not trust YoYo Games and Opera to not move back to this model in the future. It actually looks a lot better than I expected right now looking at the page - free desktop and mobile exports for non-commercial is great - but I have no intentions of hitching AM2R to this ecosystem with no means out if they change the purchase model again. Additionally, source editing AM2R is fairly prohibitive as we do not distribute the audio or visual assets with the source; they must be extracted from a compiled copy and reinserted into the source code locally. This makes the setup for modding rather unwieldy (just ask anybody who's tried to work with the current source instead of UTMT). | 03:00:47 |
Chief Idiocy Officer | * # Okay, so why no GMS2? Lots of reasons, but they fall into four general categories: 1) Fundamental incompatibilities between GM:S 1.4 and GMS2 2) AM2R's reliance on specific quirks and behaviors of GM:S 1.4 3) Modding 4) The New Runtime I'll address what I can remember off the top of my head in each category, which will be posted as individual messages underneath this one because I'm a bit long-winded. | 03:01:27 |
Chief Idiocy Officer | * # 3) Modding A GMS2 port would destroy our modding community. A huge amount of what AM2R is today - and what it will be in the future - is because of what people were able to create with various modding tools. ## Modding tools GM:S 1.4 is in a unique position where the modding tools that exist for it are capable of effectively serving as an entire software development stack for GameMaker games. Literally any aspect of a GameMaker game can be created and implemented from scratch using the UndertaleModtool (UTMT); changes to the GMS2 format remove a large amount of modding tool compatibility, and if I recall correctly changes to how code is compiled and interpreted have removed the ability for modding tools to manipulate code altogether. If not now, this will certainly be the case in the New Runtime, which we'll talk about in section 4. So what, you ask, why can't they just use the GMS2 IDE? Good question. ## Using GMS2 Using GMS2 is simply not an option for a large portion of people who want to mod AM2R should the purchase model change again in the future. For a long while, GMS2 was a subscription-only platform; I do not trust YoYo Games and Opera to not move back to this model in the future. It actually looks a lot better than I expected right now looking at the page - free desktop and mobile exports for non-commercial is great - but I have no intentions of hitching AM2R to this ecosystem with no means out if they change the purchase model again. Additionally, source editing AM2R is fairly prohibitive as we do not distribute the audio or visual assets with the source; they must be extracted from a compiled copy and reinserted into the source code locally. This makes the setup for modding rather unwieldy (just ask anybody who's tried to work with the current source instead of UTMT). | 03:02:24 |