Makes Sense.

Perhaps we could get some feedback from any newer people here, what were the impressions you got when you first came here and initially ran ENIGMA and started to use it? What are the problems you most frequently run into with ENIGMA?

I have noticed that the community here has become a little stagnated, so I've thought of this project that may hopefully get people here a little more involved and using ENIGMA

In the past we have made a few attempts at advertising ENIGMA in order to try and gain a greater following and increase ENIGMA user activity. These attempts were however not that successful and only managed to attract a couple of users here. Having read back through some of the feedback from these attempts I noticed 2 key responses: firstly that a lot of people just wanted to see the core system worked on further, and lots of bugs needed to be ironed out - this we are always working on and things will naturally continue to keep improving; and secondly that people wanted to see examples of what ENIGMA is capable of.

We are already in a much better position than we were before because we now have the EDC where a number of examples have already been posted but I am hoping that with the help of people here some more great examples and hopefully even full games could be made which showcase ENIGMA's full capabilities. The aim is to have compiled .exes of working games and examples that will be put into a zip and then this zip can be distributed whenever ENIGMA is advertised in the future as a showcase of what it's capable of (the next serious attempt at advertising will likely come after JDI is finished and ironed out). I feel like ENIGMA is a great, free piece of software that more people would benefit from finding and using, if you feel the same way and you want to help spread the ENIGMA word then I hope you will join us in creating some work for this showcase project

A notice for those on Windows that have updated after 3/Dec/2013 or anybody who hasn't updated before then and does so in the future: you will likely need to delete some files to prevent bugs/errors from occurring. It was changed by cheeseboy so generated files are now put into %APPDATA%/ENIGMA instead of SHELL, but in order to stop conflicts you now need to delete any generated files that you already have in ENIGMASystem/SHELL. The files to delete in ENIGMASystem/SHELL are the following:

API_Switchboard.h, enigma_blank, enigma_compile, enigma_defines, enigma_searchdirs, Preprocessor_Environment_Editable (delete the folder) and .eobjs (delete the folder).

This is topic where list main problems and what features you want seeing ins ENIGMA/LGM.

Put them in two separate lists: PROBLEMS then FEATURES and order in priorities.

Might as well make a proper topic about the Windows zip and ENIGMA.exe, can say what features you want to see and how it should be implemented and also maybe collect all the problems people are having with it here in one place from now on.

There's always endless warnings that crop up when compiling. I think as developers we should have a new mandate that instead of ignoring them we should resolve them whenever we see one instead of just always ignoring them. This is the only way I think they will get weeded out of the source.

Well a while ago Josh reluctantly agreed to allow me to add this in to ENIGMA after a lot of persuading and I've only just re-remembered and got round to it.

What I've done is add a map as a 'fallback' for when you reference an instance variable that's not declared in the object struct. This means you can for example now work with this code:

Code Select Expand

//(in say obj_0):

obj_1.foo = 5;
obj_1.buffer = 99;
show_message(string(obj_1.foo));

In ENIGMA if you don't use the variable foo anywhere in the object obj_1 then the variable will not have been declared. So in ENIGMA when you try to reference the foo variable for an obj_1 instance, there is no object member variable to access. Before ENIGMA was just assigning to a dummy variable, so that code would have shown 99 (as that was the last variable referenced). But with my change it will now add a map of the value 5 to "foo" local to the obj_1 instance, so you can reference to it properly as you would with any normal variable. Like I said this is like a fallback backup for when people don't declare variables in an object like they should do and it's obviously a lot less efficient so you should still always try to declare your variables properly.

You will find that this will improve the compatibility with Game Maker games quite a lot, I was constantly running into this incompatibility with games I tested. But I've not exactly tested much, so I'm posting here in case anybody can see any problems this winds up causing.

Hey can I get some feedback please if anybody else is experiencing this issue?
https://github.com/enigma-dev/enigma-dev/issues/165

I think this probably deserves an announcement so people know. Last night we added a condition so if the room_speed is set greater than 170 then Sleep is not called between frames (ie the fps is uncapped). When I tried this however I noticed a huge drag occurring, whereby blank games where still only running at 250fps. After a long debugging session it was found that the room caption setting was the single culprit (it was getting called liked 15 times a step and it's a rather bloated Windows function - not good). I have now removed the room caption temporarily (until it's sorted tomorrow) and after I removed it I found my fps shot up to an expected 1600fps in an uncapped blank room.

To summarize: this thing was a huge inefficiency so after you update, depending on your game, you might suddenly notice a large increase to your fps counter.

Cheeseboy has created an all-in-one zip file for Windows. It includes git and mingw along with Windows dependencies. You can download it here:
Windows Zip Installer.exe  (55MB)

The file is a self-extracting 7z. Once the file is extracted you click ENIGMA.exe inside the extracted folder to run ENIGMA/LGM. The first time it is run it will do an automatic git checkout, and patch in the dependencies before running LGM.

Many people have been complaining that the installation is too hard and hopefully this should go towards resolving this. It also gives users an easy way to update now without knowing git, this can be done by opening git-bash and typing: update. Developers should also be able to commit/push from this as well if they wish to use this set-up instead (I haven't tested this though). Another benefit is that it's now implemented correctly with a newer gcc so Windows Widgets are working again.

At this point we're looking for people to test it to make sure it is working correctly for everyone, then I will add it to the download page as an alternative to a standard git install.

[using]

In response to a suggestion that Josh has been throwing around for a while I would like to start a topic about this so it can be further discussed. I for one would like to see it happen.

These are some previous quotes from the Christmas plan topic about it:

Also, who among you is interested in the idea of encapsulating EDL types and functions in their own namespace? It would make it easier to deal with noise from library implementations, but it would require putting lots of shit into that namespace and using lots of shit from STDC.

In other words, we'd no longer have problems with time or list being illegal variable names unless the user specifically said, [snip=EDL]using std::list;[/snip] or [snip=EDL]using namespace std;[/snip], which I intend to unify between all viable backends (meaning, in JavaScript as well).

The new parser is much, much more adept at making these distinctions, so I can probably get it to allow using types and shit as variable names (especially in compatibility mode), but this would be a fix-all.

Encapsulation of EDL types and functions would be nice, especially if it solves the problems with "time" and "list" being used as variable names. How easy would it be to set up the system such that EDL types and functions can reside in both the global namespace and the EDL namespace? If it is easy, I would like the system to be set up that way, since that should enable easy step-wise migration.

Simple as placing "using namespace <name here>;" in the global scope. Just like you would any other namespace. I'll set ENIGMA up to read from :: or ::edlwhatever based on a macro. After everything's migrated, or we think everything's migrated, you'll just flip that flag and try compiling.

Harri, can you add in the functions surface_destroy (which is missing) and path_get_position?

Yay options panel

JUST TO CAP IT ALL OFF

[main]

Well after the upgrade I would like to bring this topic up.

It seems there is not a direct goal set or aim for the project at the moment. People are just randomly implementing bits & pieces wherever, which does progress things yes but I think you'll find if things are more directed progress happens much quicker and is much more noticeable. When you have a set goal it also greatly increases the motivation for doing tasks that are less appealing and people as such put off, by just doing bits & pieces these will never get done because there is no direct reason to and they will always be put to last but if it is necessary to do them in order to reach a goal then they will more likely be done.

Previously you had a goal set to get a stable first release out which seemed like a good goal but then it got drifted away from. So I ask exactly is the main aim at the moment which you want for the project?

• A stable release?
  
• GM compatibility?
  
• To annoy YYG's or prove them or the gmc wrong about something?
  
• A bigger user base?
  
• More developers?
  
• More games created?
  
• Or something else?
  

After you work that out you can set individual goals and actually work in parts directly towards achieving this. Doing a wish-wash of things and bits & pieces is not the best way to make things happen.

ps. yes this topic is largely directed towards you josh :p and it may go against how you naturally work but if you have a clear aim I think other people are more likely to help work around that also. I am interested to hear what other people are looking to get out of the project though.

There has been a lot of discussion on this but I have not seen an actual topic in place to get a full spec for it. A compatibility resolver should ideally check for any possibility incompatibilities in a file that may have been inherited from a GM file then offer the user a convenient way to resolve them, so the ease of transition from GM files to ENIGMA is quick and simple.

The questions then that need to be answered are:

• When should the resolver will be run?

• What things should the resolver check for?

• How will the resolver check for them?

• How will the resolver solve these issues and how should the user interface for it work?

Just wanted to open a discussion about trackers because I question if the current set-up really the best we can come up with?

Currently things are being posted in multiple places: the enigma tracker, lgm tracker, wiki, docs, forum, irc. This clearly isn't the best way to keep things organised. Any sort of bug tracking system should preferably be all in one place, easily accessible to users, convenient and easy to use, easy for developers to see which problems relate to them and easy to filter so people know what problems exist in which areas.

So I'm opening the floor to suggestions and to see if we can come to some sort of consensus of what should be used.

OK I've done all of GM's data structures now. I haven't fully tested all of the functions so let me know if anything doesn't work, doesn't mimic GM's behaviour or of course can be made more efficient.

There is a small incompatibility from GM that when a data structure is destroyed in GM it leaves a gap in the index value (this is replicated), but then when GM creates a new data structure afterwards it fills in the gaps of the indexes (which has not been replicated because it seems retarded). This shouldn't cause any problems though unless people are calling data structure indexes as literals or something.

And there is a also slight incompatibility with ds_queues when you have multiple priorities of the same value. The way I have handled it, it will always return the lowest value with multiple the priorities the same. The way GM handles it, is it returns the value which was first added to the priority queue. This should unlikely cause any issues though as you shouldn't be setting priorities the same anyway.

Anyway code posted on pastebin (because I'm way over the forum character limit): http://pastebin.com/earWGw8Z

I've recently been witnessing the benefits of using the wiki as far as organisation goes. I'm wondering if we should set up a system so people can post all their resource projects there such as examples, tutorials, engines, DLLs, graphics, sounds. They will then all be nicely categorised and serve as a place for hosting.

[globalvar]

globalvar to global var macro needed. Already known just referencing.


Tracker Reference:
http://enigma-dev.org/tracker/ticket.php?id=91

[Tracker Reference:]

xprevious / yprevious should be changed whenever an instance's x / y variable is changed.


Tracker Reference:
http://enigma-dev.org/tracker/ticket.php?id=88

[Tracker Reference:]

propogate_locals is current called at the start of each instance's step event. However for compatibility a separate pass should be made for this after the step event.


Tracker Reference:
http://enigma-dev.org/tracker/ticket.php?id=87

Parenting events is currently not implemented.

Code (C++) Select Expand

void move_wrap(bool hor, bool vert, double margin)
{
  enigma::object_planar* const inst = ((enigma::object_planar*)enigma::instance_event_iterator->inst);
  if (hor)
  {
    const double wdis = room_width + margin*2;
    if (inst->x < -margin)
    {
      inst->x += wdis*ceil(((-margin) - inst->x)/wdis);
    }
    if (inst->x > room_width + margin)
    {
      inst->x -= wdis*ceil((inst->x - (room_width + margin))/wdis);
    }
  }
  if (vert)
  {
    const double hdis = room_height + margin*2;
    if (inst->y < -margin)
    {
      inst->y += hdis*ceil(((-margin) - inst->y)/hdis);
    }
    if (inst->y > room_height + margin)
    {
      inst->y -= hdis*ceil((inst->y - (room_height + margin))/hdis);
    }
  }
}