Jump to content

Highest Reputation Content

#3305693 Custom Titles

Posted by KC LC on 07 October 2009 - 05:15 PM

Custom Titles
Granting Requests

Because many members have requested them, we are offering custom titles. Please don't PM the staff about this, or post questions about it in this topic. These guidelines should be self-explanatory:

  • Post in this topic with the title you want. You'll receive the title exactly as requested, so write carefully.
  • Maximum title length, including spaces and punctuation, is 20 characters.
  • Titles may only contain standard alpha-numeric (US keyboard) characters and punctuation. No special characters, diacritical marks, or accents.
  • Your warn level must be 0% to be eligible.
  • When new requests are completed, they will also be deleted from the topic. That way we will be better able to track changes that users request.
  • Do NOT request anything rude or offensive, nor anything that could be interpreted as making you appear to be a member of the forum staff.

This offer may be terminated or amended without notice, at any time. Custom titles will be granted at the sole discretion of the staff. Offensive or misleading titles, or those deemed inappropriate by the staff, will be ignored.
Humiliation resulting from a member's stupid title choice -- including (but not limited to) spelling errors, bad grammar, inflated ego, or general nerdiness -- is the sole responsibility of the member.

Offer void where prohibited by law.

  • 141

#3789385 Reputation

Posted by Takagi on 16 July 2011 - 01:53 AM

If I get 100 +'s on this post, I will consider reopening this thread. Until then, peace out.
  • 102

#4376584 Who Can Make Cool Topdown Character With Gun.

Posted by fama_h on 03 September 2013 - 10:32 AM

Are you done the colors yet? It's been 8 years. I need to finish this game already plz

  • 90

#4326624 Shader examples - source and download included

Posted by xygthop3 on 05 July 2013 - 10:13 PM

All these Shaders are available on the Marketplace here:



All these shaders and more have been migrated to the Marketplace (forever FREE) Marketplace Link



You may use any of these shaders in your game(s), paid or free. GameJolt, Steam, own website are permitted.

You may not redistribute any of the shaders/examples on the Yoyogames Marketplace, paid or free as projects, extensions, shaders, etc are not permitted.

Any questions related to these conditions please private message me.

All shaders use the application_surface, as such this will require you to be using either the v1.3.1307 Beta and above or v1.99.97 EA and above. The reason to move to using the application_surface was to try to accommodate cross-platform use of these shaders without me having to actually test on them.



  • 86

#3572419 What's the difference: collision functions

Posted by torigara on 26 July 2010 - 04:23 PM

  • Title: What's the difference: place_meeting, position_meeting and so on
  • Description: Describes the difference between collision functions and troubleshoots a common misuse.
  • GM Version: GM 5 and later
  • Registered: no
  • File Type: N/A
  • File Size: N/A
  • File Link: N/A
Additional Info
There are a number of functions to check if there is an object at the specified location. This tutorial describes differences of those functions to let you choose an appropriate one (especially between the common misused two, place_meeting and position_meeting.)

The table below summarizes the difference of functions:
Function            Checks using   Checks against     Returns
place_free          sprite/mask    solid objects      true/false
place_empty         sprite/mask    any object         true/false
place_meeting       sprite/mask    specified object   true/false
position_empty      point          any object         true/false
position_meeting    point          specified object   true/false
instance_place      sprite/mask    specified object   instance id
instance_position   point          specified object   instance id

Place vs. position
The most important difference is whether the function name contains "place" or "position." Functions those named place always put the current instance that is executing the code at the specified position and checks if its sprite (or mask if assigned) collides with another object.

On the other hand, functions those named position checks the exact point, regardless of the instance that is executing the code.

Posted Image

Here are some consequences:
  • place functions doesn't work at all if the instance executing the code has no sprite or mask.
  • place functions never detects collision with itself, whereas position functions can be used with self.
    // This one doesn't work no matter whether the instance has a sprite.
    if (place_meeting(mouse_x, mouse_y, id)) { ... }
    // This one correctly checks if the mouse is on the instance.
    if (position_meeting(mouse_x, mouse_y, id)) { ... }

Meeting vs. instance
When you use a function that has meeting in its name, it just tells whether there is an object and returns either true or false. On the other hand, functions those named instance returns the colliding instance's id, or the special value noone (-4) when there is no collision.

You may sometimes see that the return value of instance_place or instance_position is used as if it is boolean .That works because Game Maker's if statement evaluates a positive number as true and negative number as false. Therefore, "if (A)" is equivalent to "if (A>0)" and "if (!A)" is equivalent to "if (A<=0)". It enables you to use instance_place or instance_position in place of place_meeting or position_meeting. However, note that the opposite doesn't work.
// This checks if there is an instance of object0 under the mouse,
// and store its instance id to the variable inst.
// The result is noone (-4) if there is no collision.
inst = instance_position(mouse_x, mouse_y, object0);
if (inst) { // This is equivalent to saying "if (inst > 0)"
    inst.selected = true; // Manipulate the instance's variable

Free vs. empty
As summarized above, the difference of place_free and place_empty is rather trivial. The former checks if there is a solid object, while the latter checks for any object including non-solid ones. Note that they return true when there's not a collision, as opposed to place_meeting and position_meeting. There is position_empty but no corresponding function position_free, though.

A common mistake is to forget that a place function uses the sprite of the current instance that is calling the function. See the following example code: it is executed by a controller object and is meant to create an enemy in a random place that doesn't collide with walls. This likely fails to work. Why? A controller object generally has no sprite or mask, so place_free detects no collision for the controller.
// This code is meant to create an enemy in a free place
// but doesn't actually work.
do {
    xx = random(room_width);
    yy = random(room_height);
} until place_free(xx, yy);
instance_create(xx, yy, obj_enemy);

To make it work properly, we have to either give the controller object a sprite, or make the enemy object itself check for collisions.
// Create the instance first (the initial position doesn't matter.)
inst = instance_create(0, 0, obj_enemy);
// Then make it find a free place itself.
with (inst) {
    do {
        x = random(room_width);
        y = random(room_height);
    } until place_free(x, y);

  • 57

#4171574 Does anyone else have any countdowns to share?

Posted by Nocturne on 22 December 2012 - 10:20 PM


  • 55

#4398180 Who Can Make Cool Topdown Character With Gun.

Posted by Overloaded on 01 October 2013 - 05:27 PM

  • 49

#4399414 Suh Burb (Outdated - Major Iteration 4)

Posted by Chrscool8 on 03 October 2013 - 05:21 AM




(Click here to skip to the most recent update post in this topic!)


































Download link is a quick bit.ly redirect to a dropbox download. Middleman used only to count downloads. Dropbox used for high speed, ad-free downloads.




All Update Posts By Date: (Look here for cool features and videos!)
10/5/2013 - Update Checker, Debug Mode
10/11/2013 - Cave Area, Ziplines
10/12/2013 - Rewrote Ledge Grabbing
10/14/2013 - Dying Offscreen, Ragdoll Bouyancy, More Jackie Animations, Wall Crash, Rocket Boots, Admin Names Online, Crouch Run Sped Up, More Helpful Blocks
10/16/2013 - Online Chat
10/22/2013 - Multiple Server Support, Update Checker Updates
11/3/2013 - 3D City Test, Footstep Sounds On Different Materials
11/10/2013 - Day/Night System, 3D Skydome
11/23/2013 - 3D Skydome Clouds
11/30/2013 - Swimming Engine, Underwater Sound Effects
12/1/2013 - Automatic Concave/Land Physics Shape Maker
12/7/2013 - Jump Trajectory Estimator Overview, Concave Physics Objects
12/8/2013 - More Jump Trajectory Features
12/25/2013 - WinterBoarder Release
1/10/2014 - Rope Physics, Inherent Velocity Explanation
3/18/2014 - Perfect Ropes
4/12/2014 - Boat Physics
5/11/2014 - Music Chunk Engine
5/20/2014 - Live Mixing / Music Track System
8/24/2014 - Dynamic Hair Physics
8/25/2014 - Underwater Sound Effects, Eye Engine (Looking / Squinting)
9/15/2014 - New Outlining Processor
9/22/2014 - Early Main Menu
10/13/2014 - Fast, Non-Blocking File Download
10/31/2014 - New Menu Demo Release
11/2/2014 - Menu Day/Night Background, Multiple Control Methods Added
11/5/2014 - Layer System, General Rewrite
11/24/2014 - Future Plans, Running Around Emerald Hill Zone
11/26/2014 - Super DungeonMan
12/3/2014 - Dungeon's House, Old Story Ideas, 3D Hand Test
12/3/2014 - More 3D Hand
12/8/2014 - Jackie's Voice Actor
12/14/2014 - Title Cards
2/2/2015 - Crude Post-Hopping Engine
2/13/2015 - More Post-Hopping
5/22/2015 - Load Screen, Pause Screen Mockup
5/24/2015 - Menu and Title Card Integration
5/27/2015 - Menu Day/Night Cycle
5/30/2015 - Custom Level Loader Preview
5/30/2015 - Importing Enormous Custom Levels, Custom Level Loader Download
6/5/2015 - Instant Gameplay
6/7/2015 - Jackie's Super Relaxing Ice Fishing Release
8/26/2015 - Automatic Bridge Maker
11/4/2015 - Pause Menu, Steam Workshop Cutting Edge Available
11/5/2015 - This List Was Created! Early Data/Stats Screen
11/20/2015 - 100th Dev Log Video! Animation Reference Acting
11/24/2015 - Pop-Up Notifications
12/4/2015 - Custom Level Update (Backdrops, Non-blocking Load)
12/8/2015 - Difficult Jump / Repeated Area Detector
12/22/2015 - New Skeleton Animation Started, Forum Topic Makeover Begun
12/24/2015 - Snow Particles, Snowy Winter Update
1/3/2016 - NewER Animation System (All Math)
1/19/2016 - Skeleton Animation Wrap-Up
2/16/2016 - Console Commands
Recent Public Updates: (Not including internal changes listed in posts)


  • 46

#3354044 Gmogre3d - GM Port Of Ogre 3D - Supports GM 8.1

Posted by Houdini on 29 November 2009 - 10:26 PM

Posted Image

Version 1.25

What Is It?
GMOgre3D is a GM port of the extremely popular open source OGRE (Object-Oriented Graphics Rendering Engine) 3D engine. Why port OGRE to Game Maker? Simply put, the 3D support built into Game Maker only supports the most very basic of 3D functionality. If you want to get the most of your 3D games using Game Maker then you need to use a 3rd party graphics library, such as OGRE.

I choose to port OGRE in particular because it's an extremely popular 3D engine that is constantly being updated and improved upon. It also has an extremely large, passionate, and active user base.

Material / Shader support
  • Powerful material declaration language allows you to maintain material assets outside of your code
  • Supports vertex and fragment programs (shaders), both low-level programs written in assembler, and high-level programs written in Cg
  • Supports the complete range of fixed function operations such as multitexture and multipass blending, texture coordinate generation and modification, independent colour and alpha operations for non-programmable hardware or for lower cost materials
  • Multiple pass effects, with pass iteration if required for the closest ‘n’ lights
  • Support for multiple material techniques means you can design in alternative effects for a wide range of cards and GMOgre3D automatically uses the best one supported
  • Material LOD support; your materials can reduce in cost as the objects using them get further away
  • Load textures from PNG, JPEG, TGA, BMP or DDS files, including unusual formats like 1D textures, volumetric textures, cubemaps and compressed textures (DXT/S3TC)
  • Flexible mesh data formats accepted, separation of the concepts of vertex buffers, index buffers, vertex declarations and buffer mappings
  • Progressive meshes (LOD), manual or automatically generated
  • Static geometry batcher
  • Sophisticated skeletal animation support
  • Flexible shape animation support
  • Animation of SceneNodes for camera paths and similar techniques, using spline interpolation where needed
  • Generic animation tracks can accept pluggable object adaptors to enable you to animate any parameter of any object over time
Scene Features
  • Highly customizable, flexible scene management, not tied to any single scene type. Use predefined classes for scene organization if they suit or plug in your own subclass to gain full control over the scene organization
  • Hierarchical scene graph; nodes allow objects to be attached to each other and follow each others movements, articulated structures etc
  • Multiple shadow rendering techniques, both modulative and additive techniques, stencil and texture based, each highly configurable and taking full advantage of any hardware acceleration available.
  • Scene querying features
Newton Physics
  • Integration of Newton Physics and collisions
  • Ball and Socket, Hinge, and Slider Joints
  • Integration of a full GUI system
  • Windows, Buttons, RadioButton, CheckBoxes, ListBoxes, ComboBoxes, EditBoxes, Spinners, Sliders, Menus, ProgressBars, TabControl, Multiline EditBoxes, MultiColumn Listboxes, and more!
  • Fully skinnable
  • GUI layout editor
Special Effects
  • Compositor system, allowing for full-screen postprocessing effects to be defined easily, via scripts if desired
  • Particle Systems, including easily extensible emitters, affectors and renderers (customisable through plugins). Systems can be defined in text scripts for easy tweaking. Automatic use of particle pooling for maximum performance
  • Support for skyboxes, skyplanes and skydomes, very easy to use
  • Billboarding for sprite graphics
  • Transparent objects automatically managed (rendering order & depth buffer settings all set up for you)
Paged Geometry
  • Dynamic geometry paging system, which enables infinite worlds
  • Batched rendering LOD for optimized rendering of near-by trees
  • Impostor rendering LOD for extremely fast rendering of distant trees
  • Flexible LOD display system, which can be expanded to display geometry with any technique you can implement
  • Flexible LOD configuration system, which allows you to configure any combination of supported LODs in any way you want
  • Optional cross-LOD fade transitions, and far LOD fade-out, fully configurable
  • Flexible PageLoader system, allowing you to dynamically load geometry from any source you can imagine
  • Easy addition / removal of trees with bit packing, allowing millions of trees to be stored in RAM using only a few MBs
  • Color-map support for trees, which enables you to apply terrain lightmaps to your trees with one simple function call
  • Animated, optimized grass rendering system. Supports density maps, color maps, wind animations, height range restriction, and much more.


Posted Image

Posted Image


GMOgre3D uses the LGPL license, which means it's completely free to use for personal and commercial use. It also includes full source code, but if you modify the source you must make those changes available to the general public.

All 1200+ functions for GMOgre3D are fully documented, and more tutorials are steadily being added. You can view the current documentation at the GMOgre Wiki. You can also look at the OGRE documentationand wiki, which is extremely helpful in learning how OGRE works.

Community Forums
Visit the GMOgre3D forums for questions, tips, and more right here.

You can download the binary release with sample GMK projects here.

Source Code
You can download the full source code, including Visual Studio 8 project files here.

The DirectX renderer requires a version of DirectX 9 dated Nov 2008 or higher. If you get an error about a missing d3dx9_41.dll then you have an older version and need to update from:

GMOgre logo by mauge
GMOgre font by "Baby Kruffy" @ www.dafont.com
Ogre head by wumpus@ogre3d.org

- Houdini
  • 46

#3774435 Do's and Dont's in gamemaker

Posted by paul23 on 22 June 2011 - 05:53 PM


Dos and Don’ts in gamemaker

This “tutorial” will describe many guidelines on how to write clearer, “more elegant” code. More experienced programmers will find this tutorial to be “stating the obvious”. That’s exactly correct: this tutorial IS stating the obvious. However too many times I’ve seen people not knowing this, or at least not following the obvious better code. With this tutorial I hope people realize what a mess they make and how to improve it. I'll often talk about "functions", while -apart from build in- functions don't strictly exist in gamemaker, for all purposes scripts are functions, and should be handled as such
During this tutorial several patterns and anti patterns will be listed. They’ll be described why they should (not) be made and what better alternatives there are.

First you have to realize that good code matters (heck there’s a book even named after this). On these forums coding often gets thrown to the background, with the argument “designing is most important once you design the code is simply a piece of cake”.
Programming is not a piece of cake, it requires experience, careful planning and good designing. There are people who advocate that tools such as gamemaker make the need for programming (skills) obsolete. This is wrong, there will always be a step between your design, and a formal language a computer understands. And as long as such a translation is being made, it is important to write clean code. A good programmer is not somebody who knows all commands and how to apply them, that is what reference material is for (and as we see through this tutorial it is often not necessary). A good programmer is someone who writes elegant code and know how to design code.
To start off let’s look at an example of how we shouldn’t write code:
This entry for the iocc.. Found at the IOCCC (international obfuscated c code challenge). Now if you desire to create such code I suggest you stop reading. Those who like to write "slightly" more readable code should read on.

What is clean code

To understand what clean code means, we have to notice the audience of your code. Let us look at the standard life-cycle of a program (and hence code): First you design your code, you work out algorithms, proof that those are working, than you write your code, after which maintenance starts. Maintenance takes generally more than 80%[1] of the project time. So if you manage to cut down on maintenance time it will pay off greatly. For this reason we want to write clean code.
So we write code for future maintenance programmers.
This is important to realize and you should never forget this, you don’t write code for yourself. It’s written for someone who has not the experience you had during writing. And he or she shouldn’t spent more time than necessary. Even if you’re completely staying “indie”, a term popular around this community, you should still plan to write code for someone else. By the time you’ll review your old code you will have forgotten what you were thinking and you’re a “newcomer” to your code.
The main problem with maintenance of bad code is, is that it always lead to “code rot”. Code rot means that code becomes harder and harder to understand. Trying to “fix” code leads to more bugs elsewhere. Ugly code hence leads to maintenance programmers fearing changes and instead of fixing, the problem is patched – Which leads to even worse code. Eventually code is so ugly that no one understands it anymore and the only sensible thing to do is a complete rewrite. I’ve experienced this myself, “gpathfinding” is currently in a state where I can only rewrite the code from base.
The alternative, writing clean code from scratch, means that maintenance can operate without patching, instead maintenance programmers can fix the code. And by fixing instead of patching code rot is prevented and no rewrite is needed.

But but…

There are lots of counter arguments people bring up here to not write clean code. Some even more absurd than others.
The weirdest thing I’ve encountered was the argument “but I want people to not understand my code, so they can’t steal it”. This is a complete anti-argument, and it shows you have a complete misunderstanding of for whom code is meant – code is meant to be read. If you must hide your source for certain people use a tool as the final step to obfuscinate/compile your code. But that is not the code-base you store or share.
Another reason I’ve seen popping up often is “but it’s faster”. This argument shows some kind of ignorance. It shows that you are busy micro-optimizing during the programming phase. Not only do you not know the bottle necks, but you might actually prevent future optimizations on certain more important parts. On top of that you have to realize what tool you are using: game maker. Game maker itself isn’t the fastest tool, and if your aim is writing fast good in spite of readability I suggest not starting with game maker.
Now of course there are exceptions, I’m well aware of this. Gamemaker itself leads to quite a few ugly forms of code. (Not being able to pass arrays around, not having member function, terribly long arguments lists on functions, no scope definitions etc etc). You’ll often have to choose between two evils, but that doesn’t make it good. Always try to aim for clean code, look if you can’t redesign the code in a better manner, and keep the ugly parts to a minimum.

Clean code tips and tricks

As I started with programming is all about writing clean code. Programming can’t be learned in 1 day, and it requires experience. Clean code isn’t a “fail/pass” thing, it’s very subjective, difficult to define. During this part I’ll try to name some hang up points which you can use as guidelines to write clean code. Following these should make the code at least “readable”. Rmember these are guidelines, and not hard rules, always choose what works best in your specific case. I ordered the guidelines by their importance and easy-to-implement. The top are very important, yet are straight forward to implement in your program (and hence should always be applied).

Now before we go into detail first discus a few generic things. As we know by now, code is written for maintenance programmers. Your goal is to make it these people as easy as possible. Just like writing an article this means that everything is expected, follow the rule of the least surprise[2]. People shouldn’t have to look into the implementation details when only working on the interface. And when looking at the implementation everything should be at the location where it is expected.

  • DO indent your code.
    The very first and most important rule. Many articles never state this. Simply because it’s so obvious. Indent your code in a concise matter. The actual way isn’t too important, as long as it’s generally accept to be good. I myself use the K&R style as it reduces vertical scrolling.
  • DO use whitespace well
    Whitespace is the most powerful tool you as programmer have to create readable code. Whitespace allows you to let your users focus, it draws attention to things. Just like in an article adding paragraphs make code readable so does whitespace in programming. However too much and too little whitespace is bad. Too much whitespace leads to incoherent code, you don’t know what belongs to what. Too little whitespace lead to an overwhelming feel a “TL;DR” moment. Both are terrible.
    Now what is good whitespace? Well there are a few simple guidelines one can follow
    • always use whitespace around assignment/comparison/mathematical punctuation.
    • use a whitespace symbol before an opening (left) parenthesis, and after a closing parenthesis
    • exception to above is when the opening parenthesis is the start of an argument list of a function. As the argument list belongs to the function closely they should be tied together
    • after a comma/semicolon follows whitespace.
    These rules will give the basic white-spacing, though it requires a lot of experience and testing to see what is really “best”.
  • When in rome DO as the romans do.
    This saying counts for many things, and it goes hand in hand with the rule of least surprise. It means that whenever you use a certain engine or work with a team, you should adapt your style to what the engine/team have decided. Don’t mix & match styles.
  • DON’T use magic numbers in code.
    This is one of the most often violated anti pattern in gamemaker. And it’s also one of the oldest paradigms in programming. There is not a single reason to use a hard-coded magic number in code. An example is the “map_width”, ie let’s consider you make a chess game, now to see if a move would be legal we first check if it is “on the board”:
    If (x < 8 && y < 8)
    But what later, when you are maintaining your project, what did you mean by “8”, does it hold a special value? – Why “8”?. Much more readable would be:
    If (x < MAP_WIDTH && y < MAP_HEIGHT)
    It describes exactly what you mean, hence making code more readable. It also means maintaining the project (maybe you want a bigger map?) easier. As it prevents errors when forgetting to update.. This counts for any constant, way, way too often I see questions about blend modes, and then the user puts something like:
    draw_set_blend_mode(3, 4); What does that mean? Nothing, nobody can understand that code without reading the help file. (which increases maintenance time).
  • DON’T use "=" for comparison.
    This isn't quite as trivial as it looks though. But in gamemaker "=" can be used for comparison, yet at the same time it also can mean an assignment. Assigning & comparing are 2 very distinct operations, having nothing to do with each other. So they shouldn't share the same symbol. Consider the following piece:
    var a, b;
    a = 0;
    b = 0;
    a = b = 1;

    What will "a" hold afterwards? - Most people with other programming background, but also most without any knowledge of programming, will interpret the last line as “set b to 1, set a to b”. – thus both hold “1” afterwards. Gamemaker will not do this, gm’s engine will read this as:
    a = (b = 1) which equals a = (b == 1) thus a would be “0”. Using “==” for comparison would’ve immediately removed the problem, we see that it is a comparison followed by an assignment.
  • DO name your variables and functions well.
    Nomenclature is a matter of making decisions as a team. Here the saying “do as the romans do” counts doubly hard. A good name should always describe what a function does. And as gamemaker lacks scope/namespaces the name should also implement the scope of the function/variable. A person who is adding code to your engine should never have to think about the name of a variable/function when adding/using it. The naming should immediately follow from the purpose. Of course names shouldn’t be bigger than necessary, using “i” as counter in loops is well understood by everybody and should be used as such.
    Doing this prevents naming collision. But much more importantly: it makes code that is self-commenting and hence makes reading code a lot faster. An example nomenclature I use I’ll quickly describe:
    • Any script/resource/constant I use for an engine starts with a 2 or 3 sign for the engine, followed by an underscore: ie “MLP_” for my mathematical/logical parser
    • all resources except scripts are then followed by an undercase abbreviation for the type of resource
    • Then the resource is named with separate words separated by capitals (not underscores). So a typical object would be: MLP_objUnaryOperator. A script would be: MLP_ParseFunction())
    • constants are typed in all capitals, words separated by underscores.
    • global variables start with 2 underscores followd by the engine ID: __MLPParserNumber
    • Local variables don’t have any prefix, but each word is separated by a capital.
    • script variables never use capitals, and use underscores to separate words.
    These are just 1 way of describing a nomenclature, but you can see that whenever I add something I immediately know how the thing should be named. Rests only what they are named. And that I know from the description of the function.
  • DO comment, DON’T overcomment
    Anyone who followed education in a computer science related field, and got programming courses will immediately remember how the tutor would hammer on commenting more and more. However this isn’t useful to production level code, the tutor wants comments as he can grade you on that, he has to know if you understood what you wrote.
    Clean code is self-commenting. The variable names, function names etc should explain the flow, not the comments. Commenting has always many, many drawbacks, and should be used sparingly.
    Comments lead to distraction of the actual code when used too often. They will require extra time spent on maintaining/updating the comments when fixing parts of your code. Always with the problem that a comment might not get updated due to time constaints or simply missing one. And then comments not only become a distraction, they are wrong and describe things that aren’t there. Also be very careful that you keep the text in arguments minimal. You are not writing a book and shouldn’t write your thoughts down. (Keep a separate document for this).
    Remember for who you are writing code: for maintenance programmers, programmers indeed. You can take it for granted that they know the language (GML) just as good/better than you know it.
    Take the following abysmal use of commenting, it looks up the phone number of a student (id) (if the student id is value) and returns that number:
    var student_id, student_phone_num, student_map;
    student_id = argument0; //initialize student id
    //if student exist
    if (student_id < NUMBER_STUDENTS) {
        student_instance = students[student_id]; 
    //this is done after the checking for the correct number of instances
    //to prevent out-of index errors on the arrays. 
    //The student_instance can be accessed for all the other data, like phone numbers, courses etc.
    //Remember you need to check if the instance is still active before accessing this data.
        if (instance_exists(student_instance)) {
            //student exists
            phone_number = student_instance.phone_number;
            return phone_number; //return
    return 0; //returns 0 when non existing user number
    //initialize student id – No really? We can read too yes, we SEE you are assigning argument0 to student_id variable, don’t state the obvious
    //if student exist We see you’re doing an if-statement here, and with a little rewriting the code would be self commenting.
    //set the student_instance to the student used
    //this is done after the checking for the correct number of instances
    //to prevent out-of index errors on the arrays.
    //The student_instance can be accessed for all the other data, like phone numbers, courses etc.
    //Remember you need to check if the instance is still active before accessing this data.

    You like writing books? This just distacts
    //student exists Yup, we’re inside the if-statement, indentation told us that already.
    //return Orly? What else would you expect from a line starting with “return”
    //returns 0 when non existing user number a little rephrasing (maybe a constant) would mean the code is self commenting. Consider the following:
    var student_id, student_phone_num, student_instance;
    student_id = argument0;
    if (student_exists(student_id)) {
        student_instance = student_get_instance(student_id);
        phone_number = student_instance.phone_number;
        return phone_number;
    var student_id, student_instance;
    student_id = argument0;
    if (student_id < NUMBER_STUDENTS) {
        student_instance = student_get_instance(student_id);
        if (instance_exists(student_instance)) {
            return true;
    return false;
    var student_id;
    student_id = argument0;
    return students[student_id];
    Notice how 0 comments are necessary, everything explains itself, the function names help you following the execution path and there is nothing to withdraw attention of what is important – the code.

    Now what are good comments? Comments should speed up reading through functions, so the first commenting should always be a description of how a function is used, and what the arguments are. It should also describe the returned value. Make sure the header stands out clear from the rest of code, and follows an easy to read format. (For bigger engines I tend to use gmlscripts system of headers example).
    Apart from that “header” argument you might wish to add “TODO” type comments, to notify the user that a certain feature is yet to be created. Other comments inside code are generally bad and you ought to rephrase/refactor your code.
  • DO one thing in a function. Do one thing only.
    This another of those programming paradigms that has been with programming forever. It means that a function should do 1 thing, and only act on 1 level of abstraction. This is a bit more difficult to implement, it requires the programmer to carefully think about his functions. What is 1 thing, what do I want my function to do.
    Take for example our original student-phone number code, that script did 3 things in 1 function. Instead of splitting it up into 3 parts (which was done later). Our main goal is to get the phone number of a student (1). To do this we have to check whether a student exists (2), and also get the student_instance from the id (3).
    Clean code[3] had a good method to describe what is “one thing”. They described the “TO”-method, where we describe the function starting with “TO <functionname>”
    TO get_student_phone_number, we check if student exists. Then we get the student_instance which we use TO get the phone number
    It should now be clear this function did 3 things.

    A particular offense I see popping up quite a bit are that people pass “behaviour” variables to a function. I’ve seen an extension once that had a Boolean as second argument of an initializing function. If the Boolean was “false” the function would free the memory instead of initialize.
    Initializing and freeing are 2 distinct things. And should never be in the same function.
  • DON’T repeat yourself,
    DRY, another of those base principles created at the very beginning of programming. And still valid today. If you have to do a certain action multiple times, do never ever copy-paste the code at two (or more locations). Put the code into a function such that you call this function.
    Failing to do so will lead to confusion & maintenance problems, if you wish to change a certain feature you fear the functions go “out of sync”, and you’ll have to be very careful of fixing bugs.
  • DO keep function bodies small.
    A function in itself should be understandable without reading it more than a few times. It should completely fit in the “human working memory”. And as such don’t write function that are pages long. A small function leads immediately to self-commenting code. And as explained, self-commenting code leads to clean code.
    The question is: what is “small”. There is no answer for this question, and it is completely personal preference. However when you reach the triple digits functions are getting long already and you should be on the lookout.

And a final, last but not least action everyone should undertake:
DO learn another langue.
Not because gamemaker is a bad language, but simply because it makes you a better, more complete programmer. By learning multiple languages you won’t stay around bad programming practices endorsed by a certain language. You will learn about other ideas and you will learn the morals of other programming languages. This means that when you look back to gamemaker you can make a well-funded reason why something should or should not be written in a certain way.

Following these rules will benefit you always in the long run. Some principles might require a bit of planning and careful design, all require discipline and efford. But if you follow above rules and write your code clean, programming won't ever be an annoyance that "must be done", it'll feel like a breeze when reading previous code!

How to write clean code

The remaining part is: how do you write such code as described above. It seems a terribly long list with lots of things you have to take notice from. This is indeed true, and being very chaotic myself I can fully see the problem. It is also never meant to say that you should write code "clean" from the go, first it is important that you get to fix the problem. As only after you fixed the problem you see what was necessary to fix it, and only then you can decide how the code would look best.
After that you should just "proof read" your code a few times. Be critical, maybe keep above list as a reminder next to you, and delete all those temporary comments. Refactor code so it is self describing. (Often this means splitting up functions into several parts). Rename variables so they're actually meaningfull. This requires indeed discipline and time, there's no direct gain from this. But I hope you understand by now the importance of clean code.


When writing code the first thing one should notice is that the audience are maintenance programmers, maintaining programmers typically takes about 80% of the programming time. For these programmers code should hence be clean and well written. Clean code will always share some traits, it means code is readable and self-commenting. It also means that code is "obvious", doesn't hold weird structures and where it must be done it is explained throughly. Finally clean code also means that code is formatted in a specific manner.

With this tutorial I hope you will now look into your code and start refactoring it, with each look over your code try to make it a little bit better. I especially hope that examples written are actually clean code. It's a mindset you should have. Programming is not something you should just as a quick obligatory thing to design a game. Instead it's a field which requires just as much designing, planning & experience as any other design.

[2]http://en.wikipedia.org/wiki/Principle_of_least_astonishment (june 2011)
[3]Clean code: a Handbook of Agile Sofware Craftship, Robert C. Martin et al, 2009
  • 45

#4518793 2D Artist (Hand-Painted Style) Game Assets And Ca

Posted by kabecao on 04 March 2014 - 05:54 PM

Hi, I'm focused on creating creative artwork from concept art to in-game animations.
With more than 10 years of game development projects I have a wide base and experience on good methods and practices for real-time techniques such multi-resolution optimization, segmented animation, tiles, multi-layer background and non-tile based assets to build organic levels.

I use GameMaker for over 10 years and can work taking into account special features and technical stuff in GMS.

Available for works at any scale from sketches to finished animations and backgrounds.

Email: contact@hammeronart.com
Site: http://hammeronart.com/

Game Assets



run.gif  jump_fall.gif
read.gif   run.gif
jump.gif   drown.gif
Background, Tiles and Props:
User Interface, Itens:

Concept Arts, Illustration and Mockups

  • 44

#3788318 Reputation

Posted by FB-Productions on 14 July 2011 - 01:06 PM

I was always wondering about the Reputation in people's profiles.
I know what it means (probably...), but how do you increase it?
Mine is 1... :(

  • 42

#4860417 Hello! I'm Shaun, Your new Community Manager!

Posted by ShaunS on 20 August 2015 - 03:04 PM

Hello everybody!

I'm Shaun Spalding and I'm super excited to officially announce my new position as Community Manager at YoYo Games! I'm just taking this opportunity to introduce myself and give anyone and everyone here the chance to ask me anything about anything. Some of you guys might already know me from my YouTube tutorials, live streams and other stuff but if not here’s a quick background on who I am:
I'm 26 years old and graduated from Teesside University in 2011, I then went to work for Ubisoft Reflections as a game designer which is a job I got thanks to a student project made using GameMaker 8.1. I worked there for two years before going indie and releasing Another Perspective on Steam, made with GameMaker: Studio. Over the years I've been releasing regular tutorial videos on YouTube for GameMaker: Studio and generally being a huge GameMaker fan boy and now I've joined YoYo Games as their official community representative.
Going forwards I’ll be your go to person for all things GameMaker and the guy behind all of our social media posts on Twitter, Facebook and so on. I'm really looking forwards to getting to know all of you and doing my best to support and grow the community! If any of you have any questions now would be a good time to ask, otherwise you can find me at @shaunspalding on twitter and you can email me at shaun.spalding@yoyogames.com.

  • 41

#4382817 Polish Shader Library

Posted by PsichiX on 11 September 2013 - 05:22 AM

Hi, it's great time to back, since GM supports shaders :) GMClan.org is proud to make awesome shaders library available for everyone with GM:S! Here is a list of created examples and i will sometimes post a new examples, so check it out:
  • 39

#1369 Game Annoyance List

Posted by J Dan on 06 October 2003 - 07:08 PM

I've assembled the items in this list from my own experiences, and other members posts. This is mainly meant for annoyances you've experienced from games made with Game Maker. This is not a topic meant to bash other's games, but to point out how our GM games can be made better. Changing one or two things in your game could make the difference as to wether or not yours is a "good" game or a "great" game; or even between "mediocre" and "good".

Game Design/Layout
  • Unnecessarily time-consuming tasks that should be simple (e.g. excessive distances between the bank and the shops).
  • Annoying health decreases.
  • Using different background music for everything (can make game slower or just be annoying).
  • Not enough background music variation (using the same song throughout the entire game can be annoying).
  • Weird glitches or bugs (Test, test, test, and then test your game some more).
  • First boss being harder than later or even the last boss.
  • Game rules that go against your intuition (random's example: "Cosgroves umbrella the jumping stones still kill you on the side").
  • Not being able to hide from or avoid boss attacks.
  • Impossible to beat bosses (Duh!).
  • High scores that only rely on getting a bonus and nothing else.
  • No title or menu screen, and starts right into the gameplay on startup.
  • Lack of an opening movie sequence.
  • Lack of an "attract mode". *
  • Multiple mini games that are poorly done, instead of one type of game that is done well.
  • Uses the default resources that come with Game Maker.
  • Not enough levels or is too short.
  • Ability to save the game too often (not annoying really but can take the challenge away from some games).
  • Inability to save the game at sensible check points (e.g. level completion, defeated boss etc.).
  • Lack of variable jumping in platformers (i.e. the longer you hold the jump button, the higher the player jumps).
  • Too much focus on graphics, and not enough on gameplay.
  • Lack of custom in-game dialog boxes (the show_message function can be annoying and unprofessional).
  • Inability to see what is ahead of you because of annoying HBor or VBor view settings (in platform games especially).
  • Lack of responce from user interaction (see Rithiur's postand J Dan's post).
User Friendliness (let users play your game the way they want to play it)
  • Not being able to toggle full-screen (if someone wants to run your game in full-screen give them the option; if they don't, let them turn it off).
  • Not being able to toggle background music and/or sound effects (can slow game down or just be annoying; and if the user turns it off, make sure it STAYS off throughout the WHOLE game).
  • Cinema/movie scenes that are too long and/or impossible to skip.
  • Almost anything that takes control away from the user for long amounts of time.
  • Lack of documentation (e.g. can't play a game if you don't know what the control's are).
  • Lack of a quick exit feature (let the user quit the game whenever they want to via one or two key combination exit).
  • One key exits (accidentally exiting a game without saving it is needless to say, very annoying).
  • No load/progress bar during the load screen (not as important if your game has a short load time).
  • No indication that a menu item is selectable when you hover over it with the mouse.
  • Game errors on you when running Game Maker in secure mode.
  • Unecessary installers or lack of appropriate installers.
  • Extra files, other than the one Game Maker compiled exe., that are needed to run the game.
  • Game text that scrolls too fast, or too slow, or is impossible to skip.
  • Lack of a Restart Level option.
  • Slow load times.
  • Slow run times (be careful about scaling).
  • Lock ups during game play.
  • Slow download caused by large file sizes.
  • Long download times; short gameplay times.
Game Controls
  • Controls that are spread out too far or are too cramped together. (CobraA1: "Try to use keys that require minimal hand movement, but the left hand and right hand should be a comfortable distance apart. ")
  • Using the Shift key (can open an unexpected Accessibility window on some computers).
  • Using the keypad (can cause problems for laptop users).
I hope this will really help upgrade the playability and quality of our games. Keep your annoyances coming. :)

* "The mode where you get demos of gameplay is called "attract mode", because arcade games use it to attract players during idle time." EricDB
  • 39

#4168705 Is Gamemaker "cheating"?

Posted by NakedPaulToast on 19 December 2012 - 02:41 PM

Is he cheating when he:
  • mows the lawn with an electric mower and not a push mower?
  • writes with a ball point pen and not a quill pen?
  • does math with a calculator and not a pencil?
  • writes a report on a computer and not paper?
  • uses a spellchecker and not a dictionary?
  • cooks with a microwave and not an open fire?

  • 37

#4054349 Calling all GM Studio professionals....

Posted by Nocturne on 11 August 2012 - 10:35 PM

Responded when don't have Studio.


Raised your warn for being an idiot.

  • 37

#2026794 Particle Designer 2.5.3! (application)

Posted by Alert Games on 13 April 2007 - 12:52 AM

No more using the effect_ functions!!!

By: Alert Games

->How do I use particles? And how can I design them? This program allows you to create a particle system with all of the functions available in GM6+, but it also allows you to create emitters, attractors, changers, deflectors, and destroyers. With its easy interface and random generating particles, you will be able to create particle effects and particle systems much much quicker than you can by reading the code! You can export the entire system to GML to use in your game, or take screenshots and animated GIFs. This program doesn't need to be used just for game maker, you can create nice looking effects for anything!

->Major features:
--All functions for a particle type for a single particle
--Great user interface
--All functions for the emitter, attractor, changer, deflector, and destroyer.
--Generate random particle settings
--Lock settings so they aren\'t affected by random option
--Very functional codebox for changing values while testing.
--Import a GML file
--Export the particles, a tab, or the particle system to GML
--Export the above to the clipboard
--Save and open PDSF files, which include codebox gml
--Full capability to use external sprites(not saved however)
--Take screenshots of the particle, and even save GIF animations
--Shortcut keys
--Preferences for testing and exporting particles
--Fullscreen capabilities(stretches window)
--Detailed help files to help with using the program, and putting particles into your game

Why should I download version 2.5?
O--Option to click the mouse to emit particles
O--Widened the viewing area a small bit
O--Added a Loading Sprite dialog with centering feature
O--New menu system to resolve errors
O--Added Background alpha feature as an effect
O--Added "Move all this Type" option
O--Added a comment to indicate where the particle code starts
-->Fixed emitter particle numbers in the tab
-->Fixed filename problem when using sprites
-->Fixed an error when exporting particle to clipboard
-->Now exports commented background color and alpha to load in the program
-->Changed the crash prevention to allow lower room speed than it
-->Attractor force values in multiple tabs bug fixed
-->Fixed incorrect Xmax and Ymax for the destroyer
-->Fixed bug when copying a destroyer
-->Fixed the Lock/Unlock all button
-->Fixed some dialog messages and added more help tips
-->Fixed emitter still streaming a particle if emitter is deleted
O--Added a semicolon after each function in the export
O--Help files improved
O--Added langauge support
X--Removed color code tabs option
O--Added a "Destroy Off-Screen Particles" option
-->Fixed a display glitch switching to tabs in advanced mode.
-->Fixed characters not being displayed for some different languages.
-->Fixed sprite loading issue.
-->Fixed other menu and loading bugs.

See all screenshots here

->For more information, screenshots, etc. visit these links
*OFFICIAL PD2 PAGE* - INCLUDES: updates list, FAQ, extra particles, etc.




->DOWNLOADS (2.5.2):
(~3 MB) Windows 7 Compatible!
>Please extract the files before using to avoid any errors or saving issues<
(Downloads include some particle examples that you can load.)

>> Host-a.net

>> Box.net

DOWNLOAD THE LANGUAGE FILE(place the lang.txt file in the program's directory):
Download English (or here)

If you translate the file, and would like me to host that language and feature it here, please send me a PM (Personal Message).
Download Dutch
Download Swedish (Courtesy of Alfred0110)
Download Czech (Courtesy of D4rkS7der)
Download Polish (Courtesy of damian440)

Instant Play(V2.3)
download the chm file (compiled help. outdated)

If you would like to DONATE to the project, please click here!

Credit: Credit is not required for anything generated, but you may put credit as "Alert Games" if you want to.
__________________________________________________ ______________________________________________

->Known Issues/Suggestions:
-Improve import function to avoid issues with variables and not throw errors
-Improve codebox with clickable, easier functions/variables to add
-Change the PSDF file format for extended compatability, security, and reliability
-Leftover tabs when loading a new file
-Values to the third place value are not exported properly
-Buttons to easily set direction and speed with the mouse, and set others with a slider
-Allow the dimensions on the screen to be changed for Screenshots (including GIF, and maybe add AVI)
-Hotkey for show/hide the crosshair
-A less restricted number of emitters, particles and other particle system types
-Fullscreen does not keep some settings, including room speed
-Not able to have FPS over 60?
-Direction of particles can screw up with multiple particles
-Lock checkboxes don't reset for new particles
-Buttons for shifting color of the particle, proportional scale and size, etc.

->Having Trouble?
Before posting it here please check the included help files first. There is also an online FAQ, which is found HERE

->Common problems:

When I export the particle and put it in my game, it gives me an error!


Be sure that you have everything necessary for the particle to work. The particle system creation code is not exported on default. You can change this in the preferences, or just add "Sname = part_system_create();" before the particle is made. The reason for this is so unnecessary extra particle systems are created. Be sure to remove the system when you need to.

My particles lag a lot when i put it into a new game


be sure to check that the particles and particle system is only created once. They only need to be called in the create event, and they can be used with multiple objects. Once you are done with the particle, you can delete the system if you need to. To stream the particles with an emitter, it only needs to be called once. But you can change the region in other events.

If there are any bugs, suggestions, comments, post them here!

  • 37

#4232228 Parakeet 2 OUT NOW - http://parakeet-ide.org/

Posted by Jobo on 07 March 2013 - 06:50 PM

What Parakeet does is allow you to create and edit GameMaker projects in a more streamlined environment with more focus on programmingless focus on learning and the world of focus on ease-of-use.

Of course, GameMaker will still be required and necessary for certain tasks - including compiling. This is only a choice for an alternative development environment.
When downloading Parakeet you agree that the creator of this software is not responsible for any damage that may occur to your device while the software is installed and any use is at your own risk.
Parakeet 2 has been RELEASED: http://parakeet-ide.org


Check out Parakeet 2 here: http://parakeet-ide.org

  • 36

#4177851 Working With Multiple Resolutions (1.3.X)

Posted by Manuel777 on 31 December 2012 - 07:45 PM

Setting up your views for multiple resolutions can be a tricky part of developement with GameMaker Studio, and I see just too many people asking for solutions everywhere, so here is my guide on how to do it;

First beware that this guide is based on the methods and experiences I had, there may be mistakes, if you found one, please point it out so I can fix it!


Also: This guide was initially written for older versions of GMS (pre-v1.3) especifically for Android. I have now updated it to the new way GMS uses in 1.3, and it is now compatible with all exports :D

Post-v1.3 guide (Scale to fit)

GMS 1.3 has changed significantly how we were used to deal with multiple resolution changes, if you are used to change the views size using the old method (wich is still available at the end of the post) you may have to erase all of your previous view scaling code and start from scratch. Most of times, if you were doing it right, you will only have to replace one object's event or two at most.

How does GMS behave now?

I have put up this nice little graphic to show you how the propierties of the view behave now, in either desktop o mobile they behave the same way, except that in moile we dont have a window, so we replace that with the display size; (click to see full size)


Testing view changes on desktop

Testing for mobile devices now is pretty much the same thing as it was before, if you want to test a given reoslution on desktop, set the window size to those values, say I want to test a 1080p screen on my PC and I dont have access to a 1080p device:

window_set_size(1920, 1080);

Also, a very important note here, when I speak about mobile and desktop I refer to every single mobile device and every single desktop platform. Since 1.3 everything is unified, that means that if your code works for Android it will work for all the other mobile devices, including iOS and Windows Phone with no differences! the only difference between mobile and desktop as of now is the "Window", that is, where the entire display is contained. In desktop it is contained in the window, and in mobile it is contained in the entire display. So if you use window_get_width() on desktop, on mobile its direct equivallent will be display_get_width()

What is application_surface?

application_surface has been referred many times in a whole load of topics regarding 1.3 new ways. It is basically the surface that draws everything. It was always there, but hidden, so this 'new' feature will not slow down your games.
It usually has very little impact on how we work with views, except for one important fact; we will have to resize it every time we resize our views! else everything will look awfully bad, because the surface will remain on a different size than the size we are actually using for the screen.
Why is it all so damn buggy now??

IT IS NOT! we just have to learn how it works, please be patient. please!

Since we have to scale application_surface everytime we make a change, we now need to use this line of code after every change we make to the screen:

surface_resize(application_surface, width, height);

Now, here I must stop and add a few notes; width and height should match your view sizes, as that is usually what you want, not the port nor your screen size, your view_wview or view_hview sizes are what you want it to be.
And secondly, if you are changing these values you will probably get a crash, this is probably a bug in GMS, you just have to round the values you just changed:

width = round(width);
height = round(height);
surface_resize(application_surface, width, height);

To manually draw the surface or to not?

Right now it may be unnessesary, but for the sake of it, if you MUST for some post-process you can now draw it as usual, in any event (preferably some Draw GUI event as they have top-most depth), just notice you have to disable automatic drawing for it to work properly, else the surface will be drawn twice to the screen and that may slow down your game, especially on mobile:


Adjusting the screen size

Usually using scale to fit you do not need to adjust the screen size. This is very important, because the GUI and ports will stretch to fit perfectly inside the screen and leave some black borders around the edges. You can still stretch the views size to elliminate the black borders trough.

As usualy here we have two methods, first I will describe the most common one, 1:1 scaling wich will resize the surface to fit you whole screen, like we did before, adn a second method wich will just work to elliminate the black edges. You should be easily capable of changing the algorithm later on if you need to make some extra chages to these, but you first have to understand how this works of course.

1:1 scaling

This is super simple, please note all of the notes I mentioned above!

view_wview[0] = round(display_get_width());
view_hview[0] = round(display_get_height());
view_wport[0] = view_wview[0];
view_hport[0] = view_hview[0];
surface_resize(application_surface, view_wview[0], view_hview[0]);

Also note that I changed the view port size here. This is only required when changing the size of the rectangle where the view will fit, in other words, only when we want to change the size of the space that is taken inside the screen (everything else will be empty / black)

In case you want to make the screen adjust when rotating the device it is a little different. Using surface_resize() continuously takes a whole lot of memory. We need to check for view changes before we resize anything:

var w, h;
w = round(display_get_width());
h = round(display_get_height());
if view_wview[0] != w || view_hview[0] != h {
    view_wview[0] = w;
    view_hview[0] = h;
    view_wport[0] = w;
    view_hport[0] = h;
    if surface_get_width(application_surface) != w || surface_get_height(application_surface) != h {
        surface_resize(application_surface, w, h);

Note the round() in the first lines and how I check for the view size changes afterwards. That will execute surface_resize only when needed.

Removing the black bars

I kind of like the black bars as they provide us with a perfect scaling no matter what we put in the views size or what device size we use. but on mobile devices this may look odd or unprofessional sometimes.

To remove the bars we have to do pretty much what we were doing before when we were calculating the aspect ratio of the screen. It is basically the same thing, but applied to the new application_surface as well, beware that to do this we have to change everything and then resize the surface size, never resize the surface unless you are done with the calculations to get the view size!

Now first things first of course. When GMS resizes your display to keep the aspect ratio the only thing it does is to stretch the view ports to fit inside the screen (or window as in desktop), but when it does this it doesnt change your current aspect ratio (the one you have on you views) so you end up having two different aspect ratios, one for the views and another one for the display. The difference you see is shown as black bars around the edges.

views_aspect_ratio = view_wview[0] / view_hview[0];
display_aspect_ratio = display_get_width() / display_get_height;

To fix that we have to match the aspect ratios of both, what we want to do now is to figure out what is better, to either enlarge the view horizontally or vertically, and that is exactly what this piece of code does:

// Remember to round theese
display_w = round(display_get_width());
display_h = round(display_get_height());
views_aspect_ratio = view_wview[0] / view_hview[0];
display_aspect_ratio = display_w / display_h;
// If we have to enlarge vertically
if views_aspect_ratio > display_aspect_ratio {
    view_hview[0] = view_wview[0] / display_aspect_ratio;
    view_hport[0] = view_wview[0] / display_aspect_ratio;
    surface_resize(application_surface, view_wview[0], view_hview[0]);
// Else we have to enlarge horizontally
else {
    view_wview[0] = view_hview[0] / display_aspect_ratio;
    view_wport[0] = view_hview[0] / display_aspect_ratio;
    surface_resize(application_surface, view_wview[0], view_hview[0]);
// Else they already match! we dont have to do anything

You can put this in a create event, an alrm being executed at one step, or even a step event that checks when we have to resize the views. At any case, do not resize application_surface constantly! as that will create lots of lag.


What's up with the GUI now?

Now the GUI behaves pretty much the same (as far as I noticed), keep in mind that the black bars you see will still be a part of the GUI, so if you draw anything in the GUI at 0,0 it will be on the left topmost corner, even if you have black bars.


To overcome this you just have to get the position of the view in the GUI, for that we use application_get_position(), it will return an aray and we just have to use the first two values (the x and y from the left-top coner of the application surface)


Also beware that whatever size your views or window is, the GUI will always have the same size and will scale to fit your window! if you change your window size in desktop you may want to use display_set_gui_size() and make it 1:1 with the window so it does not look bad or stretched:

display_set_gui_size(window_get_width(), window_get_height());
In mobile this should not be needed as the display size will always remain the same, but sometimes you may want the GUI to remain the same size across all devices and put a static value in it, or even do some aspect ratio fix for it to maintain the device aspect.

Pre-v1.3 (mostly obsolete) (almost like 1.3's full scale option)

Important note about the room size: In order for the views to change troughout the many different screen sizes, it is better to feave your rooms at something large like 2048x2048, the reason is simple; if the view width or height ever go larger than the room, it will probably create black bars or some other non-desired effects on your game.
Another way to avoid this is to set your room size to the max size the view will reach, say your static height is set on 768, then you can set the room height to 768 and leave the width on something like ~1600, because your view height wont change (do notice im speaking of view size, aka width/height, not ports size!)

Why dont I use room_set_view(): This is a common question, and I honestly dont know who proposed this method on the first place, but it is a horrible way of handling theese situations. I dont use it for several reasons, one is variable handling; Sometimes you need to modify the attributes of the views on a constant flow, that is, ports before sizes and stuff like that, that is not possible if your work with this function, and you end up crating lots of useless variables wich may get a confusing code.
Secondly and most importantly, room_set_view() doesnt work when you are triying to change the current room propierties! this sucks, because you have to create a whole new room just to change the view sizes, and if you need to do it at runtime.. well, you are screwed. So I trust you understand this and stop using it as well smile.gif

Why does everything still looks bad/skewed on my game??: This is a common issue when you change your views at startup and nowhere else, when setting either portrait or landscape mode. GameMaker takes a few steps (usually just one, maybe two) to get the screen size and mode from the device updated, if this is your case you can just add an alarm and set your view updating codes there, do notice that, on my examples I set everything right after an "alarm[0] = 2", to avoid just that.
If you are working with automatic rotation you can dump the view-adjusting code on a step event, and it will adjust your views every time you rotate the device, I recommend to test this by yourselves, it is pretty handy to know you can do all of this every step with no further issues for the game!

  • 37