Hello all,

There's been more than a few discussions on the project Discord since I last updated this thread so I fell out of making status updates here, but Warbird's a helluva lot closer to working in ENIGMA at last than it used to be (the sooner RadialGM gets finished the better).

I've updated the thread title with the current status of compiling Warbird in ENIGMA based off my test build I've been messing with in Studio 1.4.9999. I've also updated the original post description a bit with a link to the original post text on a Pastebin since the forum doesn't support spoiler tags, and updated the download link to point to the Bitbucket site for Warbird that I made a few years ago after having some trouble with Mediafire.

Been out of the loop for a little while until I received an email notification about an old GitHub issue I reported last year. This work on not only a new IDE but a consistent and stable way of using ENIGMA sounds promising and if I don't have to jump through a stupid amount of hoops to get it to work like I did last time I'll be happy to test my projects on it again in the future.

* Do not expect to be able to export any RadialGM project back to a GM format, you will likely convert your projects to EGM upon open/load and then either maintain two copies or stop using GM.

This has me somewhat concerned though. I think I understand the reasons for why writing support is being dropped given YoYo's tendency to change how they themselves write to it, but EGM has never been reliable in the time that I've spent looking at this project and as a binary flat ala GMK I'm not sure limiting export options to that is a good foundation. Would it be out of the question to at least consider GMX (Studio 1.4) write support as an alternative to it given that GMS 1.4's update support ends this month and therefore won't be subject to the above issue with YoYo?

Also, will RadialGM work like LateralGM in that it'll function for at least the purpose of opening and viewing projects without ENIGMA necessarily set up? This and the GMK format support were LateralGM's biggest strengths.

As for the subject of installers and the like, I'd be more than happy with a portable ZIP solution as long as it works. The existing portable ZIP from last year reminded me somewhat of MAME's environment system but where MAME had clear instructions and had the needed components there to go, ENIGMA required research through multiple pages and extra components to slot in from Dropbox links.

[Also, if someone could please make a note in LateralGM that the DirectX11 renderer currently causes a complete system lockdown and shouldn't be used at all, that'd be great.]

Thank you for your patience faisaloo. After a few days to clear my head and a bit of research around the depths of this forum I was able to diagnose the problems with getting LateralGM/ENIGMA itself to work.

Since the information I gleaned to help get this result is scattered around several places apart from the Wiki itself I'll write it down here:

1) Use 32-bit Java. Apparently some component of ENIGMA won't accept compileEGMf.dll otherwise. In the "idecommand" tag in settings.ini of the portable build I had to specify the exact directory for java.exe.
2) Run git-bash.bat and type "update". This seems to update the bulk of the repo itself but does not account for LateralGM or the other java files.
3) In the ENIGMA folder run install.py. I had Python for Windows already set up so for me it was just a matter of double-clicking but git-bash.bat with "cd ENGIMA" then "install.py" might work too?
4) Run ENIGMA.exe with administrative privileges. This alone made the difference between the really fucking vague error and actually getting a running game.
5) Expect that LateralGM will probably crash spontaneously no matter what you do

From testing I can confirm that the alpha clamping issues previously noticed seem to be gone, however TheExDeus's fixes for direction issues don't seem to have been brought into the mainline branch so Issue #933 is still present. In addition to this there is still an order-of-events issue where compared to GM the collision event from obj_player_shot to obj_en_parent is happening after obj_en_parent to obj_player_shot instead of before, resulting in shot explosion animations not being called when hitting enemies (except when the smaller ones are still moving, which is weird).

Also, if someone could please make a note in LateralGM that the DirectX11 renderer currently causes a complete system lockdown and shouldn't be used at all, that'd be great.

Saw that the pull request had been merged so I started from scratch as per Install:Windows wiki page.

LateralGM wouldn't compile compileEGMf.dll until I put the specific directory for Java in the settings.ini. %PATH% inclusion is fine, it's literally what the Java installer put for it. Not sure why this still doesn't work for the launcher.

I use the included batch file and type update, it didn't update LateralGM, so I manually downloaded that and put it in. Some other error popped up on attempt to make a blank room run.

Put in enigma.jar from Install:Extra_Packages, got as far as making a blank room. I load up the GM:Pro version of Warbird and I get this very fucking descriptive error:



The debug option didn't help, neither did changing sound or video systems.

Give me a buzz when the barrier for entry isn't so high I have to gdb backtrace anything that isn't a blank room.

I got a bit further after looking at your instructions, it got the compiling to go but still wouldn't accept that it was even there. Putting the exact Java directory in settings.ini fixed that much but I can't open gmx project files with the LateralGM that came with the WinPatch folder, not even a blank room actually compiles and runs anymore, and I can't use the new LateralGM because when I do I get this on startup:

Operating System: Windows 7
Version: 6.1
Architecture: x86

Java Name: Java HotSpot(TM) Client VM
Java Vendor: Oracle Corporation
Version: 1.8.0_91

Available processors (cores): 8
Free memory (bytes): 230056064
Maximum memory (bytes): 1013645312
Total memory available to JVM (bytes): 259588096

File system root: C:\
Total space (bytes): 224945762304
Free space (bytes): 50593607680
Usable space (bytes): 50593607680

File system root: D:\
Total space (bytes): 0
Free space (bytes): 0
Usable space (bytes): 0

File system root: G:\
Total space (bytes): 1000169533440
Free space (bytes): 629001560064
Usable space (bytes): 629001560064

Stack trace:
java.lang.NoSuchFieldError: FUNCTIONS
   at org.enigma.EnigmaRunner.setupBaseKeywords(EnigmaRunner.java:505)
   at org.enigma.EnigmaRunner.access$0(EnigmaRunner.java:502)
   at org.enigma.EnigmaRunner$3.run(EnigmaRunner.java:187)

I don't know for sure whether it's specific where it's something on my end (my PATH is fine and adding the direct folder instead of Oracle's symlinks made no difference), something in your branch, something in the main branch or something with LGM itself or something with ENIGMA itself.

I'm going to have to just wait until this gets pulled into mainline and an out-of-the-box build gets made available because I no longer have the patience to piece things together. For the last three years running every time I try to get this going it explodes in my face - either just launching it or trying to run a simple 20-second game - when GM:Studio just works.

Excellent news!

I attempted to get ENIGMA working again using a ZIP of faisaloo's master branch to see whether it did indeed fix the image_alpha behaviour on Warbird but it failed to compile the compileEGMF.dll-thing needed to work. Not sure what I did wrong there.

NOTE: Trying to use this branch now will probably fail. My changes relies on newer GCC (the compiler) and MAKE. Thus if you do overwrite your current ENIGMA it is still very possible you won't be able to compile a game anymore. I will try packaging a new ENIGMA installer at some point.

Ah, this is probably my main cause for failure. Once I realised I missed the Windows dependencies I did the overwrite approach and got a different error that seemed to suggest something along those lines. I've compiled and messed around with MAME before so this might help me tinker in the right direction.

On the subject of Windows 10, as a retail worker I do not trust it. I crashed one of the display machines at JB HiFi just by navigating around with the mouse and I've already seen customers do returns on products where I work because Windows 10 screwed something up in the install process and wouldn't let them revert it back (deleting the factory default image of the system that Win8.1 uses for it's "Reset system" option is also bad jujus). Win7 and XP were pretty cagey initially though - give it a few months and we'll see how stable it is, NSA playground/control panel issues notwithstanding.

Stupid question from me and I'll shut up again: how does one actually get the GL3.3NormalMatrix branch running in Windows at the moment? I can get the normal ENIGMA seemingly fine in my existing folder but as soon as I replace the enigma-dev with the branch one, add the Windows utilities in and try to run a Hello World I get compile errors - http://pastebin.com/zzP8h44x. Am I supposed to rather overwrite the former with the latter?

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.

Seems you're right about GM rounding values all around. Did a bit of research and found GM:Studio has a math_set_epsilon function that allows for a system-wide version of what you describe and the latest update allows for the internal rounding to be switched off. IIRC GM 8.0 did not have this and just rounded from the 3rd place value for functions like vspeed.

Perhaps math_set_epsilon can be implemented and the folks with the fetish for having 0.05 - 0.05 = 1-0e2754whatsit or 0.0000000000000000000000000001 as normal behaviour can still do so using math_set_epsilon(0)?

I isolated one of three remaining compatibility issues with Warbird and it seems I'm treading old ground. I note this GitHub report here from a few years ago where it was described as a non-issue but in the interests of GM compatibility I'm inclined to disagree. Note my test build here: https://www.dropbox.com/s/516eqyqi4qq7o1s/Test8.gmk?dl=0

Basically, as you decrement in increments of 0.1 when you go from 0.1 to 0 the variable you're subtracting becomes some twisted number other than 0, which if you're using for if statements leads to different things happening based on what video renderer you're using. Under OpenGL it spits some weird scientific notation and stops, but in DX9 it becomes a truncated value and continues decrementing resulting in going past 0 entirely and into negative value territory. Of course in GM it hits 0.

I'm concerned that this particular behaviour is different for the OpenGL renderers vs the DirectX9 renderer, the latter which I understood was supposed to be closer to GM's behaviour as it too used DX9, and is causing noticable differences in my GM projects vs in GM itself. For a "non-problem" GM is handling things very differently from ENIGMA here and I think it'd be worthwhile to have some kind of precision toggle in the Compatibility/Progress sector.

Thanks guys, it seems you've hit the hammer on the nail.

I'll have to test again once I get back to the machine with GM:Studio installed, but Studio adds a character range of 0 to 127 if memory serves me correctly. 0 to 255 seems more effective still though. When drawing text with no character range at the moment it drew absolutely nothing, but did not generate errors.

If it's supposed to do that, then there must be a bug I guess, because it isn't working for me that way. Here's a screenshot of what I get:



Until I press + and get a character range in the white box on the bottom-left corner the font file is completely unusable.

My only recommendation would be when making a new font file to add a default "group" to it straight away (not sure what to call it, whatever it makes in the bottom-left box when you press +) instead of making the user have to press + or Preview to add one, I can't really comment on anything else but from what I gather it seems fine otherwise.

When doing my test builds requiring only a basic font I didn't look twice at the font manager - right-click, add font, done like every other GM version - and then wondered how come my object wasn't drawing anything to the screen, only to find because it didn't have this "group" thing set it was drawing with no actual characters instead. Makes me look like an idiot I know, but it seems like a simple addition to make it less idiotproof, if you will.

In my tests of ENIGMA/LateralGM vs GM behaviour today I discovered that pressing the buttons to change the font character range when editing a font does not respond at all until you press either the + or Preview buttons underneath. In Game Maker 8.0 Pro it just fills a default character range as does Studio, but Studio seems to have multiple presets in a similar fashion as LateralGM does here. Studio however makes a preset but LateralGM does not.

Simple question I put here because I'm not entirely sure it belonged in the tracker, but is this intentional behaviour or not?