ENIGMA progress

[The 11th plague of Egypt]

Next for ENIGMA

the parser a lot simpler, like getting rid of the dynamically added variables. All variables local to an instance will have to be declared as "local". This is actually a small change that would break little, but could fix a lot of problems we have now with

I agree with that.  Like that idea.

I don't need - or even want - GML compatibility. Or GM compatibility in general. We don't need people porting stuff from GM to ENIGMA. We need people making stuff on ENIGMA.

Words of wisdom, and agree 100% !
Besides with big changes YYG is heading for, porting will be irrelevant and so outdated.  Time to actually shine and be better and faster. (in more ways )

Seeing as GM is slowly dying anyway, I don't think we need to follow them.

I agree, this whole acquisition is big sham in my opinion, and in the end people will find out why it was never a good idea for a gambling company to have put its nose in GM....I think it's obvious what interests they are after and where they are heading.

If we could at least keep GM compatibility up to GM 8.1/GMS 1.4, that would be great.
A lot of work has been done on studying and supporting the .gml file format, and it would be nice not to throw it all away.
The importer is still there, right?
Freeze the GM(S) support to a specific version and move on.
There are a lot of GML examples around, and remaking all those tutorials may not be as easy as it sounds

[onpon]

Considering a large portion of Game Maker files can't even be run by ENIGMA... yeah, I don't think worrying about compatibility is worth it. Keeping use of ENIGMA and LateralGM similar to use of Game Maker is probably worth it, on the other hand.

[The 11th plague of Egypt]

Considering a large portion of Game Maker files can't even be run by ENIGMA... yeah, I don't think worrying about compatibility is worth it. Keeping use of ENIGMA and LateralGM similar to use of Game Maker is probably worth it, on the other hand.

Of Game Maker files, or Game Maker Studio files?
Last time I checked, most GM files worked fine.

[onpon]

The binary ones. I don't remember what I've tried other than this and older versions of it, but none of what I've tried has worked. I think it's deleting stuff that confuses ENIGMA's compiler, isn't it? That must be a pretty common action.

[Josh @ Dreamland]

I'm impressed, Harri. I don't have much else to say.

[time-killer-games]

@onpon sorlok has gotten a lot of huge games built for gthe gm5/6/7/8 era working quite nicely on windows mac and linux, hes contributed a lot but got busy so its cool we have Harri to sub in the meantime, as enigma needs a lot of its own features too, i like the idea of port gm projects, but ppl who port their projecmts to enigma will want to make them better in enigma without re-writing much, so that were the enigma features harri is putting will also come to great use, bringing in ppl to make the full switch to enigma rather than just porting a game to enigma when bored saying, "hey, it actually works, cool beans" and moves on. I think its good we have a ballence. Enigma can be its own engine, but i find keeping support for at least up until 8.1 being the biggest thing as far as the basic functiobality, all the most important stuff, and when it comes to file format, 1.4 gmx is good enough. They "un-obsoleted" a lot of shit they got complaints for removing in gms, and yeah all my projects from gm81 ported over to studio just fine, as i dont really use any of that weird shit liket he cd functions, etc. Just the essentials.

also my game flippy biard multiplayer hd works out of the box now no questions asked. really cool. and my torture of tge afterflesh f ame which is my biggest and more serious project right now, a 3d game btw, can be played from start to finish with no problems at all except some ones with the graphics and view port, but theres not that much problem with that surprisingly, and i dont think it would take that many lines of code to f u x if the problem and solution is known agead of time without trial and error tweaking that can make more bufs, esp if not tested and launched in a new official commit release. Just my two cents at this point. There isnt mych lect to do with gm compatible regarding what i personally find essential, other than a crap liad of bug fixes. depends on what your game uses. If its uses all the shit that is currently proken, then forget it. I feel to be one of the luckier ones with that fortunately. Just depends on priorities and how much gm compatibilty gets in the way in contrast with how much ut would actually draw in more ppls desire to use the the engima game engine.

[TheExDeus]

If we could at least keep GM compatibility up to GM 8.1/GMS 1.4, that would be great.

I don't plan on dropping file formats, like gmk, gm6 and so on. They are already implemented and nothing can change for them. They will not be able to save some stuff like .egm can (right now even). When I talk about compatibility I mean function compatibility and language compatibility. Like EDL supporting stuff GML doesn't and maybe not supporting something GML does.

Of Game Maker files, or Game Maker Studio files?

I think one of you talks about the file formats (loading a game in LGM) and the other talks about actually compiling and running. ENIGMA didn't achieve that level of compatibility with GM that many games ran without changes, though it did achieve compatibility that 99% loaded in the IDE.

I'm impressed, Harri. I don't have much else to say.

Thanks.

.4 gmx is good enough.

I think we need to fix and improve .egm. I already use it everywhere, but more things should be supported. Like room shouldn't be in binary and we need to support an extracted format for version control (like gmx). Technically .egm can be totally backwards compatible all the time if we manage to save everything in xml or other description language. Right now the only compatibility problems can come from the binary room data. I am still not sure why nobody has changed that, as it was discussed previously. And seeing as we already support xml's, then doing a change should be trivial. Heck, copy 90% of GMX room description if you have too. Just be more consistent than them and support all the stuff we do.

[onpon]

Indeed, I was talking about compiling with ENIGMA, not opening in LGM.

[time-killer-games]

@harri and onpon, i mention the compiled side of things too (how the game compiles and runs without errors with little or no bugs to notice off hand at runtime), and gave examples of specific games, most which are huge, and how well the work, which is close to perfect. sorry for the long post im not concise and need to be aware of that next time i post.

[BPzeBanshee]

Seems there's a few elephants in the room here in this discussion. This may sound cynical but reading what's here I'd like to put my few cents in as well.

I'm all for taking .egm into the future with regards to breaking compatibility here and there so long as one can transfer the bulk of say, a GMK project and get it working with some alterations. GM8.x to GMS wasn't a painless process either and with features like BGUI it'd yield additional functionality without stupid sandbox restrictions. I was initially concerned about DLL compatibility with audio engines but looking closer with what ENIGMA provides there isn't that much of a need to use one, it's very functional as it is and much more so than legacy Game Maker.

As for GM compatibility in general, let's not pretend it ever really was the limelight goal of ENIGMA to make a complete stupidity-included GM clone. LateralGM maybe, but not ENIGMA. The potential *is* here to make a game creation engine inspired by GM's environment, but the biggest barriers that remain to bar people from taking serious interest in this project is not the compatibility (that's no.2) but actually getting the f**king IDE to work. Random crashes every 20 minutes, crashes when you press a button after doing a few compiles, modifying folder names to get it to start, modifying commandline arguments, having different versions of Java, error messages that give you no damn clue as to where things went wrong, etc all get in the way of providing a painless experience that both Mark Overmar's Game Maker and the new YoYo/PlayTech Game Maker provides. This combined with the licensing shenanigans is what's holding up adoption of the project.

Compatibility *was* a big deal once upon a time, when simple projects like my Warbird wouldn't behave because object inheritance and alarms were completely unsupported and graphical pipeline changes meant a build one week would display fine and next week have a big black triangle covering half of it and display everything in the wrong shade of colour. That stuff last I checked is long gone, with some of the remaining issues fixed I see has been listed in this very thread!

I feel the remaining barrier to compatibility here at this point (with exception given to unsupported functions that are also unsupported in GM:Studio) is exclusively ENIGMA's parser. The same parser that decided GMOSSE wasn't going to work because apparently the alarms I coded in GM8.0 aren't the same alarms it supports, because I did something slightly unusual in some Draw event and it panicked, because I don't even know what thanks to the completely useless error messages. Perhaps a strip-down of said parser as TheExDeus suggested may actually be a good thing to work towards this end-goal, start from scratch and build up as you say, have a fork of it for certain purposes and someone else can do another fork for GM-specific support, I don't know. Doesn't seem like anyone wants to touch the parser in its current state and I have next to zero C++ knowledge compared to my GML knowledge.

[time-killer-games]

Seems there's a few elephants in the room here in this discussion. This may sound cynical but reading what's here I'd like to put my few cents in as well.

I'm all for taking .egm into the future with regards to breaking compatibility here and there so long as one can transfer the bulk of say, a GMK project and get it working with some alterations. GM8.x to GMS wasn't a painless process either and with features like BGUI it'd yield additional functionality without stupid sandbox restrictions. I was initially concerned about DLL compatibility with audio engines but looking closer with what ENIGMA provides there isn't that much of a need to use one, it's very functional as it is and much more so than legacy Game Maker.

As for GM compatibility in general, let's not pretend it ever really was the limelight goal of ENIGMA to make a complete stupidity-included GM clone. LateralGM maybe, but not ENIGMA. The potential *is* here to make a game creation engine inspired by GM's environment, but the biggest barriers that remain to bar people from taking serious interest in this project is not the compatibility (that's no.2) but actually getting the f**king IDE to work. Random crashes every 20 minutes, crashes when you press a button after doing a few compiles, modifying folder names to get it to start, modifying commandline arguments, having different versions of Java, error messages that give you no damn clue as to where things went wrong, etc all get in the way of providing a painless experience that both Mark Overmar's Game Maker and the new YoYo/PlayTech Game Maker provides. This combined with the licensing shenanigans is what's holding up adoption of the project.

Compatibility *was* a big deal once upon a time, when simple projects like my Warbird wouldn't behave because object inheritance and alarms were completely unsupported and graphical pipeline changes meant a build one week would display fine and next week have a big black triangle covering half of it and display everything in the wrong shade of colour. That stuff last I checked is long gone, with some of the remaining issues fixed I see has been listed in this very thread!

I feel the remaining barrier to compatibility here at this point (with exception given to unsupported functions that are also unsupported in GM:Studio) is exclusively ENIGMA's parser. The same parser that decided GMOSSE wasn't going to work because apparently the alarms I coded in GM8.0 aren't the same alarms it supports, because I did something slightly unusual in some Draw event and it panicked, because I don't even know what thanks to the completely useless error messages. Perhaps a strip-down of said parser as TheExDeus suggested may actually be a good thing to work towards this end-goal, start from scratch and build up as you say, have a fork of it for certain purposes and someone else can do another fork for GM-specific support, I don't know. Doesn't seem like anyone wants to touch the parser in its current state and I have next to zero C++ knowledge compared to my GML knowledge.

Im having a sore thoat and thus, *coughs out "viewport and graphical issues" again* lol

and i use gms as my ide and could still use gm 8.1 as my primary ide either way its not much different, so i dont need lgm at all, but would be super cool if that worked on its own, without the crashes the quote above also reiterated quite nicely, some of which mention by darkstar before, and the earlier points by myself.

long live enigmas big fat harri sausage! :p

edit:

almost forgot, gm and gms have ide's that are fully functional for free, so lgm is completely garbage and thats why no one uses it, lgm being free isnt why one should use it, that the argument to use enigma partially, but not lgm at any level. The reason to use lgm is 100% the same reason as the other half of why to use enigma's compiler and not GM's, and thats the funxtions and features engima has which gm gms do not. Making sense? So if enigma is a gm clone and thats all itll even be, put lgm in... the garbage can, as we already have two great ide's that will always work and be a lot better, in that said secenerio, but.. If we are to make enigma stray away from the compatubily of gm and gms at any level, whether whole or in part, it is vital that lgm doesnt crash and works at all, otherwise we cant stray away from gms and gm related stuff at all. Make sense?

[Wendigo]

Well for Linux users like myself there is no way around LGM. It runs quite solid on Linux by the way, there are hardly any crashes.

[time-killer-games]

^My point exactly wendy, the crashing is primarily a windows issue. GM and GMS ide's only run on windows so yeah. Ive never had it crash once on my ubuntu OS before, personally. At least, not from what i can remember, its been a while since ive used that harddrive..

I guess it could vary depending on the linux disro, but i doubt it.

Not to mention wine runs both YYG ide's on linux too, then compile outside of wine using enigma's compiler. (Many have tried GM with wine and reported is works as it should).

Wine for Mac OS X however may be a different story as its a lot earlier in the development stages and is still a lot buggier even today, so ive heard.

[Goombert]

Yeah Windows is a large part of ENIGMA's problems. The OS has no package manager like any sane Linux distribution and every Linux distro comes with a C++ compiler generally. On Linux ENIGMA just utilizes the package manager to install OpenGL and other libraries but on Windows we have to ship the whole freaking MinGW compiler, plus all of its binaries that ENIGMA does not even use, plus all of the libraries ENIGMA uses but MinGW does not. That much really is a Windows problem and also a C++ problem because C++ has no standard ABI. This means you generally can't build C++ programs with one compiler and then link C++ code from another compiler. Such as writing Visual C++ dll's that are linked from a MinGW compiler. This means when you write a class in C++ the vtable or virtual table which holds all the pointers to the classes methods can be layed out in memory differently between each compiler, because C++ does not standardize how the implementation should work. The C++ standard only defines what the implementation of any standard function does not how it does it. This can even lead to problems linking C++ binaries to other C++ binaries that were produced with different versions of the same compiler.

https://en.wikipedia.org/wiki/Virtual_method_table
https://en.wikipedia.org/wiki/DLL_Hell
https://en.wikipedia.org/wiki/Application_binary_interface

This is also why I do not update the ENIGMA zip anymore because it's 100mb's and takes me an hour to upload which is a complete waste of time. We were going to make the server do this automatically but nobody has the time or interest to set that up.

Anyway I agree with BPzeBanshee, I really have no idea what this discussion or argument is about but I totally do not care. However I agree with him in that nobody wants to use ENIGMA because of how big a pain in the ass it is. This is especially true because of what I just mentioned above. These largely result from our use of JNA to communicate LateralGM's plugin with ENIGMA's C++ compiler interface. Related to the problems I specified above is the reason why a 64bit Java installation will not work when LateralGM is coupled with ENIGMA. I would also like to point out that because of the way Eclipse works it also does not work between different architectures of Java, so 32 bit Eclipse only works on 32 bit Java. But ENIGMA does not even have a 64 bit version on Windows because of the OS's above mentioned problems and the complete rubbish that is MinGW64 on Windows. It's a total nightmare to go and build this thing and that's why nobody wants to do it.

That aside if you take LateralGM and use it by itself without the ENIGMA plugin you rarely have problems but it is about as slow as GM8.1 with loading projects because both it and GM8.1 use managed languages (Delphi.NET and Java). This is also what a command line interface would solve because LateralGM and the Java Runtime would not have to link to ENIGMA at all and would not have to give a crap what architecture or compiler it was built for it would just pass command line arguments to it and be done. It's not even that these problems can't be worked around without a CLI it's just that nobody has the time or interest to do them and it's a lot of work to really do it correctly.

This is why I continued to package LateralGM separately from ENIGMA and why I feel it should continue to be done that way. LateralGM works great on its own and it's a wonderful and very stable program by itself with a lot of applications including recovering projects in niche cases that old and new GM versions can't handle.

[TheExDeus]

I was initially concerned about DLL compatibility with audio engines but looking closer with what ENIGMA provides there isn't that much of a need to use one, it's very functional as it is and much more so than legacy Game Maker.

Technically a lot of DLL's should work too, but they haven't really been tested. I think the FMOD audio extension relies on a DLL originally made for GM and it worked. This hasn't been tested much though.

As for GM compatibility in general, let's not pretend it ever really was the limelight goal of ENIGMA to make a complete stupidity-included GM clone. LateralGM maybe, but not ENIGMA.

I think long ago ENIGMA really did start as "Open Source GM". It wasn't meant to have more or better features, just the possibility to add them. So for a time GM compatibility was pursued quite zealously, even adding GM5 compatibility (trough an extension though).

That stuff last I checked is long gone, with some of the remaining issues fixed I see has been listed in this very thread!

Yeah, it should be a lot more stable these days, but there are still problems with regressions. We don't have integration testing, so it is often possible for things to break.

Yeah Windows is a large part of ENIGMA's problems. The OS has no package manager like any sane Linux distribution and every Linux distro comes with a C++ compiler generally. On Linux ENIGMA just utilizes the package manager to install OpenGL and other libraries but on Windows we have to ship the whole freaking MinGW compiler, plus all of its binaries that ENIGMA does not even use, plus all of the libraries ENIGMA uses but MinGW does not. That much really is a Windows problem and also a C++ problem because C++ has no standard ABI. This means you generally can't build C++ programs with one compiler and then link C++ code from another compiler. Such as writing Visual C++ dll's that are linked from a MinGW compiler. This means when you write a class in C++ the vtable or virtual table which holds all the pointers to the classes methods can be layed out in memory differently between each compiler, because C++ does not standardize how the implementation should work. The C++ standard only defines what the implementation of any standard function does not how it does it. This can even lead to problems linking C++ binaries to other C++ binaries that were produced with different versions of the same compiler.

This isn't as big of a problem you put it to be. First, Windows 10 finally has a built-in package manager, so looking forward to that. Second, there really isn't that big of an issue of providing mingw in an installer together with "Additional". I think the current method works quite good.

This is also why I do not update the ENIGMA zip anymore because it's 100mb's and takes me an hour to upload which is a complete waste of time. We were going to make the server do this automatically but nobody has the time or interest to set that up.

I'm willing to do that. I think you even posted some tutorial or something how you did it, so if you could link it then I will start doing it. Internet isn't a problem where I live and 100mb's is really not an issue speed wise. Only need to find a good place to host - I think hosting on Dropbox isn't the best way. Maybe we have a way to host on ENIGMA's website? I don't know how much space we have though, Josh should know.

But ENIGMA does not even have a 64 bit version on Windows because of the OS's above mentioned problems and the complete rubbish that is MinGW64 on Windows. It's a total nightmare to go and build this thing and that's why nobody wants to do it.

I can compile ENIGMA (the plugin) on 64bit, but of course the LGM stuff needs to be changed too in that case.

That aside if you take LateralGM and use it by itself without the ENIGMA plugin you rarely have problems but it is about as slow as GM8.1 with loading projects because both it and GM8.1 use managed languages (Delphi.NET and Java). This is also what a command line interface would solve because LateralGM and the Java Runtime would not have to link to ENIGMA at all and would not have to give a crap what architecture or compiler it was built for it would just pass command line arguments to it and be done. It's not even that these problems can't be worked around without a CLI it's just that nobody has the time or interest to do them and it's a lot of work to really do it correctly.

Yeah, finish the CLI would be a good start. I think the only big thing missing there is rasterization of fonts? All the other things are either done or should be easy.