[SOLVED]Converting a project from GMS 2 to GMS 1

I am not trying to convert specific GMS 2 code, or features, but am working to get the code formatted in a way that GMS 1 can assemble the project. By now it is hopefully at the stage where I have addressed most of the differences, though there is one element I'm unsure of.

Below is part of a GMS 2 yyp file (2.3, I think) and it seems to have no corresponding part in the gmx file of a GMS 1 project.

"Options": [
{"name":"Linux","path":"options/linux/options_linux.yy",},
{"name":"Windows","path":"options/windows/options_windows.yy",},
{"name":"macOS","path":"options/mac/options_mac.yy",},
{"name":"Main","path":"options/main/options_main.yy",},
],

Looking at it: it seems to have something to do with either the version you are running it on (windows or linux etc) or maybe the version you are exporting to? I'd guess the former, but am unaware of how to make these changes in GMS 1 (and besides which, can only run it on pc / windows. so can't test it)

So I don't have the full template to compare the differences between versions, or know if this information from the later version is even used.

Can anyone tell me if this irrelevant to GMS 1?
 

Heathenlamb

Member
Haha ... every game I made in GMS 1 that I tried to import into GMS 2 just flat out didn't work. I gave up on doing that.
 
  • Sad
Reactions: Mut
Haha ... every game I made in GMS 1 that I tried to import into GMS 2 just flat out didn't work. I gave up on doing that.
Once you know the quirks (e.g. compatibility backgrounds, cameras and layers) it's pretty easy to get a game converted and working depending on the project size
 

Heathenlamb

Member
Once you know the quirks (e.g. compatibility backgrounds, cameras and layers) it's pretty easy to get a game converted and working depending on the project size
Yeah nah .... after many attempts to get them working it was just taking up too much time. So I gave up.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
In GMS1, the equivalent of "options" resources is the Configs\<name>.config.gmx and the corresponding directory with images/metadata. Unless you are writing a tool to be used for a whole lot of projects, I wouldn't recommend going over all of this.
 
In GMS1, the equivalent of "options" resources is the Configs\<name>.config.gmx and the corresponding directory with images/metadata. Unless you are writing a tool to be used for a whole lot of projects, I wouldn't recommend going over all of this.
Yeah - I initially thought only the .project.gmx file handled things, and I am reasonably comfortable sorting that. But then I realised about macros, and other conditions a conversion may be reliant upon, so getting the project recreated exactly seems the way to go. I wouldn't want to miss something that I think is inconsequential, only to find it's not irrelevant.

Thanks for the info.
 
@YellowAfterlife
If you don't mind, could I pick your brain with a question :)

Regarding macros: I know where they are created in GMS 1, and that it is only in the config file (er....'all configurations' is .project.gmx, and the others go into their own .config.gmx file? that's slightly confusing)

I have a project for GMS 2 in yyp form, though am unsure now if it was converted from a GMS 1 project. It may contain things that are conversions of former practices.

There is a script called MACROS - I am assuming this is generated by GMS 2, as macros in GMS 1 are defined through the UI (what I would call "engine code"), and the results are done through the config (project?) file.

However: there is also a script dealing with enums, which to my knowledge are defined by the user through code (in a create event, or whatnot) and not through the UI. This script also has macros, so I'm a bit confused here. My assumption is that the script called MACROS is where I would want to be looking (treated as engine code...?), and yet here is a script that I would have thought deals with object / instance code, yet it has engine code.

I thought I could just rely on finding this MACROS script, but that now seems wrong, and I might have to parse every GMS 2 script for #macro?

Apologies that was a bit long-winded. I can just about grasp the GMS 1 side of things, but either the compatibility changes or GMS 2 structure is making this tricky.
 
Last edited:
It was really just interest (and the first thing that came to my mind why someone may legitimately want to convert in that direction and not the other ;) )
I haven't yet gotten used to GMS 1, and find it easier to understand than GMS 2.

A lot of useful examples are no longer in GMS 1 format, and I also think the UI of 2 for code windows is very irritating compared to the more flexible arrangement of 1.

Some performance tricks from 1 don't seem to have quite the same effect in GMS 2, and that's either me not understanding it (due to needing to learn it all again, and don't want to, or can't) or things under the hood have changed, seemingly not for the better.

Not very exciting reasons, but nonetheless - my reasons :)
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
I thought I could just rely on finding this MACROS script, but that now seems wrong, and I might have to parse every GMS 2 script for #macro?
Yes. You can peck at the GMS2.2➜GMS1.4 conversion tool that I made last year - most of the concepts still hold true for 2.3
GMVitalizer/VitGML.hx at 7196cbe149968b76be4af4b8be114a9874434a41 · YAL-GameMaker-Tools/GMVitalizer (github.com)
"macros" is the name of the script that would be automatically created for you when importing a 1.4 project, but macros can technically be scattered anywhere. Many people create a script called "macros" out of habit now. "enums" is not standard.
 
Yes. You can peck at the GMS2.2➜GMS1.4 conversion tool that I made last year - most of the concepts still hold true for 2.3
GMVitalizer/VitGML.hx at 7196cbe149968b76be4af4b8be114a9874434a41 · YAL-GameMaker-Tools/GMVitalizer (github.com)
"macros" is the name of the script that would be automatically created for you when importing a 1.4 project, but macros can technically be scattered anywhere. Many people create a script called "macros" out of habit now. "enums" is not standard.
I did find your conversion tool, but as you say it needed updating for 2.3 and that level of editing is a bit beyond my current know-how. Altering a HEX file, if I remember correctly? Probably something that I could get to grips with eventually, though for now I've managed doing it with just gml. It's working out what each version requires, and where, that I struggle with.

I see now that macros can be in object scripts too, so am realising I have to parse several more area's. With enums I am a bit unsure, as I haven't got around to using them. They are global in scope, so am I right in thinking that in GMS 1 they will only be in an objects create event, and presumably in a single controller object that is created first in the room instance order? So that you don't get instances trying to use enums that aren't initialised, and due to it being global you only need it defined once, so you have one control object to ensure how and when it's run.

Because a response regarding macros vs enums from yo-yo's mike (?) said both are compiled as constants at run-time, at least for GMS 2 (uh...in 2017 when the conversation took place, so that could have changed...), and as far as macros are concerned can be anywhere in the project. Which if I understand correctly is quite to different to GMS 1, where they are only in the project / config files. I don't want to assume with enums that they follow the same conventions as macros in GMS 2, and am not that sure of how they're applied in GMS 1. Can they be anywhere in 2's various scripts, or only a create event?
 

TheouAegis

Member
I don't get the hangup on enums. Are you saying GMS2 doesn't save enums inside the object files along with the rest of the object code? Other than any potential file storage issues, GMS1 and GMS2 use enums the same way from what I recall; it's just object code that the UI interprets. I could foresee the UI not recognizing an enum right away, but the compiler should recognize it regardless.
 
I don't get the hangup on enums. Are you saying GMS2 doesn't save enums inside the object files along with the rest of the object code? Other than any potential file storage issues, GMS1 and GMS2 use enums the same way from what I recall; it's just object code that the UI interprets. I could foresee the UI not recognizing an enum right away, but the compiler should recognize it regardless.
I would never make a definitive statement about what GMS 1 or 2 do, other than fairly basic functions, because I don't know. The convertor is just a glorified text editor, after all. Nothing particularly difficult to comprehend, even for me.

I know nothing about how the engine works under the hood, so haven't a clue how enums are handled, or any other process that it's doing. Consequently I have to ask questions that might seem quite basic, but such is the level of my programming knowledge.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
I did find your conversion tool, but as you say it needed updating for 2.3 and that level of editing is a bit beyond my current know-how. Altering a HEX file, if I remember correctly?
You'd need to edit the Haxe source code to account for 2.3-specific portions of YY files and project format.

I see now that macros can be in object scripts too, so am realising I have to parse several more area's. With enums I am a bit unsure, as I haven't got around to using them. They are global in scope, so am I right in thinking that in GMS 1 they will only be in an objects create event, and presumably in a single controller object that is created first in the room instance order? So that you don't get instances trying to use enums that aren't initialised, and due to it being global you only need it defined once, so you have one control object to ensure how and when it's run.
Enums can be anywhere both in GMS1 and GMS2, you don't need to do anything.
 
@YellowAfterlife
Thanks for the help. I always think of code being linear, so the notion that the engine strips certain things out over the entire project and compiles them first, is strange to me. But any confusion is inevitable, as I have no education in programming whatsoever. Typing "pod can run" or "pod can jump", and watching an animated tomato run or jump, on a computer powered by coal, is all that I ever had :)
 
Top