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

Announcements / Removing Glew from the Repository
« on: May 12, 2018, 07:48:47 pm »
Fair warning, I'm about to remove glew from the repository and from now on it will be obtained via your package manager like the rest of ENIGMA's dependencies.

Josh felt it appropriate to warn everybody, and I agree. If you update to master now you will need to have glew installed:

Quote from: Ubuntu apt-get Glew
sudo apt-get install libglew-dev
Quote from: Arch Pacman Glew
pacman -Sy glew
Quote from: MSYS2 Pacman Glew
pacman -Sy mingw-w64-x86_64-glew
Quote from: Mac Brew Glew
brew install glew

This is important because ENIGMA should not distribute its dependencies this way. For one, they are not our code and distort the code coverage, and second they end up getting really old and crufty (like the current glew) which also leads to security vulnerabilities.

Finished Games / Re: Key to Success
« on: May 12, 2018, 06:46:16 pm »
Quote from: time-killer-games
noticeable flash of a "black screen"
I'm sorry I did not notice that before, so in general I'd say both are fast. I don't know what is causing the black screen (I can reproduce this/do notice it now that you pointed it out) but that should definitely be looked into, I have a feeling it may not occur if you were to set the Direct3D9 graphics system (but I think you may have already done that, I forget). I'm just guessing here that it's a vertical synchronization issue with OpenGL. Can't comment on which is actually faster, just because there's a black screen doesn't necessarily mean ENIGMA is slower, GMS is just keeping the last frame showing while blocking during the next room load (my guess). I can't say until we have additional benchmarking and performance querying capabilities. Regardless, I think both are fast.

Quote from: time-killer-games
None of the enemies or obstacles that can kill you are able to do so from where you are standing at the beginning of each level, so I'm not sure what you mean here either.
Sorry, I wrote this early in the morning, so my thoughts were all over the place. I wasn't making a direct connection between the two start levels just in how your levels seem to use the same approach. Once you get past the first obstacle, the rest are a lot easier. The first obstacle is typically the "key" to figuring out how to do one of your entire levels.

Quote from: time-killer-games
All that was very nice of you.
You're absolutely welcome. Just a little reward for everyone here that has supported ENIGMA. Also, in general, it's nice to let the community share the spotlight since everybody here plays a role in ENIGMA's success to some degree.

That said, I did not put it on ENIGMA's Twitter yet, is that also something you'd be interested? I just like to have relevant things to share with the Twitter followers from time to time and this is a good example. Let me know.

Works in Progress / Re: Pacman for Linux demo
« on: May 12, 2018, 06:35:57 pm »
Hey Hugar! The game is looking really good, and I did mention to you I felt the playback in your YouTube video seemed really smooth. I can't actually test it because I'm on Windows and I don't have easy access to Linux right now (my VM instance is totally fubar). Regardless, I'll gladly test it if/when you do get that Windows version out.

In regards to some issues you were facing, I'm going to go test some stuff right now in regards to the xstart and let you know. Keep up the good work (Y)

Announcements / Re: RadialGM
« on: May 12, 2018, 06:10:01 am »
Hey BPze! The issue I closed I hope I did so in good faith because I will get around to those missing events, just trying to organize all the open issues. A lot of issues being closed have actually been resolved, some by GCC themselves, some by us, and some didn't have enough info to go on.

Quote from: BPzeBanshee
This work on not only a new IDE but a consistent and stable way of using ENIGMA sounds promising
I really hope so, what I've been trying to express to people is that this time will be different not just because we're all more experienced programmers. We have this down to a science now thanks to continuous integration where we can verifiably fix bugs and create a test that, like I've been saying, makes sure they never come back.

Quote from: BPzeBanshee
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.
I agree, and we're still thinking about this problem, but the new setup I am using is MSYS2 based. So, what we want to shoot for will probably be something a lot like MAME. I am actually glad you linked that because I've actually already looked at it for this haha. But most importantly Java won't be required unless you want LGM over RGM, that's clear already.

Quote from: BPzeBanshee
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,
I know that this is a hard one for people to grasp at first, but it doesn't mean it won't be possible. It just happens that it won't be easy to export back to GMX because we have, for example, no need to use proto options to distinguish which fields are nodes and which ones are attributes. In order to write GMXs, we would actually need that kind of field description. In other words, the writers are much uglier than the readers (but I will tell people how to create/code them if they want to do so). However, I may not allow them or protest if somebody tries putting them into the ENIGMA main repo.

This hits right at the central idea of RadialGM, the fact that it's an "ENIGMA" IDE and not a "GameMaker" one. Doing this does simplify a lot, and not just the readers, but also the complexity of the UI. For LateralGM to do what it did, it had to have a UI option for everything every GM format ever supported (and that kind of makes its UI ugly).

Quote from: BPzeBanshee
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.
I can understand these reservations due to my own mishandling of the lgmplugin in the past. But the idea is to make the format totally complete from the very beginning and only rarely needing changed. When it does happen to need changed, the protos make that easier because they are automatically backwards compatible and binary compatible with ENIGMA itself (hence no need to update a plugin or jar file). Also, we will ofc have an EGM project in the CI testing this time around to make sure silly stuff doesn't happen. Finally, it's not limiting the export actions as I described, just limiting the save function (I am conceptually making a distinction between exporting and saving here).

Quote from: BPzeBanshee
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.
This one is a bit of a tough question I don't necessarily want to answer just yet. I want to say it's unlikely because the protos themselves as well as libEGM (which loads GMK etc) resides in ENIGMA's main repo. The reason is because emake itself depends on it and we use emake to test ENIGMA from Travis/AppVeyor to prevent it from breaking. So the protos again, pretty much "belong" to ENIGMA and ENIGMA now actually understands what a GM project is. Hold that thought for a second, when I consider this myself, in retrospect it seems really insane that previously ENIGMA didn't understand any GM projects when it itself is a GM augmentation.

Quote from: BPzeBanshee
extra components to slot in from Dropbox links.
Yeah, there won't be any dropbox links unless you go the LGM route. And we'll probably submit an actual ENIGMA/RadialGM combo package to the MSYS2 maintainers.

I hope that answers most of your questions and gives you a little more insight into the thinking behind this/the justification for these decisions. For the most part, all of this will be worked out in time, and I definitely hope you get a chance to test this thing (Y)

Finished Games / Re: Key to Success
« on: May 07, 2018, 03:15:03 am »
I want to take a minute to comment on your game, since I've tried it on different occasions since you started.

I've made it very clear in the past, that I am not typically a fan of platformers, it just never really was my genre. But I found your game entertaining for a specific reason. At first, I found it very difficult, so what kept me engaged was just trying to get some of the first couple of jumps right. I think the reason is because this is a little similar to what was done in the original Super Mario Brothers (how a Goomba is spawned to walk directly at you on the first level). After you do get the first couple of jumps, you can get through a level more consistently. But despite that, the challenges you've added to various levels keep the game challenging the whole way through. It's nice to see that you added a few additional levels for the completed version, it feels like a "full" game now. We may have differing opinions on the difficulty level, but I do feel the difficulty progression is consistent within each level because each level sort of has a unique combination/pattern (ironic that I feel this way and they game is called Key to Success; which I find appropriate) to get right before you can beat it.

Overall, I really like the quality of the game, the playback is smooth, the art is appealing, and the audio really creates the right tone. The only feedback I have is that I think there should possibly be some sound effects for dying/level restarting (though I am really impressed with how quickly the levels restart). I am also super glad that the game plays so well in ENIGMA in comparison to GM and I feel it's a sure sign of progress on the community's part.

Nice job, that's all there really is to say about this one, you got to me to genuinely enjoy a game from a genre I don't typically engage with (Y)

Thanks to Game Theory on YouTube, every time I see Pacman now I think of FNAF, very eerie. Regardless, it's looking good hpg678, the playback seems to be real smooth. I actually took a class in the history of game developments and just to mention that in particular Pacman was a game that stood out to me. I was not aware of the different strategies used by the Ghosts and when I told my mom she actually knew more about it than I did because it was her favorite arcade game way back in the day! Just an example of something that really challenged my perception because most of my life I was used to experiencing the exact opposite. Looking forward to seeing more examples from you!

Announcements / Re: RadialGM
« on: May 06, 2018, 08:34:56 am »
As I've been saying from the beginning, it needs investigated more, but it's definitely something I want to look into, a native binary installer. You just can't make an installer before you actually make the IDE, hence, we'll get to it when it becomes important. The only people actually needing to set it up right now are those working on it, and for that, the MSYS2 installation works very well and much better than our old solutions (due to the package management).

Announcements / Re: RadialGM
« on: May 06, 2018, 12:28:22 am »
I had not actually heard of that game before, but you can't blame me too much because C64 wasn't my generation, N64 was :P

Regardless, that's really interesting. I don't think I've studied much into maze generation, but one thing I was always interested in was world generation (think Dwarf Fortress). I was always into doing that for both 2D and 3D because it always seemed less linear to me, and I don't know, I've always had a bias against linear games (but not against 2D).

And yes, I happen to agree with you as well, video games are always the cutting edge of computer science, there's always something interesting going on. There's AI, 3D, 2D, art, modeling, sound recording, music synthesis, plain old programming, networking, data structures, and everything else. I must say I've experienced what you describe about a thread with writing this new IDE on several occasions. Sometimes you get stuck on how you want to do something and after thinking about it for a while, it will "just click" and you suddenly know exactly how you want to do it.

But no, don't worry about being a little offtopic, a lot of what you are saying is relevant to where we're going with ENIGMA and a new IDE too.

Announcements / Re: RadialGM
« on: May 04, 2018, 04:28:05 pm »
Quote from: egofree
Last year i worked in my free time with Unity to create another remake, but now i've less time.
Do you mean like a game remake or another thing or like how ENIGMA is a remake of GM (really it's an augmentation... not a remake)?

Quote from: egofree
Anyway Enigma will always stay dear to my heart, so from time to time i visit enigma's website.
Thanks dude, you were always really nice and helpful here as a contributor. Please do come back too because I do foresee this thing becoming stable and I hope you'll be around for the beta. I honestly can't predict much right now, but I've been pretty consistent about sticking to an end-of-summer deadline to get a beta out.

Quote from: time-killer-games
When it is released, will there be a standalone available for each release, or will everyone be forced to compile it from the source code themselves?
I'm sorry, thanks for clarifying. I can't say just yet, but yes I would like to see a real installer for ENIGMA, but we have to look into how to make that possible with msys2. The setup will certainly be a lot easier. I have to look more into the technical details and also wait and see because there are other things I want to do. But yes, definitely would like to see easier installation.

Announcements / Re: RadialGM
« on: May 04, 2018, 06:00:52 am »
Hey egofree! I'm glad you caught wind, how have you been?

Back on topic, and in regards to your question:
I want to clarify to everyone right now, this announcement is purely to get everyone informed. I'm not actually looking for testers yet (but privately I will give the directions if requested) - there will be more announcements to come (and very soon too!).

There's just so many technicalities we felt it best not to spring it all on everyone at once.

Announcements / RadialGM
« on: May 03, 2018, 08:36:30 pm »

Ok, so I've been hinting around and letting some of you know for a while that a few of us have been redesigning the architecture of ENIGMA to support a new IDE. Some of you may be more familiar with it as I know I've let a handful of people test out the new tools, but I'm here to break it down and try to explain it in more detail for everybody.


I want to start off by enumerating the current things ENIGMA was doing that are somewhat insane. When I started contributing to LateralGM, GM HTML5 was a brand new thing and there was really only the GMK format to support. This went well for a time, as many of you know, and we were able to add features as YoYoGames did without too much of a thought-out serialization framework in place. We had experimented with making a new IDE, just for the sake of making a new IDE (not as much because one was needed). Working on LateralGM, I tended to continue with the mindset that it was a "GameMaker" IDE and we should try to add compatibility for everything which is now not only a difficult task but next to impossible. Because LateralGM and ENIGMA communicated using C structs with JNA through compileEGMf.dll, they would not be binary compatible if we added new fields and other metadata. Overtime, Oracle has become an even worse company attempting to undo decades of legal precedent with regards to software engineering, Java, and specifically OpenJDK, hasn't made fast enough progress, and I just want to make games.

Architecture Changes

So I experimented with using Google Protocol Buffers as a serialization for projects. I was also adding things here and there to emake.exe as fundies asked me to. He was working with Josh to get our CI tests setup to prevent regressions in the engine and everything (which I must say are doing wonders for this project). fundies expanded the protocol format to basically load GMXs completely and then I tacked on GMK, have YYP semi-working, and him and Josh are currently working on EGM saving. These formats are all being handled in libEGM which is a new C++ library built on top of libProtocols.

The plan is to have libEGM only ever read the GM formats but save and read our official serialization format (*.egm). The CI tests will make use of libEGM to load and compile a test project from every version of GM back to GM5. You can actually examine this right now on GitHub because the Protocol Buffers PR is already running these tests:


Using the new protocols I was able to experiment with making RadialGM actually functional (since because of the architectural changes much of the work was already done).

As you can see, we've made a lot of progress. I am really satisfied with the results so far, and personally, I want to make games myself using the new IDE and that's why I've been working on it so much. What's so great about all of this though, is not just that RadialGM is actually possible, but the architectural changes really do make every other IDE as equally likely to work out (though for various reasons, I've decided to focus my efforts on the Qt version; simply because I personally like it the most). However, you should consider RadialGM to be more of an "ENIGMA" IDE as it will be almost purely for ENIGMA editing.

What You Can Expect

* It is unlikely that I will be making any more changes to LateralGM.
* The C-based backend/ in ENIGMA will remain but may be rewritten to convert to the protos (instead of the inverse) for the foreseeable future. It will likely be deleted if someone decides to rewrite the ENIGMA-LGM plugin to use the protos instead of the C backend (but that's much more work than converting the backend into protos).
* You can expect to be able to load all GM formats back to GM5 (*.gmd, *.gm6, *.gmk, *.gm81, *.gmx, *.yyp, *.egm).
* 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.
* You can expect the IDE to make more optimal use of your system's resources for the above reasons (primarily because resource data is lazy-loaded and reference counted in the frontends).

Issues Help Desk / Re: Array accessors in Enigma?
« on: May 02, 2018, 04:14:44 pm »
I've sent the fix to GitHub:

Also, since this topic was originally about the special array/ds accessors, please take a look at how I responded to the request on GitHub the other day:

Basically, we don't have them now, but we may later add real accessors (for data structures and things other than array), and then make the GMS syntax simply not a syntax error (just unnecessary). But don't expect it too soon, we're working on a new IDE.

You may encounter other small anomalies like this, as we don't have nearly as many developers as GM, but otherwise letting us know about them helps! Thanks!

Issues Help Desk / Re: Array accessors in Enigma?
« on: May 01, 2018, 06:03:55 pm »
Ok, I see, I think I've figured it out, and it looks like this performance issue has been here since they were originally written.

Can you try something out for me? In your ENIGMA setup, I want you to close everything and navigate to [snip]enigma-dev/ENIGMAsystem/SHELL/Universal_System/Extensions/DataStructures/data_structures.cpp[/snip] and go to line 1218 where [snip]ds_list_replace[/snip] is defined. Comment out the erase/insert lines and put this:
Code: (cpp) [Select]
  //replaces the value at pos with the val in the list
  if (pos < ds_lists[id].size())
    //ds_lists[id].erase(ds_lists[id].begin() + pos);
    //ds_lists[id].insert(ds_lists[id].begin() + pos, val);
    ds_lists[id][pos] = val;

Then save that file and reopen your game and try to build it. Then the performance should be normal. I'm giving you these steps because I believe the performance decrease is the result of erasing elements at positions other than the end. When you do this, as our API is, to a C++ vector then it can cause a reallocation and moving of the entire rest of the list:

Quote from: on std::vector::erase
Because vectors use an array as their underlying storage, erasing elements in positions other than the vector end causes the container to relocate all the elements after the segment erased to their new positions. This is generally an inefficient operation compared to the one performed for the same operation by other kinds of sequence containers (such as list or forward_list).

I hope that fixes it, and if it does, let me know so I can make up a pull request and send this to master to get it in there for everybody.

Issues Help Desk / Re: Array accessors in Enigma?
« on: April 30, 2018, 06:54:50 pm »
Hi Wacyym! I am not the one who wrote data structures, but I will attempt to help here. Theoretically, there should actually be little to no performance difference between lists and arrays if you are only replacing values (I say this with the possibility that there is a bug in ENIGMA, in which case it should be fixed). Only resizing a list should have a performance difference in comparison to arrays, and it should actually be more efficient because lists attempt to amortize their allocation complexity by doubling their sizes instead of just "making room for one more" as arrays typically do. DS Lists in ENIGMA are internally backed by std::vector from the C++ Standard Template Library.

Can you show us some more code? Such as other code that is in the step or create events. I am specifically interested to know where you are calling [snip]ds_list_create[/snip] because that would kill the performance if you were calling it in the step event and not deleting the old list from the last step. If you are going to reuse the list, then you should simply create it in the create event and keep reusing it, not recreating it (because the memory allocation for the list will kill the performance).

Tips, Tutorials, Examples / Re: Old GM projects working in LINUX
« on: April 29, 2018, 03:07:12 pm »
Thank you so much. Good news, libEGM seems to be loading it well in both formats in the new IDE using the protobufs we wrote underneath. However, I spotted one problem. If you look at the screenshots I've attached to this post, it seems the gm6 version may have a bug, because in the gm6 some of the objects are turning into Game Info resources after the "stone_solid" object. This does not occur with the GMX version you provided.

However, I also attempted opening the project in GM8.1 and the objects appear as [snip]<undefined>[/snip] in the project tree. Can I ask what program you used to save this GM6?