A straight-forward guide to mitigating the various harms committed upon society by YoYoGames' masterwork of digital torture, GameMaker.
PRs welcome. Share your pain.
Try running the game in YYC to generate a C++ project, and then run the generated solution file through Visual Studio's debugger. This'll hopefully point you in the right direction. Even if you can't solve the problem, it'll make for a more informative bug report to YYG.
Sure is. Strap on the proton pack and take a look at some tips on busting HTML5 ghosts.
To see your exports, you need to be logged into your Opera account. If you're logged in, but still don't see them, log out and log back in via the blue account icon in the top-right of the GameMaker IDE. This is a bug and will hopefully be fixed soon (issue has been present since version 2022.2.0.71, 2023-03-03).
Usually a result of GameMaker missing configuration data for that particular make and model. Might be solved by using Input or by adding an updated gamecontrollerdb.txt to your project's Included Files.
Also often caused by a broken/missing/outdated Visual C++ redistributable. Try installing this (Visual C++ Redistributable for Visual Studio 2012 Update 4).
fps_real only measures what you're doing on the CPU. You're likely GPU-bound. Turn off graphical effects, turn off shaders/effect layers, reduce particle counts, reduce rendering resolution, draw less to the screen. Use RenderDoc to identify particular pain points.
<insert library name here> is taking up 50% of a Step in the profiler and I am very worried about it.
The GameMaker profiler is deceptive and the percentage measurement is nigh useless due to the way it's calculated. The bit that's actually important is the time taken to execute the function. If the execution time is less than 1ms then you're getting your knickers in a twist about nothing.
Don't worry about it. fps_real is deceptively useless and the only thing it's really good for is making people panic needlessly.
Frame rate is inversely proportional to frame time, which means that (among other things) minute differences in very small frame times will have seemingly disproportionately large effects on the fps_real. What you really care about is the frame time, or the amount of time it takes to deliver a frame. This means you have a budget of about 16.6 ms to do all of your Step and Draw event processing if you want to maintain a refresh rate of 60 frames per second. An fps_real value of 5000 means that your entire game is finished with its update tick in 0.2 milliseconds, and an fps_real value of 4000 means that your entire game is finished with its update tick in 0.25 milliseconds. That's a difference of 0.05 milliseconds, which profesional game developers like to call "a vanishingly tiny proportion of your frame time budget" (it's about 0.3%).
Whatever you did to make your fps_real dip, you can do it another 300 times and still hit a 60FPS target.
Turn off Feather (at least for the duration that you're doing lots of heavy room editing).
Often caused by a broken/missing/outdated Visual C++ redistributable. Try installing this (Visual C++ Redistributable for Visual Studio 2012 Update 4).
Often caused by a broken/missing DirectX 9c runtime. Try installing this (DirectX 9c via DirectX End-User Runtimes (June 2010)).
Try using gmsched.
This is a known issue and maybe it'll get fixed some time. In the meanwhile, you'll need to manually adjust the rendering position of primitives yourself. On Xbox, for example, the top-left corner of draw_rectangle() will need to be moved right 1 pixel and down 1 pixel. This impacts many primitive-drawing functions cross-platform - happy hunting!
On Nintendo Switch the colour channel order looks off when I'm using vertex buffer functions, shouldn't it be the same as other OpenGL platforms like Linux?
It should be but it isn't. On Switch, the colour order is the same as Windows even though the graphics backend is OpenGL. (When using Scribble you might want to edit the __SCRIBBLE_FIX_ARGB macro to cover os_switch too.)
If you've created a mockup in Photoshop, Figma, GIMP, etc. and then tried to replicate it in GameMaker, you may notice that the font in GameMaker is rendered somewhat bigger than in the mockup despite font point size being the same. This is happening because of inconsistent DPI settings: image editors often have their default DPI at 72 while GameMaker's is 96. To fix this issue you, multiply the image editor's font values by 0.75 (so 48pt in Photoshop becomes 36pt in GameMaker Font Editor) or change the DPI in the image editor to 96 pixels per inch (without resampling).
1.00 rev 17. Older versions of GameMaker have patchy support for standard derivatives, and no current (GMS2023.6 and before) versions of GameMaker natively support vertex texture fetching outside of HTML5.