Revel

I was working on a game, but ran into a bug that stopped my progress on the game.So I submitted a bug, and it has since been resolved. However, I'm wondering when fixes are actually published to the beta or stable update channel. As of right now, the bug hasn't been pushed but I may be using the stable channel. How can I switch to the beta channel, and how often are batches of bug fixes released?

I'm currently working on a game where the user must solve a puzzle by building structures in "Edit mode", and then presses play to simulate the game and see if their construction solves the puzzle. Much like a bridge building game where you build a bridge and press play to test it out. When the user is building in edit mode, the game creates instances as the user constructs things. When they press play, these instances are deactivated (so they aren't drawn anymore), and for each instance, a physics object is created so it can be simulated.

When the user wants to go back and edit their creation, they press "Edit" and every physics instance is destroyed and the "edit instances" are activated, so they are drawn again and the user can continue constructing their solution.

However, my game slows down eventually. If I switch between "edit mode" and "simulation" mode enough times, the FPS will drop and drop until the game is unplayable. However, I've verified that I'm properly deleting fixtures after binding them to an instance, and I've used the debug feature to verify that all the instances are being destroyed properly. However the FPS still drops after a while. It seems as if there is a memory leak or inefficiency in the core of the GM runner that is causing the game to slow down after many instances/physics objects are created and destroyed repeatedly.

Now, I'm not switching rooms or anything, I'm just repeatedly creating and destroying physics instances in the same room. I'm wondering if switching rooms would clear out any leaks that are occuring. However this would be a lot of work, so I'm wondering if anyone has advice.

Can anyone provide insight on this issue?

Edit:

I changed it to switch rooms when switching from edit to simulation mode, but it's still slowing down after switching enough times.

Edit2:

After investigating further, the problem seems to lie in: physics_joint_get_value();

I'm guessing as more joints are created throughout the game, GM makes a larger and larger map/vector or whatever maps the joint ID's to the Box 2D b2Joint*. Then whan calling physics_joint_get_value(), it has to look through a larger and larger lookup of nonexistent joints.

Any workarounds for this?

I haven't actively been paying attention to the development of GM:Studio, but I do come check it out once and a while to see whats new. I've been waiting for socket/networking support before I even think about buying GM:Studio, and According to This, its extremely far away on the road map. I think sockets is much more important than Shaders, "Flash asset importer" and some other stuff on that list, I personally think it is a fundamental feature needed for game development these days.

Anyway, I've been quite impressed with GM:Studio the last few times I have checked it out, but without sockets, I'm not going to buy it. Why is it so far away on the roadmap? Sockets are very easy to implement since the bare minimum required is a connect/listen/send/recv function. I'm wondering what makes all that other stuff a higher priority than sockets?

I'm ready to drop $499 on the full package as soon as networking/sockets is added.

Thanks

Someone PM'ed me recently asking for a DLL that can capture a rectangle on the screen and return the pixel data as one long string for GM to parse, which would supposedly be faster than calling the DLL for each pixel.

I know parsing the long string would be slow and the string could possibly be massive (~180000 characters for 100x100 square).Instead, this DLL works with buffers where you:

• Create a buffer
• Capture the screen to that buffer
• Read pixel data from the buffer
• Destroy/free the buffer

This is much faster than the previous version that captured the entire screen everytime you wanted to grab one pixel. This version allows you to capture a specified rectangle at specified coordinates.

You can also save the captured data to a bitmap file.

An example of usage:

SC_Initialize();
Buffer = SC_CreateBuffer();
SC_CaptureScreen(Buffer,0,0,100,100);
SC_SaveBMP(Buffer,"file.bmp"); //Save to a bitmap
//Read pixel data using SC_GetColor(Buffer,x,y)
SC_FreeBuffer(Buffer);
SC_Free();

Also comes with SC_GetMonitorCount() for convenience.

Download:
Here

Screenshot:

Can almost capture and render a 100x100 box in realtime. Unfortunately GM's DLL calling and pixel drawing is way too slow to render much more in realtime.

Let's discuss ideas on why YYG is rolling out buggy Game Maker versions, and alternatives on what they could be doing.

Why don't they keep an "unstable" build and a "stable" build like most developers do? I mean, after all YYG is a professional company right? Or so I've been told.

Some people can't even get the "goodness" of GM8.1, or any new version because new features will come with bugs, or at least other features that have been broken or bugged.


Sarcasm aside, my proposal:

Keep a stable version of GM, and stable updates are pushed to the public.
An "unstable" version would always be updated to the latest build, as unstable builds (aka all the current builds that are being pushed) would be pushed to this version.
People using this version would be getting the latest features, at the risk of having a slightly buggier version. Their feedback would affect the stable versions that are pushed publicly.


Any ideas?


inb4 GM is not buggy

Plenty of topics have been created with regards to GM bugs and changes.
Many people are still using GM8 including myself. 8.1 doesn't even run on my computer.