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.
121
Proposals / Proposals for implementing ASTOperator for EDL_AST
« on: January 20, 2013, 10:53:21 am »
I have looked at the To Do for "Create ASTOperator class for EDL_AST" for the parser at Trello, and have come up with some ways that it may be implemented. I don't see a straight-forward way to do it, since the operator class and the AST nodes in JDI are tightly coupled - the operate method refers directly to ASTOperator/ConstASTOperator, and the ASTOperator/ConstASTOperator have methods specific to each node. The most straight-forward way I can think of would be to make a new class, maybe EDL_ASTOperator, and let it inherit from ASTOperator. The problem with this is that the AST nodes in JDI can only call ASTOperator, not EDL_ASTOperator. I haven't found any solution which is generally good.
I have therefore come up with a couple of different suggestions on how the problem may be tackled:
1: Simply put more methods into ASTOperator and call it a day. The advantage of this method is that it is very easy and should work without any problems in the short-term. The disadvantage is that it makes JDI dependent on EDL, and it seems like JDI is meant to be an independent project separate from EDL.
2: Introduce constant values for each node type, and let operators on the nodes simply cast to the given node type based on the constant values. The advantage is that it would decouple the nodes and the operators, and shouldn't take much time to implement. The disadvantage is that it would make more boilerplate code necessary in the operators, and that it would throw type-safety away.
3: Use a template in the AST for which operator type to use. The advantage is that it would decouple the nodes and the operators like 2, and it would keep type-safety. The disadvantage is that it seems non-trivial, it would take considerably more time than the other options, and both the non-operator parts and the general use of ASTs would be affected.
I have therefore come up with a couple of different suggestions on how the problem may be tackled:
1: Simply put more methods into ASTOperator and call it a day. The advantage of this method is that it is very easy and should work without any problems in the short-term. The disadvantage is that it makes JDI dependent on EDL, and it seems like JDI is meant to be an independent project separate from EDL.
2: Introduce constant values for each node type, and let operators on the nodes simply cast to the given node type based on the constant values. The advantage is that it would decouple the nodes and the operators, and shouldn't take much time to implement. The disadvantage is that it would make more boilerplate code necessary in the operators, and that it would throw type-safety away.
3: Use a template in the AST for which operator type to use. The advantage is that it would decouple the nodes and the operators like 2, and it would keep type-safety. The disadvantage is that it seems non-trivial, it would take considerably more time than the other options, and both the non-operator parts and the general use of ASTs would be affected.
122
Issues Help Desk / Re: Hi there, I am new to ENIGMA
« on: January 20, 2013, 03:33:40 am »
I tried to compile your example code, and it worked when compiling for the target "GNU GCC G++", but when compiling for the target "Android Simulator", I got the same error as you got. Compilation for Android is currently experimental. Can you confirm that it works when compiling for "GNU GCC G++"? If so, I believe you have everything set up correctly.
The JRE crash that you got before that with the first .gm81, were you compiling for the target "GNU GCC G++"? If yes, it sounds like the issue is caused by the specific file you loaded into LateralGM, possibly something to do with rooms based off the error text from the JRE.
The JRE crash that you got before that with the first .gm81, were you compiling for the target "GNU GCC G++"? If yes, it sounds like the issue is caused by the specific file you loaded into LateralGM, possibly something to do with rooms based off the error text from the JRE.
123
Issues Help Desk / Re: Hi there, I am new to ENIGMA
« on: January 19, 2013, 05:00:46 am »
Does running the following commands work?
Else, try to follow Josh's instructions. You wrote that install.py did not do much. Did you run it like [snip]python install.py[/snip]? If not, that could be the cause of it not doing anything, including downloading lgm16b4.jar. I also think that install.py downloads plugins/shared/jna.jar, which fits with JNA missing being the problem.
Code: [Select]
sudo su
apt-get install git build-essential default-jre freeglut3-dev zlib1g-dev libalure-dev libdumb1-dev libvorbis-dev
exit
mkdir Enigma
cd Enigma
git clone https://github.com/enigma-dev/enigma-dev.git
cd enigma-dev
python install.py
make
java -jar lgm16b4.jar
Else, try to follow Josh's instructions. You wrote that install.py did not do much. Did you run it like [snip]python install.py[/snip]? If not, that could be the cause of it not doing anything, including downloading lgm16b4.jar. I also think that install.py downloads plugins/shared/jna.jar, which fits with JNA missing being the problem.
124
Issues Help Desk / Re: Help please, I can't run 'make' in enigma
« on: January 13, 2013, 08:00:52 am »
Do you have "make" installed? If not, and you are on Mac, try following the instructions in the second answer and its comments in this thread:
http://stackoverflow.com/questions/6767481/where-can-i-find-make-program-for-mac-os-x-lion
http://stackoverflow.com/questions/6767481/where-can-i-find-make-program-for-mac-os-x-lion
125
Function Peer Review / Re: Windows callback
« on: January 12, 2013, 10:24:16 am »
I have committed a fix for Linux and included your fix for Windows.
126
Announcements / Re: Christmas Plans
« on: January 05, 2013, 04:02:10 pm »
A couple of thoughts and comments:
First off, spending 90% of one's waking time on something sounds less than healthy. Wouldn't it make more sense to postpone the new parser and compiler if it takes unexpectedly more time? ENIGMA seems to work pretty well at the moment, so I have trouble seeing the hurry.
Second off, I am happy to announce that the particle systems system is coming along well. Several examples work now, including the fireworks example from the manual (http://gamemaker.info/en/manual/412_08_example), as well as a nice fire effect example I found (http://blog.martincrownover.com/gamemaker-examples-tutorials/particle-example-fire/). There is still a lot missing, including effects, changers, destroyers, deflectors and attractors, but the system is quite usable at the moment.
Third off, ENIGMA has been very functional for quite a while, and I would therefore like to propose that a forum is created, named Works in Progress, where games in development can be shown and talked about.
First off, spending 90% of one's waking time on something sounds less than healthy. Wouldn't it make more sense to postpone the new parser and compiler if it takes unexpectedly more time? ENIGMA seems to work pretty well at the moment, so I have trouble seeing the hurry.
Second off, I am happy to announce that the particle systems system is coming along well. Several examples work now, including the fireworks example from the manual (http://gamemaker.info/en/manual/412_08_example), as well as a nice fire effect example I found (http://blog.martincrownover.com/gamemaker-examples-tutorials/particle-example-fire/). There is still a lot missing, including effects, changers, destroyers, deflectors and attractors, but the system is quite usable at the moment.
Third off, ENIGMA has been very functional for quite a while, and I would therefore like to propose that a forum is created, named Works in Progress, where games in development can be shown and talked about.
127
Announcements / Re: Christmas Plans
« on: December 28, 2012, 09:18:04 pm »
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.
128
Proposals / Re: Automatic updating for particle systems
« on: December 06, 2012, 08:13:51 pm »
If there is no difference in work required, I would prefer "Code", but "Instead" is fine as well.
129
Proposals / Re: Automatic updating for particle systems
« on: December 06, 2012, 04:48:22 pm »
I hadn't thought about generating the sprites. I have taken a look at the sprites, and I think that good approximations can be generated for each of them.
Regarding "default", it did indeed not insert the event without it.
Regarding "default", it did indeed not insert the event without it.
130
Proposals / Re: Automatic updating for particle systems
« on: December 06, 2012, 02:45:21 pm »
Cool, I will keep the current implementation. There is one other thing that I would like to implement before pushing to master, namely including built-in sprites for the particle systems.
In regards to events and formats, I see both a localsweep event and several calls between events to [snip]enigma::update_globals();[/snip] in IDE_EDIT_events.h.
In regards to events and formats, I see both a localsweep event and several calls between events to [snip]enigma::update_globals();[/snip] in IDE_EDIT_events.h.
131
General ENIGMA / Gamasutra article on GameMaker's recent DRM problems
« on: December 06, 2012, 01:45:48 pm »
I found an article on gamasutra.com regarding GameMaker's recent DRM problems, where non-pirated versions of Studio permanently overwrote images and sprites with a skull and crossbones image. There are also some interesting comments, including people who buy Studio and then use a pirated version because they find the pirated version more convenient:
http://www.gamasutra.com/view/news/182558/GameMaker_DRM_goes_berserk_defaces_dev_work.php#.UMDl49GYNok
http://www.gamasutra.com/view/news/182558/GameMaker_DRM_goes_berserk_defaces_dev_work.php#.UMDl49GYNok
132
Proposals / Automatic updating for particle systems
« on: December 06, 2012, 01:35:34 pm »
I have implemented a very basic version of particle systems, which can be seen in this fork: https://github.com/forthevin/enigma-dev. Recently, I have worked with implementing automatic updating of particle systems. In GameMaker, particle systems can be either updated automatically (the default setting), or updated by hand. I have determined that GameMaker updates the particle systems between the end-step events and the draw events.
The issue is now that updates and changes in GameMaker generally happens as part of instances and their events, and not outside them. This is reflected in ENIGMA's handling of events, since function calls (as far as I can tell) cannot be put directly in between events. Since particle systems are independent of instances and their events, they are an exception to the rule. Therefore, updating particle systems between the end-step event and the draw event seems non-trivial, since only events can be updated between events.
I have found two solutions to the problem. The first is to create a hacky event, that does not go through instances, but just calls a single function. It could look like this in event.res:
The above code would be placed in between the end-step and draw events. This code solves the issue. The only thing of notice is that it also generates a superfluous virtual function in the object superclass. This solution is currently implemented in the fork and works.
The second solution I have found would be to extend the format of event.res, such that the format allows the above solution but without generating a superfluous virtual function in the object superclass.
My suggestion is now that the first solution is used as it is, while the second solution is postponed until further notice. Since the superfluous virtual function is never called, it shouldn't cause much (if any) overhead.
The issue is now that updates and changes in GameMaker generally happens as part of instances and their events, and not outside them. This is reflected in ENIGMA's handling of events, since function calls (as far as I can tell) cannot be put directly in between events. Since particle systems are independent of instances and their events, they are an exception to the rule. Therefore, updating particle systems between the end-step event and the draw event seems non-trivial, since only events can be updated between events.
I have found two solutions to the problem. The first is to create a hacky event, that does not go through instances, but just calls a single function. It could look like this in event.res:
Code: [Select]
particlesystemsupdate: 100000
Name: Particle Systems Update
Mode: None
Default: ;
Instead: enigma::update_particlesystems();
The above code would be placed in between the end-step and draw events. This code solves the issue. The only thing of notice is that it also generates a superfluous virtual function in the object superclass. This solution is currently implemented in the fork and works.
The second solution I have found would be to extend the format of event.res, such that the format allows the above solution but without generating a superfluous virtual function in the object superclass.
My suggestion is now that the first solution is used as it is, while the second solution is postponed until further notice. Since the superfluous virtual function is never called, it shouldn't cause much (if any) overhead.
133
Issues Help Desk / Re: Compiling without Java or at least trough commandline
« on: November 28, 2012, 11:05:42 am »
Running "java -jar enigma.jar [path-to-game]" in the plugins directory gave me errors, but running it in the main directory as in "java -jar plugins/enigma.jar [path-to-game]" caused it to compile the game and create an executable in the directory of "[path-to-game]".
134
Announcements / Re: Thanksgiving Holiday Updates
« on: November 26, 2012, 07:16:51 pm »
I have committed a patch that changes the return type to enigma::instance_t for those functions that return an instance id.
135
Announcements / Re: Commit Privileges
« on: November 26, 2012, 06:37:55 pm »
I still have the old fork that I can use, so it is not so bad.