Contributing to ENIGMA => Developing ENIGMA => Topic started by: Josh @ Dreamland on September 20, 2014, 03:22:29 pm

Title: Change
Post by: Josh @ Dreamland on September 20, 2014, 03:22:29 pm
While it seems that the massive changes that were flooding in over the summer have wound down (to a degree), I am still skeptical of this, and so I am changing my compiler-related plans to accommodate all the contributions that rolled in over the summer, as well as any new ones.

There are a couple changes I started rolling out in the other compiler branch that are becoming harder and harder to merge in as changes continue to be made upstream.

I was in the process of gutting the extension system and the relevant compiler chunks to try to splice in a hook system (see my notes on the Wiki from years ago) when I realized that the warnings I corrected in the compiler were starting to trickle back in, and that (on a very related note) Robert made an absolute war zone of write_object_data.cpp trying to add support for inheritance. I stepped back to address that, and realized that the best move is for me to make all of my non-parser compiler changes in master and naively hope that they propagate painlessly, which has been the development policy for a while, now.

In other words, gentlemen, it's Josh's turn to break things carelessly. I know it isn't ideal, but I've been too reserved about these changes in the past. I have merged enigma-dev/#819 (https://github.com/enigma-dev/enigma-dev/pull/819) after its (minor) review, as it seems not to seriously break anything important. If I can get you guys to stay on top of my future pull requests, we can probably make it through this next week without anything serious failing. I will exercise the maximum amount of diligence possible given our lack of a regression test suite, which I will probably begin to set up while I'm at it (see my current implementation here (https://github.com/enigma-dev/EnigmaFileFunctions/tree/master/test)).

You will see my first commit sometime tonight or tomorrow. It will do three things, listed here in order of increasing impact:
The purpose of the move is so we don't have contention on globals in the event that we need to run two compiles or two parses. This is less important than the smaller, more-intricate move which will be made in the commit after that one, which will move all logic involving interaction with the parse system into helper functions. This includes the following:
The connecting factor, of course, is that the parser is somehow involved in all of those operations. The connecting symptom is that ENIGMA sucks at all of those operations. The reason for this move, therefore, is to make it so that once this is all said and done, the new parser will be a drop-in replacement for the old. My original approach was to do the replacement in a branch where I would not have to touch the old logic, but that's just not going to cut it for the reasons I've already hinted at.

I am going to finish mincing write_object_data.cpp, now.

TL;DR: Keep an eye out for my future pull requests. Please check them for breaking changes as they roll out.
Title: Re: Change
Post by: Josh @ Dreamland on September 20, 2014, 10:17:53 pm
I cannot believe how ugly this file was. Robert, did inheriting stacked events (key press, mouse button, etc) even work? Or would overriding them cause a compile error? Or both events to fire? This is literally the ugliest ball of for loops I've seen in my entire life. I can't believe it achieves a desired effect.
Title: Re: Change
Post by: TheExDeus on September 21, 2014, 07:51:51 am
The don't read the ENIGMA engine's code, because that thing has turned into a monster as well. :D Because all we cared about was features and bugfixes, not how pretty it all was. But many things got rewritten to be more readable.
Title: Re: Change
Post by: Darkstar2 on September 21, 2014, 12:06:37 pm
The don't read the ENIGMA engine's code, because that thing has turned into a monster as well. :D Because all we cared about was features and bugfixes, not how pretty it all was. But many things got rewritten to be more readable.

Well, I'm sure YoYoGames had the same reaction when they took over (and later destroyed) GameMaker, and to be honest I don't see them re-writing anything from scratch anytime soon, they already have GMS 2 on board and ready for next year.  So don't feel bad.  A complete re-write of ENIGMA would probably take insane amount of time and unrealistic, but hey, OpenSource project, with multiple contributors, that's to be expected no?

Title: Re: Change
Post by: Josh @ Dreamland on September 21, 2014, 01:28:29 pm
The first chunk is out for review now at enigma-dev/#825 (https://github.com/enigma-dev/enigma-dev/pull/825). If you have anything to test that with, please do so (and feel free to give me some files to keep handy for testing).
Title: Re: Change
Post by: Goombert on September 21, 2014, 07:01:23 pm
Iji should be built and I'll leave that to sorlok.

Josh you could build Project Mario for me as it uses inheritance. I have massive changes going on here that I need to test as well and I cba atm.

But also I would like to refute what Harri has said, the code has gotten a lot cleaner in a lot of ways directly related to me, such as the introduction of general headers we lost a lot of unnecessary duplicate code. A good example is that a lot of general drawing functions are written using the GML functions, which is obviously easier to understand and change ever for novices and that was one of my arguing factors in doing so. screen_redraw was one getting pretty bad though until Josh cleaned it up a bit. But I will say audio is a complete fucking mess, and that is not so much the fault of the inexperienced first time contributor that I was when I got here than it is YYG's constant implementation and deprecation of audio_* functions it's impossible to pick a version of their shit and implement it and expect it not to change. While additionally also having to retain all of the original sound_* functions our audio system is a mess.
Title: Re: Change
Post by: Josh @ Dreamland on October 26, 2014, 11:39:56 am
Since my refactor broke inheritance, it was not pulled. Rather than attempt to fix it, I'm going to go for broke and rewrite inheritance the way it was supposed to be written. This will likely take longer than just today.
Title: Re: Change
Post by: Goombert on October 26, 2014, 12:20:05 pm
As sorry as I am for not helping I think that is the best decision Josh. Because I venture you'll be able to fix a couple of the inheritance bugs while you are it, I am in favor of your rewrite. I am trying to work ahead in school and get some classes finished early so I can start break early, namely IST I finished today.