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

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 »
121
Announcements / Re: Trello
« on: January 29, 2013, 02:53:17 PM »
I'm horribly sorry, I will be more careful in the future. They have been added in the latest commit. I only just saw it myself when I made the latest commit.

122
Announcements / Re: Trello
« on: January 26, 2013, 01:22:30 PM »
I have implemented and tested the changes, and submitted a pull request. I think the solution with the ASTOperator is decent, especially given that classes and inheritance are used for representing the abstract syntax tree. I have decided to let AST members stay public, since as you say the probability of someone using them outside the ASTOperator is minimal.

123
Announcements / Re: Trello
« on: January 26, 2013, 08:46:03 AM »
Yes, forthevin is the right account. In regards to committing, I have decided to make the change in a fork and then make a pull request, just to keep things cleaner.

In regards to the current parser and abstract syntax tree, I have indeed spent some time looking at it and learning from it. Using classes and inheritance instead of unions and enums to represent abstract syntax trees in C++ can be a good idea, but I must admit that I prefer tagged unions when the language used provides support for them (which C++ does not). I don't like that (Const)ASTOperator and AST_Node are so tightly coupled, but the way you have set them up should ensure that they are decoupled in practice, which is pretty neat.

There are still some changes required; in my work so far, I found out that the "friend" concept does not extend to subclasses. So, when AST_Node declares that it is a friend of (Const)ASTOperator, that does not include the children of (Const)ASTOperator, and so children of (Const)ASTOperator cannot access anything in AST_Node. So far, I have handled that issue by declaring everything in AST_Node "public" instead of "protected".

What kind of operations do you have in mind should be performed on the abstract syntax tree (apart from printing EDL to C++ and javascript)?

I don't have much in terms of plans regarding what to work on after the first to-do, but I believe that I will work towards finishing up the particle systems. It works pretty well at the moment, but there are some non-core functionality that is still missing, such as effects, attractors, changers, destroyers and deflectors, and emitters are not fully implemented yet.

124
Announcements / Re: Trello
« on: January 25, 2013, 05:28:38 PM »
Just posting to say that I would like to be added on Trello, and that I plan to do the first to-do point on the parser.

125
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.

126
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.

127
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?

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 python install.py? 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.

128
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

129
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.

130
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.

131
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.

132
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.

133
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.

134
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 enigma::update_globals(); in IDE_EDIT_events.h.

135
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

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 »