M
MishMash
Guest
Hey, had a bit of inspiration today and made a quick little test to see if it were possible to create a simple multithreading system in GameMaker. I know it's a feature that many people want, and it took me about 10 minutes to get this working:
Goals and Features:
Video:
This video is a discussion and pratical example of the system
Method:
By injecting a small amount of C++ code into the YYGML.h header which gets included in every GM YYC project, and a few replacement C++ scripts for generated GM script files, we can achieve this system with relative ease, taking advantage of the simplicity and clean interface of C++ 11 threads.
Pretty excited for the potential and simplicity of this. Naturally, GM doesn't enforce any concurrent code design patterns such as locks, so it would be entirely up to the user to ensure their code was thread-safe. Though, given the nature of threading, most processing related things just work, though you naturally will get bugs if two things try to use/modify the same thing. It is however ideal for Embarrassingly Parallel problems where the data being modified in each instance is completely independent between threads.
In order to have a good idea of what is going on, I recommend watching the video.
Disclaimer:
As this involves modifying generated C++ code, it doesn't fall under any support for GM so if you do try any of this out, do so at your own risk.
I'd like to try and start a discussion about the utilisation of this, and whether it is something people would consider using, or ways in which this system could be designed differently to cover a better use case. Note that given how this is achieved, there is a user practicality limit, so I would want to limit the system functions such that:
- Generated GM script files do not need to change once compiled once. (No change as a reuslt of unrelated changes elsewhere)
- Minimal modifications to shared GM header, which do not have any impact on ordinary execution.
Goals and Features:
- Multithreading and concurrency of GML code itself without the need to use an external DLL or Networking, as these rely on moving data around and incur additional overhead.
- Systems for managing threads, checking completion status etc;
- Non-blocking modification of any GM variable/datastructure
- Access to a good number of GM functions
- Simple integration and utilisation. Currently functions as a replacement for script_execute called script_execute_async which can return a thread_id that could be used in other functions.
- Goal is to allow the offloading of heavy tasks to separate threads as to not block the main thread. Or improve quality of life by having routines such as level generation not impact performance
- Ability to set maximum number of cores an application can use to avoid consuming too many system resources
Video:
This video is a discussion and pratical example of the system
Method:
By injecting a small amount of C++ code into the YYGML.h header which gets included in every GM YYC project, and a few replacement C++ scripts for generated GM script files, we can achieve this system with relative ease, taking advantage of the simplicity and clean interface of C++ 11 threads.
Pretty excited for the potential and simplicity of this. Naturally, GM doesn't enforce any concurrent code design patterns such as locks, so it would be entirely up to the user to ensure their code was thread-safe. Though, given the nature of threading, most processing related things just work, though you naturally will get bugs if two things try to use/modify the same thing. It is however ideal for Embarrassingly Parallel problems where the data being modified in each instance is completely independent between threads.
In order to have a good idea of what is going on, I recommend watching the video.
Disclaimer:
As this involves modifying generated C++ code, it doesn't fall under any support for GM so if you do try any of this out, do so at your own risk.
I'd like to try and start a discussion about the utilisation of this, and whether it is something people would consider using, or ways in which this system could be designed differently to cover a better use case. Note that given how this is achieved, there is a user practicality limit, so I would want to limit the system functions such that:
- Generated GM script files do not need to change once compiled once. (No change as a reuslt of unrelated changes elsewhere)
- Minimal modifications to shared GM header, which do not have any impact on ordinary execution.