GameMaker Question About Establishing Enums in GML Object Create Event Vs. First-room Creation Code

[Game_Re_creation_Project]

[Sorry if this question has already been asked and answered. I searched and couldn't find what I was looking for.]

Is it better to establish an enum in something like a rm_init (first room creation code) or is it safe to establish an enum in the create event of an object which is going to be used multiple times in the game? Would creating an enum over and over again in the create event of an object cause a memory leak because the enum is getting generated over and over?

In the latter case, would a best-practice be to just establish temp vars?

Create:

var _auto = -1;
var _vert = 0;
var _horz = 1;

Rather than:

enum OrientationEnum
{
    auto = -1,
    vert = 0,
    horz = 1
}

 

[TheouAegis]

Enums are better. They take up no memory. Enums are for the compiler. It makes no difference where you declare them. Declare them where you will use them if you want, or all in one place.

 

[Yal]

It's also worth pointing out that both enums and macros get defined before the first room starts, no matter in which event they're placed.

I personally prefer using constant macros #macro NUMBER_OF_PLAYERS 4 over enums, since macros can have float / string values while enums can only be positive integers - macros has more versatility and better syntax highlighting / autocomplete so they just seem objectively better.

 

[rytan451]

For some enums, I actually create a script __ENUMS and define the enums there. It doesn't matter that I'm never calling the script anyways .

 

[Bart]

Another thing that may be relevant is debugging.
Enums and macros are replaced by their value before the game runs. They're actually little more than a simple text replace before the executable is created and they're not really part of a game's code.
You could say they're baked into the executable.
An enum doesn't exist as a variable so from that perspective it doesn't matter at all where you define them in code.

Because of all this, there's no way to access an enum's value through the debugger.
Suppose you have an array that you index using an enum:

enum Vec {
    x = 0,
    y = 1,
    z = 2
}

vector = [2.4, 5.6, 4.6];

var _x = vector[Vec.x];    // This won't work as a watch in the debugger since it doesn't know "Vec.x"
// var _x = vector[0];     // What's actually there behind the scenes

 

[TheouAegis]

I've been adverse to macros simply because they were so similar to constants in GM8, which themselves were retained by the program and so were nothing more than globalvar taht could not be modified at runtime. I'm sure they're vastly different from constants, but... That fateful day opening the command line debugger on a GM8.1 program when I didn't even own GM8.1 scarred me, I guess.

while enums can only be positive integers

ANY integers. Enums can be negative. Fractions will be rounded toward 0 (well, probably just dropped).

 

[samspade]

The primary difference, for me, between macros and enums are that macros are purely text replacement and enums are constants. Macros can be used in every place that enums are, but enums cannot be used in every place that a macro is. However, the automatic numbering of enums can be incredible helpful when using them as indexes as it allows you to add and remove without having to update anything. To get the same results with a macro, you have to actually go edit the macro.

 

[Game_Re_creation_Project]

Wow! Thank you for the many responses! I will go the enum route.

I am generating a list of hwnd-like user controls. Right now I am fleshing out the scrollbar control which will actually be made of vertices rather than sprites. I just needed to know if it was safe to generate an enum in a create event rather than a script or an rm_init because I want these controls to more or less stand on their own.

If I manage to get something working, I will post the source code for review and suggestions. The ultimate goal is Scrollbar, Spinbutton, Command Button, Radio Button (this will have a "group" assignment), and Toggle Buttons. I may also include Combo Boxes but I don't think I'll take the deep plunge into Textboxes.

I will include flat design and the more embossed look as options for appearance.