Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Goombert

General ENIGMA / Re: ENIGMA progress
« on: August 09, 2015, 07:45:36 am »
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.
I've seen it already and I don't think I care, it will take some time for it to take effect either way. I really would just rather use Linux which solved all of these problems a long time ago. I don't switch to Linux full time because I really do need things like Word which does happen to be more reliable than Google Doc's or Open/Libre Office. While I may be exaggerating the problems they are very real and I think you are undervaluing them. There are a large number of complaints about C++ but most of them Bjarne Stroustrup dismisses except for a standardized ABI. I don't mind coding in C++ at all and I did make a number of substantial improvements to ENIGMA's engine including starting that model class (though I've learned much more C++ since then) but this really turns me off from trying to build cross-platform applications or applications to be distributed in the language.
Quote from: Bjarne Stroustrup
The compatibility with C at the system interface level has encouraged people to use C-style strings, arrays, and structs, where they would have been better off with some higher-level abstractions presented as classes or templates. Instead of leaving the low-level facilities at the system level and within the implementations of classes, people have let the low-level constructs - and pointers to them - permeate their designs. Type errors, wild pointers, array bounds errors, and memory leaks are the obvious results. Lots of macros and casts often adds to the obscurity of the code. It saddens me to see some of the unnecessary messes people get themselves into.

This is why I still really honestly like Java besides its amazing new MVC GUI API called JavaFX (which I am building some of my prototypes in). Java is still amazing in that you can generally build quick cross-platform applications, build them once, and deploy anywhere. This idiom only gets broken when you try to mix it with native code like ENIGMA which really sucks, it is the lowest common denominator, and gives you the benefits of neither Java nor C++. Regardless I agree with Mr. Stroustrup 100% on everything he's said there.

Quote from: TheExDeus
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.
The topic is pinned in "General ENIGMA" and I would appreciate it if someone else would build the ZIP occasionally. Josh could obviously give you FTP access to the server but I've just realized that we could just upload these to GitHub directly if Josh enables it on the repository. He does it this way for Calico (click "Releases"). I think we should upload the ENIGMA binary releases directly to GitHub since that is a standard/more common approach.

Quote from: TheExDeus
I can compile ENIGMA (the plugin) on 64bit, but of course the LGM stuff needs to be changed too in that case.
That would be great as well because then users would at least be able to download a 32bit and 64bit version of ENIGMA and they wouldn't have to specifically install a 32 JDK/Java. You would have to recompile all of ENIGMA's plugins though and I also think you need to replace the jna.jar with the 64bit version. I hit too many errors and incompatibilities between MinGW64 and 32 and finally just gave up on packing it. It's sitting on my desktop and was the last thing I was trying to accomplish before I stopped contributing for this period of time. Largely because of my poor internet, if someone else were to begin packing the zip or just taking care of it instead of me by some standard/methodical approach as I did before it would make it easier for me to contribute to ENIGMA again in the future. I am actually mainly still interested in LateralGM's development so if I could maintain improvements and bugfixes to that and delegate the ENIGMA matters to someone else (regarding packaging LGM and everything) it would be a lot of work off my plate and free me up for more contributions to LGM.

In my honest opinion I still like ENIGMA on Linux because it just uses the package manager, you install the necessary components one time and then ENIGMA just works. You can easily replace the lateralgm.jar and the entire ENIGMA framework just as it is expected.

Quote from: TheExDeus
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.
Yes that is one thing that it needs but it is debatable whether the ENIGMA engine should provide such functionality as well, perhaps through a plugin because GM does have functions to add fonts at runtime that we never implemented and I believe Studio added TTF font support or w/e.

Quote from: TKG
Yes calm down TKG, you're being eccentric. You know some of the prototypes I've been working on and one of them is about to be released open source in a few days. It is a library that is a necessary component to bigger things I am developing and are ENIGMA related.

General ENIGMA / Re: ENIGMA progress
« on: August 07, 2015, 05:28:47 am »
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 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.

Third Party / Java 8 Nashorn Script Engine
« on: July 31, 2015, 01:12:40 am »
For a side project I am developing in Java I needed a good JavaScript parser but the publicly documented Nashorn interface is all about compiling when I only needed an intermediate representation. It is currently possible as of JDK8u40 to use the parser to get the AST as a JSON encoded string either from a JS file being executed by the ScriptEngine or from within Java using the non-public Nashorn API.

An abstract syntax tree is produced by a parser after the lexer phase breaks code into a stream of tokens. The below image should convey to you how a simple assignment statement is broken into a stream of tokens then an AST is generated as JSON on the right. This is why symbols like * + - are called binary operators because they take two operands, ! is the logical negation and an unary operator becaues it takes only one operand. The operands can also be expressions because expressions are defined recursively in terms of expressions which can be literals, terms, or other expressions. This is how we end up with tree's and these tree's coupled with semantic information such as keywords and identifiers help us do code generation which can let the whole process take in one language, say GML, and spit out a completely different one like C++ and if you don't already know this is exactly what ENIGMA's compiler does.

Wikipedia has additional information on abstract syntax trees if you would like to know more.
The following StackOverflow post provides clarification between an AST and a parse tree.

My first example here is the standard example on the web of how you can get the JSON tree for any arbitrary JavaScript parsed by a JS script that is being actively executed in Nashorn. You can take this AST and print it or traverse it in JS or pass/return it up to Java through a binding. This example was taken from the following link.
Code: (JavaScript) [Select]
#// Usage: jjs -scripting -fx astviewer.js -- <scriptfile>
 * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *   - Redistributions of source code must retain the above copyright
 *     notice, this list of conditions and the following disclaimer.
 *   - Redistributions in binary form must reproduce the above copyright
 *     notice, this list of conditions and the following disclaimer in the
 *     documentation and/or other materials provided with the distribution.
 *   - Neither the name of Oracle nor the names of its
 *     contributors may be used to endorse or promote products derived
 *     from this software without specific prior written permission.

if (!$OPTIONS._fx) {
    print("Usage: jjs -scripting -fx astviewer.js -- <.js file>");

// Using JavaFX from Nashorn. See also:
// This example shows AST of a script file as a JavaFX
// tree view in a window. If no file is specified, AST of
// this script file is shown. This script demonstrates
// 'load' function, JavaFX support by -fx, readFully function
// in scripting mode.

// JavaFX classes used
var StackPane = Java.type("javafx.scene.layout.StackPane");
var Scene     = Java.type("javafx.scene.Scene");
var TreeItem  = Java.type("javafx.scene.control.TreeItem");
var TreeView  = Java.type("javafx.scene.control.TreeView");

// Create a javafx TreeItem to view a AST node
function treeItemForASTNode(ast, name) {
    var item = new TreeItem(name);
    for (var prop in ast) {
       var node = ast[prop];
       if (typeof node == 'object') {
           if (node == null) {
               // skip nulls

           if (Array.isArray(node) && node.length == 0) {
               // skip empty arrays

           var subitem = treeItemForASTNode(node, prop);
       } else {
           var subitem = new TreeItem(prop + ": " + node);
    return item;

// do we have a script file passed? if not, use current script
var sourceName = arguments.length == 0? __FILE__ : arguments[0];

// load parser.js from nashorn resources

// read the full content of the file and parse it
// to get AST of the script specified
var ast = parse(readFully(sourceName));

// JavaFX start method
function start(stage) {
    stage.title = "AST Viewer";
    var rootItem = treeItemForASTNode(ast, sourceName);
    var tree = new TreeView(rootItem);
    var root = new StackPane();
    stage.scene = new Scene(root, 300, 450);;

This example shows you how to get the AST as JSON from Java. This was my own discovery from studying the Nashorn source code.
Code: (Java) [Select]
String code = "function a() { var b = 5; } function c() { }";

Options options = new Options("nashorn");
options.set("anon.functions", true);
options.set("parse.only", true);
options.set("scripting", true);

ErrorManager errors = new ErrorManager();
Context contextm = new Context(options, errors, Thread.currentThread().getContextClassLoader());
String json = ScriptUtils.parse(code, "<unknown>", false);

Both of the above two examples should give the following JSON encoded AST. This JSON encoding provided by Nashorn is compliant with the community standard JavaScript JSON AST model popularized by Mozilla.
Quote from: Java Console

This example code shows you how to get the AST as a Java object representation however the interface is poorly documented and I could not for the life of me figure out how to traverse the children of the function node. This solution is adapted from a StackOverflow post.
Code: (java) [Select]
String code = "function a() { var b = 5; } function c() { }";

// parser options including anonymous functions
final Options options = new Options("nashorn");
options.set("anon.functions", true);
options.set("parse.only", true);
options.set("scripting", true);

ErrorManager errors = new ErrorManager();
Context contextm = new Context(options, errors, Thread.currentThread().getContextClassLoader());
// get a source handle for arbitrary javascript code passed as a string
final Source source = Source.sourceFor("<unknown>", code);

// get the global function node to traverse the parsed AST
FunctionNode node = new Parser(contextm.getEnv(), source, errors).parse();


for (Statement stmt : node.getBody().getStatements()) {

You should get the following output on the Java Console from the above code.
Quote from: Java Console
function {U%}a = [<unknown>] function {U%}a()
function {U%}c = [<unknown>] function {U%}c()

It is important to note however that this interface may change because it's not well documented and is new to the JSE. Additionally the OpenJDK project is developing a public interface for Java 9 that allows AST traversal in a more standard and user friendly way.

Limited documentation for the existing public Nashorn classes in Java 8 can be found below.

The following link provides a list of all of the parser and compiler options that I set above. However it is important to note that the syntax is different when setting the options inside Java where - is replaced with a period.

The Nashorn source code can be found on GitHub and also on BitBucket. I prefer the BitBucket version as the GitHub version seems to be missing some classes.

General ENIGMA / Re: ENIGMA progress
« on: July 31, 2015, 01:07:26 am »
Very nice work Harri I like seeing the contributions you have been making. I am still too stressed out for ENIGMA development. I am working on something very cool right now on my vacation that I hope you will all enjoy very much, a lot simpler than ENIGMA but something you may not be thinking of. However some of the ideas are based on previous prototypes which I am not sure if I've shared.

And for anybody afraid to contribute you shouldn't be, ENIGMA is a great way to not only learn game development but to learn game engine development. I had never used Java before I joined the forums and most would say I really turned LateralGM around. I was not completely new to C++ either but I was fairly novice and managed to accomplish a number of tasks in the engine. It really only takes the perseverance but it is still a lot of work regardless of how much you know.

What's a better way to learn game development than GameMaker? I'll tell you the answer and it's by building GameMaker itself. The opportunity has presented itself, it's right here and it's called

Function Peer Review / Re: Lua Extension
« on: July 31, 2015, 12:59:36 am »
Was this merged into the main repo?

I've moved this temporarily down to Function Peer Review as I am not quite sure where it belongs on the board.

Programming Help / Re: How are instances working?
« on: July 31, 2015, 12:58:05 am »
Just a note if you do not mind I am going to move this topic to Programming Help along with your topic regarding ENIGMA templates since they don't directly pertain to active ENIGMA development/projects.

Here is also the location of your other topic I moved to this board:

Issues Help Desk / Re: Some Fervi's Question
« on: July 07, 2015, 07:01:12 pm »
Yeah basically what Josh said, though I am kind of diverging myself in a lot of different directions. I've so overloaded with school work but I have a really amazing prototype of some of my new ideas and a lot of great ones that I am not going to drop on this forum because I want to retain them. Some people I've been keeping in the loop about some of these things I've been working on it, but it is too early for me to say much. But I am basically behind what you are saying Harri and we're pretty much on all the same page. I am hoping that I may actually come up with something for the interim that will put us back on the right track until Josh solidifies his ideas and plans.

General ENIGMA / Re: What's next for Enigma?
« on: June 13, 2015, 10:49:41 pm »
I figured I'd post just so I don't leave you all hanging on a limb. Sorry if I've been AWOL for quite a while, college and life has had me extremely busy. Josh is still working on his new compiler TheExDeus, I haven't really gone anywhere and we all still hang out in #enigma-dev IRC on freenode. I haven't been doing much work on ENIGMA because I don't find it very useful at this point in time. I've been focusing what efforts I can into side projects such as an IDE that both me and DaSpirit are too busy to develop full-time. However we have actually made progress this time instead of just building GUI's and going crazy announcing new platforms, it follows a proper MVC 3-tier architecture and we've been following Dreamland's guidance on its design. Essentially the plan is to build a modular IDE much like how the engine is where everything can be swapped in and out, this was our original focus but we didn't really have any idea, but with college and all our research we've been improving a lot, especially me.

The problem now is that this IDE project in and of itself is a monumental task. But one of the hopes of it is to make it modular enough that more people can contribute to it, and the project is maintained primarily by DaSpirit and however we structure any contributors around it in addition to it being a newer framework with a modern GUI and all the other little themeing and customization tidbits. Another present interest of mine is developing JEIE for the web with HTML5. The main purpose of JEIE to begin with was that there are few Microsoft Paint applications of good quality for Mac and Linux. I don't like the structure of JEIE and I'm really starting to hate Java as a platform, not because it's interpreted, but because Oracle likes to stick crapware in the installer and security exceptions like to be a pain. At any rate I am really interested in bringing this image editing program to the web, but I haven't even had time to begin the project and I don't exactly know what I have in mind yet.

Also with YoYoGames having just killed GameMaker 8.1 support a few weeks back I think it's safe to leave the ENIGMA project where it currently is at the most stable release we have. We'll go from here and see how things develop into the future, but we're all still here and working on different things related to the project.

Developing ENIGMA / Re: MinGW 64
« on: January 22, 2015, 11:12:03 pm »
That's a possibility and yes it would be relatively straight forward Harri.

I think I will just recompile the libs for 64bit and get a 64bit Portable out first and then we can discuss restructuring the ZIP's.

On side a note I had to push another fix to make it build for Mingw32 again, so it builds for both now, it should work for both 32bit and 64bit GCC on Linux now as well. In addition the compiler now builds with C++11 support.
This was to fix the issues reported in the other topic.

Edit: Just a quick update here I managed to get the basic engine compiling with Mingw64.

Thanks to Rusky for making a 64bit zlib and me finding a 64bit FFI lib, the basic engine and graphics now build. What you see in the following screenshot is the first 64bit ENIGMA game built with Mingw64 with LateralGM running in a 64bit JVM and a 4GB memory capacity. It can build at least Project Mario with DirectSound so far.

Note: If you try setting -xmx to larger than 1GB in the regular Portable the OS will probably not allow LGM to launch, I've tried it myself.

There are only 3 things left to do, build a 64bit OpenAL, Box2D, and Bullet and we can release a 64bit Portable. OpenAL will be the bulk of the work because we have to rebuild vorbis and a bunch of other libs to support all the audio formats.

Issues Help Desk / Re: sprite_add not working?
« on: January 22, 2015, 09:13:39 pm »
Haha, no I was merely pointing out that it is really easy to add new functions, just like you would in your own self contained game or C++ program, it's extremely trivial.

On a side note I also managed to get the latest 32 bit branch working again with sorloks gif fixes and my 64 bit compiler fixes, and the image loaded fine for me from the working directory simply calling it "file.png"

So Darkstar2's version probably just got broken or out of sync somehow.

General ENIGMA / Re: ENIGMA compiled EXE detected as virus!
« on: January 22, 2015, 06:23:47 pm »
This isn't new this is exactly what you reported last time and it hasn't changed.

Most reliable source I can find says that it could be related to using AppData, though I didn't think our exe's use that at all, only the compiler.

It could also be some of the extensions because those load DLL's, one of the reasons the old GM games still get flagged is because of DirectPlay, which is obsolete. Studio also does not handle resources the way the old GM did, its executables are essentially self-extracting 7zips, you can actually use 7zip to extract the audio from any standalone exe made with Studio, just extract it like a 7zip, though I haven't tested on the standalone installer. This is what my attempted decompiler originally did besides scanning for png and bmp files.

I'll run the test myself before and after disabling some extensions. Either way I am not really concerned with what some silly virus scanner on the internet says, we know for a fact it's not a virus.

Edit: Oddly enough switching off all systems and disabling every extension except paths gets it flagged by a different scanner, but still 1/57
Qihoo-360    Malware.QVM20.Gen    20150123

Using only Direct3D9 the same way but instead of OpenGL with no extensions flags it twice.
CMC    Packed.Win32.Katusha.1!O    20150120
McAfee-GW-Edition    20150122

For why you shouldn't care what this scanner thinks either, read the following:

Issues Help Desk / Re: sprite_add not working?
« on: January 19, 2015, 11:10:25 pm »

I don't know, I plugged it into my last Project Mario build and it seems to work fine. I can't build an exe right now because I have the 64 built configured right now but I haven't updated the libraries. An executable would be helpful.

Issues Help Desk / Re: sprite_add not working?
« on: January 19, 2015, 09:54:52 pm »
Do you have the PNG? I'll test myself, Project Mario uses extensive BMP and PNG loading. Also the code that you are trying to load it with.

Issues Help Desk / Re: Extension .egm does not match EGM?
« on: January 19, 2015, 07:34:14 pm »
Yeah this is a known bug, when adding multiple constants support I temporarily broke EGM format. Basically me and Josh really aren't sure what to do at this point.

Josh hates the EGM format, it saves rooms as binary blobs like the GMK format and it's barely extensible at all. What he would like is to basically rewrite the whole format with a proper spec and implement everything properly. We have a GitHub ticket filed on this:

For now you can just use the old LGM if you want, though I don't think it will work with ENIGMA anymore. We really need to get this fixed ASAP but I specifically don't know what to do, I'll have to talk to Josh.

No problem, I had to fix it because it was actually me that just broke it lol. And because now I accomplished what I wanted, 32bit and 64bit support for JDI and the compiler. As usual let us know if you have any more problems!