ENIGMA Development Environment

It is weird that surface_is_supported() returns true. It checks the GL extension and it shouldn't lie. So what hardware, OS and drivers do you have?

Sadly we don't have a way to see which version of GIT a person using. So we can just ask where and when did you download ENIGMA?
Also, try this and see if you can see the image:
https://dl.dropboxusercontent.com/u/21117924/surface_avatar.exe
Because it works for me as well. If you see it, then you have old ENIGMA and it probably had some bug. If you don't, then there is a bigger problem.

Hi. I don't have the time or creativity required for original content so I though we (or just I, but some sprite work would be nice) could make some remakes just to show ENIGMA's potential. I would also want the development time to be recorded as rapid game creation I think is the biggest selling point of ENIGMA (if there ever was such a point). The idea came from watching Greenlight and Kickstarter where there are a lot of old style games, but by reading the info it always seems there was a lot of time invested in the coding part. For example, for the past week or so I was hooked on FTL: Faster Than Light and the guys who made it said they did the engine part for 6 months.... and I can assure you that I could remake that engine in maybe a week of intensive work in ENIGMA. The same with Broforce which I saw yesterday. They made it a lot faster (because it originally was for ludum dare), but I believe that in ENIGMA all of that could be made faster still. Same for games like Meatboy and others.
So what you guys think? If anyone has a game they would like me to try to remake (my scheduled is quite full though, but this is just a test for me. Others can take over if I fail or just do it separately), then post it here.
My current ideas are:
FTL: Faster Than Light
Meatboy
Maybe Broforce, but that would just be interesting from the destructible world part.

The problem with this is that they are all indie games. For example, if I make a very precise remake of FTL then that could actually be negative and seen as copying other people ideas. And then if I release them as freeware then people would think I want to rip off the original devs.

We should remove the possibility to save as gm81 until we CAN actually save as GM81. Because if lolman closes his project now and then opens it he will see no event code and thus his project will be ruined. I sadly did that to one my projects, but I think I will be able to fix it by using .egm and then manually modifying some files.

Well, in a room, don't we have objects running in parallel (in the step event) ?

Josh already replied, but I will clarify how it all runs now (at least I think I know). Just like in GM, ENIGMA runs sequentially on one core. All of the instances are run in order sorted first by depth and then by id. And all of the events are executed in a certain order, like the first one is create, then step and then draw, but there are many more events. The execution order is the same as the order in which LGM shows them (at least it should be). That is why Create is always before Step and Begin Step is also before Step in the LGM object editor. So if you have three instances, one instance is object0 with depth=-5 and two instances of object1 with depth 0.
The id of the first object1 instance will be 0, the id of the second object1 instance will be 1 and third will be 2 (in reality they are a lot bigger). There are going to be 3 events - create, step and draw. Then every frame this is the order it will execute:
Create for object0 instance with id 2;
Create for object1 instance with id 0;
Create for object1 instance with id 1;
Step for object0 instance with id 2;
Step for object1 instance with id 0;
Step for object1 instance with id 1;
Draw for object0 instance with id 2;
Draw for object1 instance with id 0;
Draw for object1 instance with id 1;

After this it will do some internal work (swap buffers, get input etc.) and then do it all again the same order. Internal work is also done between events.

Also when i call the instance_create to start the animation, it's like an asynchronous call.

Animation is automatically done between events. Like image_index+=image_speed is done before Draw event. Like in previous example it would show up as:
Create for object0 instance with id 2;
Create for object1 instance with id 0;
Create for object1 instance with id 1;
Step for object0 instance with id 2;
Step for object1 instance with id 0;
Step for object1 instance with id 1;
Advance image_index by image_speed for object0 instance with id 2;
Draw for object0 instance with id 2;
Advance image_index by image_speed for object1 instance with id 0;
Draw for object1 instance with id 0;
Advance image_index by image_speed for object1 instance with id 0;
Draw for object1 instance with id 1;

I don't know this is entirely accurate because I don't remember the event order from the top of my head. But the idea is that it all runs in order. Nothing is done in parallel.

Josh, while we could do parallelism for some things I think we realistically cannot do it for most. We can just give users the means to do it for themselves. Like adding functions to create threads and control them. As we don't have functions per se (just like GM), then threads would just execute scripts. Like thread_create(scr_script0) and then it runs in parallel. If something breaks because of some race condition then it will probably be the users responsibility to add mutex and semaphores. Also OpenMP could be useful as an extension. So a very heavy loop could be made to run in parallel just by #pragma omp parallel for.
I also know that there already were some threading functions in ENIGMA. I don't know if they really worked though and where are they now.

The animation just seemed to be two rectangles going apart in the middle. It should be trivial to calculate the time needed. Like if the view_height=640 it goes apart with speed of 50, then alarm[0]=ceil(view_height/2/moving_speed)=7. So in 7 steps it will disappear (go out of screen). You can also reverse the calculation just by taking time to do it. Like you want the animation to end in 2 seconds, then alarm[0]=room_speed*2 and moving_speed=view_height/2/(room_speed*2)=5.333 (if room_speed=30).

edit: Here is an example: https://dl.dropboxusercontent.com/u/21117924/Enigma_Examples/reveal_example.gmk

Even 2-3% is a little high, but it's in the ballpark where it should be.
I just compiled your egm and I can run it with 1% CPU use like normally. So I am sure you have some buggy ENIGMA installed. In the topic you mentioned that Robert's version worked and so you probably didn't try the one I mentioned. Maybe try that (it should work when you have two versions extracted. Just extract it to another folder). I don't know about Robert's version, but the one I posted downloads newest stuff from GIT.

We should REALLY fix this installing BS. Previously we didn't have working installer, but now we have several which "supposedly" works, but apparently differ in content. Which lead to this topic and took 3 pages to figure out. So I propose:
1) Pack everything just like Poly did, so on first run it would download everything from git. I also think it would be nice if it showed if newer commit is available and propose to download that as well.
2) Pack the newest LGM with it. The poly version has old plugin and old LGM which creates hoops you must jump trough to get it all working.
3) Rename the LGM correctly (or change ENIGMA.exe accordingly), so you don't have to rename it every time you want to install it.

Of course the problem could also be with his MinGW. But for now I think it is the ENIGMA.

But as far as I can tell he is the only Windows user we have who has this problem. It's weird, but still shows that it could be something specific to him. ego, have you tried on another PC? And if you sometime in the future reinstall Windows then try again. And did you actually install the OS or was it preinstalled with the PC?

edit: And what is this TestOpenGL.exe you are running all these tests? Is it really an empty game? I guess you would notice if it wasn't...