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. Nintendo Switch Pro controllers don't work on PC over USB: try Bluetooth, or use Steam.
The YYC module should detect changed files and only recompile those needed but it occasionally loses track, especially after adding scripts and objects. To solve this, hit the Clean Cache button (the little brush next to the debug/play/stop buttons in the IDE) to force GameMaker to recompile from scratch. You can also delete specific files from the cache to force a smaller and faster partial recompile but this is often more trouble than it's worth.
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.
While GameMaker's animation system does not advance when frames are dropped, (such as while dragging the game's window around) the value of delta_time will. This means delta_time can get much larger than you might expect which can break timings in your game. You should cap delta_time to mitigate this problem.
<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 mostly 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) small differences in very small frame times will have 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 is negligible.
Whatever you did to make your fps_real dip, you can do it another 300 times and still hit a 60FPS target.
A variant of the above. fps_real is a poor metric to begin with, and targeting a framerate far above the update rate of every display in existence is unnecessary. If you really want to target very high framerates, shoot for 240FPS when measuring with the native fps variable. To be clear: this is still ridiculously high but at least it's somewhat reasonable.
Turn off Feather (at least for the duration that you're doing lots of heavy room editing).
If you still want to use Feather, starting in GMS2023.11 you can go into Feather preferences and hit the Do not analyze project for Room Instances with auto-generated names and/or Do not analyze Room Instances options to alleviate the worst offenders.
Try using gmsched.
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)).
See the special Spine page for some pointers.
GPU scissor functions operate in "surface pixel space". This means that you need to set up the scissor coordinates by counting pixels on the surface itself instead of pixels in the room or on the view.
When using scissoring on the backbuffer in the Draw GUI events, the surface pixels to count are the number of pixels on the window itself. The scissor functiona do not respect GUI offset or width/heighr/scale.
(For those into their graphics programming, the GPU scissor test happens in normalized device coordinates. GameMaker presents this to us as a familiar pixel metric instead of the actual normalized coordinates.)
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.
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.
This happens when something you are drawing does not provide the attribute data that your shader needs. For example, if you apply a shader that expects texture coordinates, onto a draw_rectangle, it will fail. A common workaround is to have different versions for you shaders depending on what you're drawing (e.g. shd_basic, shd_textured, shd_textured_normals, etc).