itch.io

Unfortunately, I don't know 😅

If the demo apk installs and runs on the quest, then I'd suppose it works (but would technically be unsupported since I have no way to confirm it works, since I don't have a quest to test on)

If the demo apk doesn't run on the quest, then I would take that as confirmation that this isn't compatible with the quest at all. 

As for whether or not a quest version is even possible, I would say it's almost certainly possible (assuming GameMaker apks are quest compatible - something yoyogames won't have tested since GM is not designed with VR in mind). If the quest SDK can be accessed through either java or c++, making a wrapper for it that GameMaker understands would probably be a similar process to making this cardboard version

Accidentally over-scoping the test project and have too much going on to get it done in time. Will instead be doing a local test using Too Many Birds, if it all works out I hope to still publish the update on schedule 

(also considering glTF import support long term...)

...and we are done, minus documentation, shapekeys export even with generative modifiers (as long as the number of verts and loops is the same as the basis shapekey - so some modifiers like degenerate may still disable some shapekeys. Just gonna do my mini game test and we should be out soon! Would you believe the hardest thing to figure out was getting blender to clean up copied meshes when I was done with them? Annoying, but it's done

Also considering making a file upgrader script, to convert the old mmod files into the new mmk files with the new features, to ease the transition a little more than the compatibility functions already do Ok I did it, couldn't help myself. There's a function to convert legacy models into the new format (subbing in data in some cases, but it works), so if you've lost the source model, they'll auto-convert through MMK_model_load, or you can manually call MMK_upgrade_old_model and save out the returned buffer to save on repeat conversions. The result won't be as accurate or feature-rich as re-exporting your raw models, but this should reduce teething issues when I get the update published

OK, the implementation checklist is complete. There are a few compatibility scripts and materials that work with the demo project (with a few minor edits, but nothing complex and results are identical with much better performance than expected)

So there are 2 things to do - test it over the next month or so to make sure I don't give you something broken, and make blendshapes with generative modifiers work (which is just a blender script update, my plan is to get that done tomorrow)

And documentation, I suppose :P that one helps a lot

Over-compensating for lack of updates probably, but there are only 2 tasks in the way of release now: Documentation, and compatibility functions (to aid porting from the old version) 

I need to make a tweak so blendshapes/shapekeys can be exported from blender objects with generative modifiers (currently they just aren't exported if you have something like subsurf or mirror active), but that is lower priority, arguably a non-blocking nice-to-have thing, since shapekeys do export and function if you have no generative modifiers

I'm debating finishing and releasing the update within the next 10 days, OR jamming out a game to make sure it's production ready and then publish it at the end of october. I think for safety's sake I should do the production test, even though I'd love to get this upgraded and functional version out ASAP. I think I'd rather put out something well vetted and well documented that should hopefully last longer with more modern versions of GameMaker

I've been working through this over the last couple of days and I've pretty much finished the updated GML-side code now. I think I just need to provide a compatibility layer + update guide for the old system and it's pretty much done. I'm hoping that when I say Soon­™ I actually mean it this time

I have been not very on the ball while I have a job (I've only been able to poke at this when not working and also not tired), but I'm still planning on rolling out an update to this Soon™.

Details are as follows:

• GameMaker has changed too much over the years, and the old methods are too slow. I've gotten a little more clever too (I think), so the system has been rebuilt from the ground up
• GameMaker's new garbage collector has forced me to drop the GML implementation. Too much garbage gets generated by matrix functions, and alternate garbage-free methods are too slow - essentially, the system is slower (and in many cases doesn't even run) on any version of GameMaker released after the garbage collector was introduced.  As such, the entire core has been ported to external C++ libraries, with GML structs wrapping the operations
• Advantage of the new C++ port is that everything is much faster and more flexible, though you won't be able to modify the core anymore (unless I sell a version with C++ source access, but I barely have time to provide support for the current version, let alone support for C++ code)
  • The C++ version also cannot be broken directly by any further changes to the runtime
• The major disadvantage is not all platforms are supported out of the box. The supported platforms are as follows:
  • Windows x64
  • MacOS (both Intel-based and Apple Silicone have been tested working)
  • Ubuntu+SteamDeck
  • HTML5 via WebAssembly (it honestly works way better than I ever expected, especially considering the previous version never worked on HTML5)
  • Android
• Remaining platform statuses are as follows
  • iOS - Unsupported, but in progress - I built a binary, but lack of clarity from Apple on what is required to make a dynamic library that can be distributed via the App Store has thrown a spanner in the works in making sure this works in an acceptable way (and it's hard to tell if I can make an "approved" build compile with GameMaker's current extension system)
  • tvOS - I don't have a tvOS device, and I don't plan on buying one. Maybe it would work if iOS builds are made, but I don't know how
  • Consoles - Without access to NDA'd build tools, I can't make this work on console. However, if you have access to console SDK's or a publisher who knows how to use CMake, we could probably make an agreement to share the source code so they can compile it on those platforms.
  • GX.Games - this platform does not support non-GML extensions at time of writing. If/when support is added for JS or WASM extensions, it should be really quick to add support for this platform to the extension

Some other limitations: 

• 64 bones per armature. The plan is to increase this limit to either 128 or 256 (hopefully before release), but this will have an effect on performance, I'm just hoping it's a small effect
• I'm officially dropping plans for a 3D collision implementation as part of this system, which shouldn't cause any problems since it was barely usable anyway. It's a lotta work to get right by myself, and there's no good way to make a one-size-fits-all solution with reasonable performance at this time. Maybe that'll change in with the new runtime, but my current recommendation is to build your own tailored systems on top of something like bullet3d in C++ (or hire me to do it for you 🤫)
• Uh I actually can't think of any others compared to previous versions. I thought there'd be a longer list

The initial delay has been because I can't figure out how to get the new code to compile for iOS and remain allowed on the App Store (there's some unclear information on the acceptability of dynamically loaded libraries and I don't want to port the C++ source to Objective-C or whatever and have to maintain 2 codebases - so until I can work that out, no iOS support, even though I really want it to be ready to add to Too Many Birds)

However, I've decided it's better to get this out and working again rather than wait an indefinite period for iOS support and leave you with something that barely functions with new GameMaker runtimes. 

The Core is complete (minus a few concept features, like a built-in IK solver), so I just have to flesh out a few of the interface structs. Stuff like mesh binding and materials, then I'll enter a test phase and get the new version out, alongside some upgrade documentation and compatibility scripts. I will also put a live demo on the store page, since the HTML5 version works now

Even though it's a total rewrite, upgrade will be free for existing users, I'm considering bumping the price up later, but not sure yet

Compatibility with the latest IDE should be ok, but the latest runtime that is confirmed to work is runtime 2.3.0.401 - there's some change to GameMaker that breaks it afterwards

I will be updating the system Soon™, so that it will work with newer versions - it's a complete rewrite that adds a lot of extra features and performance gains, but I have to find time to work on it between work contracts and such. I do need it for one of my games I'm working on, so it is coming, but it could take 3-12 months before it's ready

Thank you for your interest!

Only a year late (oof, sorry about that), but it looks like I am going to be focusing on this on my weekends shortly, since something important has broken when used with newer runtimes. 

I would guess the tangent stuff was commented out due to the weird way gamemaker handles format types and GLSL ES, but it's been so long I don't remember the specifics. Hopefully the rewrite will address this

Ok, so good news and bad news. The fix for this crash was pretty simple, but after fixing it I found out that something has changed in the GameMaker runtime at some point that has broken something else which stops rendering from working. 

The current quick fix (to both issues) is to roll back your runtime - everything seems to be working adequately with runtime 2.3.0.401, other newer runtimes may work too. It's not a perfect solution but it's all I can offer for now. It should at least let you start experimenting with what you can do

Thank you for highlighting this issue for me. Since I'm not sure what specifically is broken, I think it's time for me to raise the priority on doing the complete re-write. It's probably going to take a bit of time since I need to work on it between contract work, but hopefully I can have it in working condition within the next month or two. It should simplify animation/blending and stuff and boost performance, but it will also have a different API (making use of structs and such)

As I've been working on a job, I've discovered that the garbage collector HUGELY impacts the performance of the system. This was not an issue when I first made this thing, since the garbage collector didn't exist (at least, not in the same way)

It's not super noticeable with low-bone count armatures on higher end hardware, but it actually gets pretty bad pretty fast, resulting in stutters of up to half a second thanks to the garbage collector needed to clean up a lot of mess. 

Unfortunately, there's not an easy quick-fix I can suggest for now - matrix_multiply, which is quite essential for this thing, allocates a new array each time it is called, and marks the old array in place as garbage. So for any non-native targets, there is a terrible performance impact. I can't just remove this function, and replacing it with a GML-based byRef version results in significantly worse performance. 

The solution: In a later update, animations will be driven by native C++ on as many platforms as possible. Other platforms will still have the GML as a fallback (and HTML5, if it ever works, won't suffer as badly due to its different GC pipeline)

It might take me a while to get this sorted since I have less free time now, but I'm hoping to get stuff updated soon in a much better way - it'll be pretty much a complete re-write, but I'll not be selling it as a separate thing, so don't worry about needing to pay twice

Bit late to the party, but I believe YoYo fixed this a while back

That's not good! I can't check things out right now, but I'll see what I can do this weekend and push out a fix if necessary

All done, thank you for the reminder!

Basic setup and usage is here: https://youtu.be/GyEbLzovVOA

Text-based documentation is here: https://docs.google.com/document/d/1nGKWqkGdxnnO9zO28S15vHw4pzldvPHfZIUEKDtMzQw

Both of these should now be on the main page too

I'll add a gif if I can make one that both shows off stuff sensibly and is less than 3MB

Hey!  Thanks for your patience - I've been a little busy recently.

What sort of differences are you seeing? Are you able to capture a video of the difference? Are both the GameMaker extension and the Blender script fully up to date (I have done some animation bug fixes somewhat recently)

I might have to peek at the original blend file (privately, of course)  if we can't figure it out here so I can check the setup - there are some restrictions with respect to euler rotations, if you are using those at all (only YXZ is allowed)

I'm in the middle of rewriting the export/import and animation system, so this is actually a good time for me to check for fix this sort of issue.

Oh, I should also mention, I'm working on a bit of an overhaul for the new version so it can benefit from GameMaker 2.3 features and allow me to add more features more easily. It's taking some time, but in the meantime the current version works fine.

It was pointed out to me by a cool user that there was a memory leak. I have now pinpointed it, but it appears to be a GameMaker bug (wonderful...)

In a recent update, I gave materials more power by letting them change GPU options on an individual basis. I reset this with gpu state functions, so you don't have to worry about conflicts. It turns out that gpu_get_state() (which is used by  MMK_armature_draw) causes some kind of memory leak, even with the map destroyed. Even "ds_map_destroy(gpu_get_state())" causes the exact same leak!

If your materials don't change any GPU states, you can fix this by setting the value of "MMK_auto_handle_gpu_resets" to 0 or false by double clicking the extension in the resource view, double clicking "MMK_Models.gml" and opening macros and finding it in the list there. The latest version of GameMaker wasn't updating this value consistently for me, so try closing and re-opening the extension window to double-check that the value has changed. 

I will report this bug to YoYoGames, so hopefully this will not be an issue in future!

Submitting my SkyBox Generator: https://maddestudios.itch.io/mms-skybox-generator

And my Twitch IRC GameMaker extension: https://maddestudios.itch.io/mms-twitchtv-irc-interface-for-gamemaker

The best way to contact me (especially in this case) is probably by sending an email to MaddeStudios@gmail.com (I'll add that to the description). I'll send you a code so you get access to all the resources available on the Itch page.  It helps if you can include some kind of proof of purchase, but if your email matches the limited details I have from YoYo Games, that works too!

Thank you for picking the extension up!

Due to request, I have added a simple demo of realtime shadows to the example windows executable and to the practical project source code. 

There is a little inconsistency in naming (I accidentally switch between lightmap and shadowmap a few times), but the code is commented. 

I intend to to a video/text post at some point in future explaining how this works in more detail, hopefully allowing more people to add shadows to their games in general.

The version with shadows is currently available at no extra cost.

The error message suggests that the macro "PUBLIC_TWITCH_CAP_ALL" has not been defined, which doesn't make much sense - did the scripts import correctly? The macro is defined in "twitch_connect", so you might have to check that script to see if it has loaded correctly.

I'm a little confused by the second question - I don't believe I used any sprites in the demo project, nor in the video - could you clarify what you mean please? Pictures may help me understand.

Yes, you can modify the demo to send messages to Twitch quite easily! 

I think the simplest way is to do something like this:

Add a key press event (I chose Key Press Enter) and add this code to it:

if(twitch_check_connected())
{
    twitch_send_chat_message(get_string("Send Message","message"));
}

If the demo is currently properly connected to a twitch chat, this will open a textbox when enter is pressed, and will send the message once confirmed.

For non-test purposes, you should use async input functions - or better yet, custom text inputs - but this test code gets the job done in a simple enough way.

I don't know if it is possible to send DMs on itch, but you can send an email to MaddeStudios@gmail.com if you want! 

Ok, I've checked it out and it turns out I made a mistake and accidentally uploaded the wrong file. Whoops! I've now checked the project again, updated the version of the IRC extension it uses and properly uploaded a YYZ file instead which can be imported into GMS2. 

Thanks again for letting me know about this, I hope it works for you!

Hello!

Thanks for letting me know. I'll give it a check to see what's wrong and get back to you once I've figured it out. Hopefully just later today.

Just gonna post a little progress update on 0.5.X! While the update is not public yet, here's what's been done so far:

• Exporting and rendering ShapeKeys (or morph targets/blendshapes) has been implemented and tested and seems to work well! Note that there are some specific requirements and caveats for exporting them, due to some Blender restrictions
• Support for exporting all UV and color layers for meshes is done
• Various things in the exporter have been fixed/stabilized
• Made it possible to get the current output matrix of a bone, even while pose-caching is active (e.g. Allows characters holding objects in the right place without fully re-calculating the pose)
• A rewrite to how animations are handled is under way
• Made the system write much more useful info to the Blender Console (Window>Toggle System Console) and added the option of writing this info out to a file. This includes some export information (scene scale, left-handed conversion), as well as vertex format info, ShapeKey indices and what has been exported
• Changed the file format a lot. Uh-oh....

What are the caveats related to Shape Keys?

Well, the most major one is that Blender cannot apply modifiers to a mesh with Shape Keys, so I cannot apply modifies to such meshes. The reason seems to be that Blender applies modifiers to an imaginary mesh after applying the shapekeys to the base mesh, so results can vary wildly between Keys. The solution is to just make meshes without modifiers if you intend to use shape keys, though I plan to at least emulate the mirror modifier on export (and perhaps allow it to make mirrored shapekeys separate)

Another important thing to note is that ShapeKeys add more attributes to your vertex formats, so more specific shaders are necessary for each. The vertex formats needed are written to the Blender Console. Because of the need for these extra attributes, meshes can now also have individual vertex formats within a model, to reduce redundant data in meshes that don't use certain info and increase compatibility.

I know in software like Unity or Unreal you wouldn't need to make a shader for every single mesh, but that's because they already kinda do that for you. If the GameMaker IDE gets plugin support (which is looking less and less likely...) I'm considering making a tool that could generate all the shaders you need for your meshes from a base. 

Animation re-write?

Yep, I'm changing how animations are handled. They are the main reason this kit exists, and they need an update. It's not a complete re-write, but the fundamentals are changing.

Why the change? As I was working on shape-key support, I realised it would be nice if we could also use animations that target values other than bone and object transforms. I then also realised the way I was writing was rather messy and wrote potentially incorrect values, and that the way they are stored and read could be greatly improved to hopefully improve accuracy, performance and provide more options. 

This will basically give us a whole bunch of benefits:

• Animations will be more accurate between Blender and GameMaker
• Animation code should be simplified and easier to maintain
• Automatic caching of some values should be easier, to make animation driving more performant (Even without pose-caching)
• Interpolation Modes of individual keyframes can be written and interpreted, allowing more accurate animation without baking frames (Except bezier, for now)
• Animations that do not affect certain properties of a transform will not reset it. 
• Hopefully, this will allow a dual-quaternion skinning mode to be activated, to improve performance, increase bone-count limits and preserve volume (this will be optional, but quite handy - especially on mobile platforms)

This requires a change to both the export, the import and how animations and bones are stored and handled and requires me to update the C++ code as well as the GML. It should be worth it though!

File Format Changes?

As I was working on shapekeys and animations, I realized the way the files were written was fundamentally flawed. It worked for the originally intended purpose, but as I've been adding these features, it became clear that it just wasn't expandable. The new format means that if I need to change or add features, it is far easier and does not require a re-write of any systems. Note that trying to load a new feature into an older MMK thing will abort the import and only load the features written before it.

Luckily, the files have always had a "Version" value written as the first entry, which does mean that the system can detect and load files using the current, soon-to-be-outdated format, they just don't have access to the newer features, and the current version of MMK will be unable to load the newer files (it WILL crash, as I never made it check if the version was 0 or not). Eventually, loading of "Version 0" files will be removed, but for now I will try to keep it working. This is just one of the effects of this being a Beta.

Since this file-format seems more final, too, I can also document it in case anyone wants to load them into other software. 

OK! Update over. This is sorta rough since it's just what I'm doing and thoughts about it, but I felt like writing it. Love you bye

One final update on this:

The bug has been Resolved by the Blender Developers, and I can confirm the fix will be in Blender 2.82!

However, unless the fix is added to 2.81 and 2.81 is updated with fixes, it will remain unsupported by the export script, which basically means the scripts will work, but armatures exported to left-handed space will be broken.

Another Update on this! 

I found the root cause - bone orientations get messed up on armatures when they get flipped in 2.81 and newer, which in turn breaks the animations (since they are all releative to the orientations).

I've reported it as a Blender bug and it seems to be confirmed! With any luck, this will be fixed and the script will work with newer versions again.

If this turns out to be a bug, instead of a permanent change, back-porting the code to other 2.8X versions will be fine again. There will still be some trickiness for 2.79, but it is still probably doable too.

A little update on this:

So, animations themselves are not broken - after extensive debugging, I found they are exactly the same. In fact, if you export the animations from 2.81 and apply them to a mesh exported from 2.80, it actually works fine! So this means something has instead changed with regards to calculating blend weights, but only when converting to left handed mode. A weird bug, but at least I now have a vague idea as to where the problem lies. 

It did actually result in me making a tiny optimisation for exporting quaterions to left-handed mode too, which is nice. 

The good news is that this slighlty increases the chances of me backporting some code again!

Currently, the 2.80 export scripts are NOT COMPATIBLE with 2.81! 

Well, they are mostly compatible, but animation exporting is completely broken. Something must've changed internally which breaks the information, creating weird results in GameMaker. I'm working on an updated script at the moment, it's just inconvenient right now.

The 2.80 and 2.79 scripts should still work fine in their respective Blender versions.

This also has an unfortunate consequence: It is very unlikely that I can back-port updates to older versions of Blender from here on. The existing scripts will remain, but the changes between Blender 2.79 and 2.80 were already a nuisance, but now that 2.81 is even more different and incompatible with the 2.80 script, back-porting will prove to be even more challenging, and unlikely to be worth the time.

Any questions about the update, backwards compatibility or anything else, leave them below!

New features in this version (v0.4.0):

• Initial itch.io release! Yay!
• New mascot and demo!
• Added new export scripts for Blender 2.8
• Added better armature-mesh linking to the 2.8 export script, so now they don't need to have parent-child relationships, just the modifier.
• Added a new, basic collision system featuring raycasting and ellipse collisions. This will be documented later, when I build a fun demo.
• Extended the material system so now materials can manage GPU states individually and be ignored during certain render passes (the macro "MMK_auto_handle_gpu_resets" in MMK_models can be set to 0 to disable this). This allows materials to control whether or now they write to the zbuffer, for example. Note that global GPU states are still maintained, only those set will change.
• Fixed bugs with the material system not always being called when there is no shader change, causing visual defects in some cases
• Defined some undefined behaviour regarding passing bones to a shader
• Fixed a crash with "MMK_bone_get_transform" (forgot to comment out an unused argument)
• Added and improved armature mesh setting options, so now order can be better defined, as well as the option to check what meshes are enabled
• Added "MMK_armature_add_meshes" and "MMK_armature_set_meshes", which accept both individual meshes and mesh arrays, to streamline adding many meshes to an armature. Note that meshes are appended and set in order.
• Fixed default armature textures and materials not always being used as a fallback in cases where they should have
• Added the option to pass custom UVs to armature textures, in case you need custom ones. This can also be useful if you change a texture frequently, as it removes automatic uv_clipspace calculations.
• Made negative or < frame_1 animation setting use the first frame, which fixed an issue I believe was related to a floating point error preventing me from setting frame 0 of my test characters idle animation.
• Added some "advanced" output-matrix fetching functions, but I implemented them for reasons that don't work because I forgot, but they may be useful down the line.
• Default shaders now use blendweights and blendindices for GLSL ES as well, due to changes in how GameMaker passes inputs to attributes. I believe now names matter less, but the order of attributes is incredibly important
• Native/GML code parity maintained.
• Probably more changes/fixes, but I forgot to list them on Trello
• Functions to enable the use of "Pose Caching" - MMK_armature_set/get_matrix_output_array()
• MMK_animation_get_framecount(anim, adjust_for_gamespeed)
• Fixed another axis-angle issue (when not using native)
• When using native mode, a check is done GML-side to determine if an armature update is needed now. This was already done within the extension, but the call overhead was still apparantly eating up speed in YYC. Has little impact generally, but yields a very nice performance boost (I got a ~20% boost in the test project) for YYC when an armature hasn't changed pose and/or when using pose caching. (No real impact on VM at all though)
• A few fixes and additions relating to armature transforms.
• Fixe an export crash for when tangent export is active but the current mesh has no active UV map (zero values are added instead for now)
• Added an export option to automatically export armatures linked with the current selection. Enabled by default.
• Optimised a bunch of native code, fixed a different axis-angle issue within the DLL

My next personal goals for the project are:

• Understand how to use Blendshapes/Morph targets in Blender, and export and implement them into the Kit in some way
• Allow the export of multiple UV maps per model (Which shouldn't be too difficult). Maybe color maps too, but that's less important
• Make a basic 3D platformer demo project with the collision system
• Fix bugs?

Have fun!

Hello! I'm glad you like the tool.

Thank you for the feedback! I agree, this is definitely a feature this needs and I think it will definitely be part of a bigger update when I find the time to work on the tool some more.