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 - IsmAvatar

Developing ENIGMA / Re: New properties in egm files
« on: August 25, 2014, 11:50:43 am »
"Manifest" was probably the wrong word. I meant something similar to a Jar's manifest file - it is a file in the main directory that provides information about the archive (not the TOC). Maybe we don't have one. I don't recall. It's been a while since I've touched an EGM file.

Point is, the actual EGM format should never really change, since it's so modular. If it ever does, it would be a different format, so would probably warrant a new extension. All that changes are the internal resource formats, which have their own readers for handling that.

Also, I was looking through the code, and I saw that we do have a RoomEefWriter/Reader (as an alternative to the RoomGmDataWriter/Reader), it's just not hooked in because it was experimantal. Again, the intent is to eventually switch to something like that, so if you want, go ahead and thoroughly review that code to make sure it doesn't have any logic errors, and feel free to switch over to it and try it out.

I haven't worked on the project in a long time, but we discussed all this stuff back in the day, so I thought I'd give my two cents on what we determined:

1) Windows phone compilation support - I can then make games for my phone, lol.
This is feasible. We've worked on iOS and android support. Windows phone would be the next step, but I think just getting iOS and android working again would be a higher priority, since they are easier.
2) Program compatibility with Windows phone - I want to work on my projects portably (Not desperate for this.)
This is unlikely. Even though LateralGM is written in Java, so technically it could work on any platform, it is targeted as a desktop application, with full mouse and keyboard support required. There are drag gestures and key-mouse combos and special key (like ctrl) frequently depended on throughout the application. If you want to develop on the go, get a laptop.
3) Multi-user online editing - I want to get my dev team working on this project, but it kinda makes it difficult that we have to pass the file around   
    over skype. (Again, I can just about cope without this)
This is planned. As Onpon said, the solution is to use a SCM (version control), such as Git. The issue that GM faces is that their file format is binary, which does not version/diff well; it works best with textual files. Fortunately, here at ENIGMA Corp, we've been researching and investigating textual technologies, and have come up with a few solutions. First and foremest, we have the EGM format (currently alpha). This format is designed to store every resource in its own textual file, called an E-Yaml file, with any data that is necessarily binary (such as images) stored separately. However, EGM is designed to get compressed, which just converts all the data back into binary again, but we have designed an uncompressed version so that you can use version control. Additionally, there was a project call LgmScm, which was a plugin for LateralGM the would port your code into an SCM-friendly format and add basic SCM integration (independent of whichever SCM system you chose). I don't recall whatever happened to it, but I'm sure it will get looked at again once EGM is more stable.
4) Improvement to Game Maker project compatability - Seriously, there are too many functions that I can't use on Enigma that I used to frequently
    use on Game Maker (Eg: execute_file) (I am aware I can implement Lua into Enigma somehow to solve this, but I'm too lazy to read the   
    instructions all the way through)
So, the big hurdle here is that execute_file requires something able to parse and interpret said file and inject that code into the game. This is an issue because unlike GameMaker, ENIGMA is compiled, not interpreted. We convert your internal game code into C++ code and then send it off to the C++ compiler (gcc), once and done. This requires a full suite of tools installed on the developer's machine - mainly gcc. We can't expect players to have gcc, because they're not developers, and gcc is huge, so we can't just ship it with the game.
Fortunately, here at ENIGMA Corp, we've been researching and investigating interprative technologies, and have come up with a few solutions. First and foremost, I think we have some sort of fancy Javascript engine that Josh wrote that can apparently read and interpret GM code, since it's mostly Javascript friendly, and can then pass that back to the game for integration. Josh can probably tell you more, or there might be a doc for it or something somewhere, or someone else might know more.
5) Fixed GEX support, or atleast implement it. (I see the feature is "there", but it doesn't function. Are you going to implement it, or not, lol.)
The issue with GEX is that it's often used for packaging a DLL with your game. DLLs are windows only. They are not cross-platform. Linux uses .SO files, and mac has I think a DYLIB. None of these formats are compatible (and for good reasons, since they often directly access things in the OS). We can workaround this a little bit by packaging a version for each in your GEX (so it will have all 3 - a dll, a so, and a dylib), which is more or less the plan. It'll still restrict the oparating systems that can play your game, or at least that can use the GEX extensions (so you may not be able to play your game at all on most mobile devices if it has a GEX), but it's better than no DLL support at all. It's also quite possible that we'll create our own GEX-like format, since GEX is property of GM, and if we had our own we could do more with it.

Anyways, thanks for the suggestions. They are great reminders to continue working on these side things that are often outside the scope of the main codebase.

Developing ENIGMA / Re: New properties in egm files
« on: August 25, 2014, 09:05:33 am »
The binary format was intended to be temporary, and was the reason that the EGM format never left alpha. As long as it remains binary, it should definitely be versioned. If it isn't versioned already, that was definitely an oversight. The goal is to switch all resources towards E-Yaml.
Since EGM has always been alpha, it's perfectly acceptable to abandon support of the old version and add the properties to the new version, however I would also strongly encourage you to add versioning while you're in there too. If there are people with important files on the old versions, someone could write a converter to convert files to the new version. For example, a very simple converter would be to just custom-build an LGM with both the old Room Reader and the new Room Reader, and only the new Room Writer. They would simply make a backup, open the file in this custom LGM, and then re-save the file.

In EGM, versioning is intended to be done on a resource-by-resource basis. If there was a global version number for the EGM, it should be in the manifest file, and would virtually never changes since the EGM format is designed to be as modular and final as possible. One of the only changes I would see that would warrant changing the version number outside of the manifest would be if we switched away from E-Yaml.

Programming Help / Re: Color values in GM
« on: August 15, 2014, 09:09:07 am »
If we have to, we could re-invent the algorithm based on how we see it. It won't be the most elegant thing, but if it gets the job done, we only need to run it when the alpha channel is actually used.

General ENIGMA / Re: Rooms editor 'hidden' secrets
« on: July 30, 2014, 11:27:39 am »
Be careful with that "painting", you're not actually just painting the object, you're creating a whole bunch of instances, each with the same logic as the object. So if you "paint" with an interactive object, you're actually creating dozens of interactive instances - which could behave strange or slow down game processing. Instead, if you just want to paint a bunch of them, just create 1 of them and use the Draw event to draw a bunch of them. It won't show up in the room editor, but the room editor is intended for manipulating instances, not images.

Also, I've updated you to have the Contributor Membergroup.

General ENIGMA / Re: New functions available in the rooms editor.
« on: July 30, 2014, 10:25:02 am »
The message should read something more like:
"Are you sure you want to delete all instances in this room? This operation cannot be undone."

Instance is the official term and a well-defined concept in LateralGM; it even has its own wiki page:

"in this room" is an important qualifier, to not confuse the user as to what scope of instances will be deleted - will it delete all instances in the entire project or just the instances in this room - we must clarify.

"All data will be lost" is a horrible sentence to use here. It conveys nothing more than the first sentence, and does not imply that the operation can't be undone. It is also scary - ALL data?! Throughout the entire project?! Say what you mean, and be clear about it. "This operation cannot be undone."

Punctuation is a little important as well. We should avoid contractions like "can't" (prefer "cannot" or "can not"), and remember to terminate sentences with a period.

Also, remember to send the string through Messages.getString so that it gets translated.

As pointed out, we should also be translating "<no objects>", although that may be a challenge to translate since "objects" should be independently translated.

Edit: I have committed this change. Also, it appears that "<no objects>" already has a translation key; not sure why French didn't translate it.

Developing ENIGMA / Re: JavaFX
« on: February 09, 2014, 11:53:52 am »
That doesn't seem unreasonable. That said, LateralGM, as a name brand, is and always will be intended to support different GM versions and make them as compatible as possible. It's in its name.  If you decide to fork and drop GM6/GMK support, I think it would be wise to adopt a new name as well, so we can keep LGM as legacy. Naturally, LGM (and I) would endorse your new product as the desirable game development IDE. To that end, hopefully LGM would serve as a useful tool in converting older games into the newer formats that you would support, such as EGM.

Developing ENIGMA / Re: JavaFX
« on: February 09, 2014, 10:43:16 am »
1 would it be possible to simply do a version check before using the functions? We used to do this for some of the more advanced swing features and it worked great. This way you can maintain java6 support without incurring a big dependency, and display a warning of reduced functionality to encourage people to either update or download a jar.
2 if it can't be done directly in lgm, maybe a plugin could pull it off.
3 why are we dropping gmk support? The reader and writer work great and it's the latest version gm people can use without switching to studio. And what about gm6?

Developing ENIGMA / Re: Optimized GMX Loading
« on: February 06, 2014, 09:50:11 am »
I am not against ENIGMA natively supporting reading EGMs. From my point of view, ENIGMA is and always has been intended as independent from any IDE, and having a single input format that allows it to run standalone should be a goal. The fact that this could potentially ease the strain on communicating information from the IDE to ENIGMA is a bonus. I think if there's any single main reason this was delayed, it was because EGM was never formally finalized (since LGM was the testing ground and I never really finished with it).

what do you specifically think of delaying the loading of each resource to the first time it is accessed?
I'm in favor of it. It was one of the main selling points of EGM. Much of the modularization of LGM has been towards that end, so hopefully you will at least find hooking it up to be fairly straightforward. Unfortunately there are a large number of aspects of the interface that were never designed with such a use case in mind, so we will run into unexpected bugs that will need to be figured out and kinked out - the resource preview icons being the most obvious (and we were making plans on how to handle that). Less obvious things will be resource references, such as the Room editor being essentially useless without all the dependent objects, sprites, and backgrounds loading unless you can resolve some sort of independent render storage system - which is pretty silly since loading the renders of those things is the bulk of the loading time - the rest is small data. And finally, and perhaps most significantly, this will alter the "Save" concept, which pretty much nothing supports changing this, so I expect it will fight you the whole way.

Developing ENIGMA / Re: Optimized GMX Loading
« on: February 05, 2014, 01:56:56 pm »
Notice h is before offset and shift and not after w?
The properties are alphabetized. c h o s w x y

ENIGMA's compiler does not presently support any formats natively, including EGM. LGM has all the resource readers/writers, so from the get-go, we just let LGM do that work for us. However, formatting the data into C-friendly structures is apparently an insurmountable task for the JVM. Possibly due to the fact that Java has the opposite endianness.

It hasn't always been this way. We've dabbled with a few options, eventually having LGM export the data to a file, and calling ENIGMA as an EXE - simply because I couldn't figure out how to get dlls to work in Java (using our own format, EGF, I think, so CLI still wasn't a viable option C-side only). It wasn't until I finally broke down and agreed on a JNA dependency that we were able to do what seemed more natural. Unfortunately, as Josh pointed out, transferring data this way is still a struggle on the JVM.
Sorry for skimming - I might be repeating what you already said, but what you might consider doing is some kind of hybrid where ENIGMA has a native EGM format, and ENIGMA itself will load any unloaded resources from file - while the loaded resources will be passed over through JNA->C-structures. This could further be optimized by only keeping track of which resources are changed, so LGM doesn't have to populate structures for unchanged resources. While we're doing this, as Josh suggested, we might even consider not bothering passing the more binary resources, and rather keep them in the EGM - especially if ENIGMA is just going to turn around and write them to a file anyways - it's better if we save the overhead of JNA->C-structures for binary data (which are, measurably and unarguably, the biggest cycle offender) and just write it to the file ourselves.

Developing ENIGMA / Re: YAML Settings Update
« on: January 26, 2014, 10:54:50 pm »
I thought we already had some sort of defaulting and prioritization system. Or is this something else?

General ENIGMA / Re: DevOps
« on: January 16, 2014, 11:17:36 pm »
I mainly want to retort IsmAvatar in that I do not agree with full blown unmonitored contributions
Not sure what unmonitored contributions I allowed when I was active on the project. Or did you mean another word other than "retort"?
Actually I feel I followed the extreme opposite of that, which I now think is precisely why LGM stagnated in both developers and development -- because every commit had to be reviewed by myself.

General ENIGMA / Re: LateralGM endorsed to Robert B Colton
« on: January 08, 2014, 07:49:45 pm »
Ask away, but again, the question you asked before is more of a Josh question, and if he can't answer it, just use your best judgement and/or refactoring it would be a sufficient solution.

General ENIGMA / Re: LateralGM endorsed to Robert B Colton
« on: January 04, 2014, 04:12:39 pm »
Yes, that's what I was thinking as well. Similar to plugin dependency, plugins can identify other plugins to take higher or lower priority over. A pretty elegant solution whenever we get to that point in development.

General ENIGMA / Re: LateralGM endorsed to Robert B Colton
« on: January 03, 2014, 05:03:09 pm »
Plugin Priority was an idea I toyed with, but I couldn't think of a way to implement it in an agnostic way. Either LGM already knows about the plugins that it can have, and assigns them priorities, or else plugins choose their own priorities. In the latter case, we depend on plugin developers giving their plugin an "honest" priority, and they need to have some sort of concept of scale - while a high priority plugin like Enigma may be a 1, what is a low priority plugin? 5? 100? 31415? Then there comes the fun job of priority fine-tuning - one plugin chose priority 4, and another one chose 5, and now another plugin wants to come in right in the middle...
Then there's the issue of how to handle priority. Does a higher priority plugin get loaded first or last? If he gets handled first, then all the lower priority plugins can overwrite everything he did. Of course, a possible workaround for this is for plugins to not trample when they do something - so e.g. check if something is already set before going ahead and setting it up themselves.