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.
106
Proposals / Re: Games category
« on: February 21, 2013, 01:39:35 pm »
Thank you for creating the forum, this should be very useful for getting and providing feedback.
107
Proposals / Re: Games category
« on: February 21, 2013, 07:05:46 am »
In regards to what they should offer over the EDC, the EDC seems like a place where already created games, as well as examples, tutorials and engines, are placed. It is easy to browse through and has a standard format amongst other things. In many ways, it seems like a place well suited for static, completed and permanent content. Furthermore, if a user wants to play a nice game or look for a quality example, the EDC also provides a rating option.
EDC does not seem as suited to discuss works in progress as a "Works in Progress" forum would be, mostly because it is ordered (as least as far as I can tell) according to its submission date, not the latest comment, which means that works in progress with a lot of activity would not rise to the top of the listing. A forum for works in progress would be useful, because games can be presented, discussed and debugged, and if a work in progress does not work out, or the game is completed, or there is a period of inactivity, etc., then the work in progress thread will automatically go down from the first page of the forum.
As for the "Completed Games", the main difference from the EDC is that "Completed Games" would only have posts about newly created games, and games only, while the EDC contains games, examples, etc. that may have been created some time ago. But I suppose that this role is generally well handed by the EDC, especially given that EDC also provides a type to indicate whether it is a game, example, etc., and I presume that could be used to implement a filter to make it easier for users to browse and search through specific types.
While I will give you that "Completed Games" would likely not offer much over the EDC, I do believe that a "Works in Progress" forum is not covered well by the EDC (or any other part of the website) and would be very useful, especially in regards to getting and giving feedback on games.
In regards to promoting daydreaming on the forums, I am not quite certain I understand what you mean, but I am going to assume that you are talking about works in progress that have no working demos, or have no chance of getting completed, and the like. If so, I do see your point. Moderation could possibly be used, but that would only be partly effective, and take considerable amounts of work. What about having a "Open betas" forum instead of "Works in Progress"? That would clearly signal that the game should be in a very playable state and not far from completion, and it would still allow a lot of very useful feedback, even though the feedback in that forum would be limited to middle or late in the development of the game.
EDC does not seem as suited to discuss works in progress as a "Works in Progress" forum would be, mostly because it is ordered (as least as far as I can tell) according to its submission date, not the latest comment, which means that works in progress with a lot of activity would not rise to the top of the listing. A forum for works in progress would be useful, because games can be presented, discussed and debugged, and if a work in progress does not work out, or the game is completed, or there is a period of inactivity, etc., then the work in progress thread will automatically go down from the first page of the forum.
As for the "Completed Games", the main difference from the EDC is that "Completed Games" would only have posts about newly created games, and games only, while the EDC contains games, examples, etc. that may have been created some time ago. But I suppose that this role is generally well handed by the EDC, especially given that EDC also provides a type to indicate whether it is a game, example, etc., and I presume that could be used to implement a filter to make it easier for users to browse and search through specific types.
While I will give you that "Completed Games" would likely not offer much over the EDC, I do believe that a "Works in Progress" forum is not covered well by the EDC (or any other part of the website) and would be very useful, especially in regards to getting and giving feedback on games.
In regards to promoting daydreaming on the forums, I am not quite certain I understand what you mean, but I am going to assume that you are talking about works in progress that have no working demos, or have no chance of getting completed, and the like. If so, I do see your point. Moderation could possibly be used, but that would only be partly effective, and take considerable amounts of work. What about having a "Open betas" forum instead of "Works in Progress"? That would clearly signal that the game should be in a very playable state and not far from completion, and it would still allow a lot of very useful feedback, even though the feedback in that forum would be limited to middle or late in the development of the game.
108
Proposals / Games category
« on: February 20, 2013, 06:53:18 am »
I would like to propose that a new forum category is created, called "Games", with two forums "Completed Games" and "Works in Progress". The purpose of the "Completed Games" forum would be to show and discuss newly created games, and the purpose of the "Work in Progress" forum would be to show off works in progress and discuss them as they develop.
I believe these forums would be very useful to have for users, and that they supplement the Games section on the website. Furthermore, ENIGMA has been mature enough to make complex games in for a long while, so I think the time is right for adding these forums.
I believe these forums would be very useful to have for users, and that they supplement the Games section on the website. Furthermore, ENIGMA has been mature enough to make complex games in for a long while, so I think the time is right for adding these forums.
109
General ENIGMA / Re: The particle systems extension is complete
« on: February 11, 2013, 03:01:51 am »
Very cool.
110
General ENIGMA / Re: The particle systems extension is complete
« on: February 10, 2013, 01:55:41 pm »
Regarding GLES's GLSL, I have looked a bit into it. It is based on version 1.20 of GL's GLSL, and while similar, it is different enough to be its own language from GL's GLSL.
I also looked into unified shader languages. There does exist a unified shader language, Cg, which is developed and supported by Nvidia. Nvidia provides tools to convert from Cg to GLSL and HLSL. Notable users of Cg include the Unity engine and Irrlicht. Unity supports GLSL and Cg, while Irrlicht supports both GLSL, HLSL and Cg. I think the choice of shading language should be postponed until someone wants to use shaders. That said, Cg seems like a good candidate.
I would definitely like having your goals on the wiki.
As a side-question, have a Work in Progress forum been considered at any point? ENIGMA is not yet complete in terms of features, but it has been mature enough to make games in for some time.
I also looked into unified shader languages. There does exist a unified shader language, Cg, which is developed and supported by Nvidia. Nvidia provides tools to convert from Cg to GLSL and HLSL. Notable users of Cg include the Unity engine and Irrlicht. Unity supports GLSL and Cg, while Irrlicht supports both GLSL, HLSL and Cg. I think the choice of shading language should be postponed until someone wants to use shaders. That said, Cg seems like a good candidate.
I would definitely like having your goals on the wiki.
As a side-question, have a Work in Progress forum been considered at any point? ENIGMA is not yet complete in terms of features, but it has been mature enough to make games in for some time.
111
General ENIGMA / Re: The particle systems extension is complete
« on: February 10, 2013, 08:44:44 am »
A Particle_Systems directory is a good idea, given that it provides multiple options for users as you say. I originally didn't consider the possibility of using shader languages such as GLSL for implementing particle systems, which is why I decided on having a single particle systems implementation for all graphics systems.
For the design of the system, I think it would make sense if each particle system implementation can be restricted to specific graphics systems, such that a GLSL particle system implementation can only be used together with OpenGL and OpenGL ES graphics systems, and a HLSL particle system implementation can only be used together with a DirectX graphics system.
In regards to the use of attractors, destroyers, deflectors and changers, either restricting or removing them for certain particle systems implementations would make sense, given that YoYoGames have removed them in GameMaker:Studio, presumably because they themselves use a shader-based implementation for Studio.
As for the future, I don't have any plans currently, apart from fixing various issues, improving on things here and there, and implementing some more unimplemented functions.
For the design of the system, I think it would make sense if each particle system implementation can be restricted to specific graphics systems, such that a GLSL particle system implementation can only be used together with OpenGL and OpenGL ES graphics systems, and a HLSL particle system implementation can only be used together with a DirectX graphics system.
In regards to the use of attractors, destroyers, deflectors and changers, either restricting or removing them for certain particle systems implementations would make sense, given that YoYoGames have removed them in GameMaker:Studio, presumably because they themselves use a shader-based implementation for Studio.
As for the future, I don't have any plans currently, apart from fixing various issues, improving on things here and there, and implementing some more unimplemented functions.
112
General ENIGMA / The particle systems extension is complete
« on: February 09, 2013, 02:27:53 pm »
I am pleased to announce that the particle systems extension is complete. Turn it on under Enigma->Settings->Extensions->ParticleSystems in order to use it.
All particle and effect functions and actions have been implemented and tested. It includes attractors, destroyers, deflectors and changers.
The performance of the extension is near the level of GameMaker. It is able to update and draw 10.000 particles at 30 fps on my hardware with a quad-core processor and an Intel integrated graphics card. My latest profiling indicated that updating and drawing take about the same amount of time, with drawing taking slightly more, so optimizing either updating or drawing makes sense. As a side-note, the initial profiling and optimization made the drawing about 10x faster, since it turns out glPushAttrib can be pretty expensive inside a loop. Further profiling and optimization improved the performance slightly. The updating is fully single-threaded, though there are some parts of the updating which could be parallelized.
The particle systems extension is generally decoupled from the used graphics system. Most of the extension is fully separate from the graphics system used. The graphics-dependent parts are handled by requiring the used graphics system to implement a function to draw a vector of particle instances. The only coupling remaining in the particle systems extension is a few includes of OpenGL/GScolors.h, which only uses the non-drawing functions of the header.
All particle and effect functions and actions have been implemented and tested. It includes attractors, destroyers, deflectors and changers.
The performance of the extension is near the level of GameMaker. It is able to update and draw 10.000 particles at 30 fps on my hardware with a quad-core processor and an Intel integrated graphics card. My latest profiling indicated that updating and drawing take about the same amount of time, with drawing taking slightly more, so optimizing either updating or drawing makes sense. As a side-note, the initial profiling and optimization made the drawing about 10x faster, since it turns out glPushAttrib can be pretty expensive inside a loop. Further profiling and optimization improved the performance slightly. The updating is fully single-threaded, though there are some parts of the updating which could be parallelized.
The particle systems extension is generally decoupled from the used graphics system. Most of the extension is fully separate from the graphics system used. The graphics-dependent parts are handled by requiring the used graphics system to implement a function to draw a vector of particle instances. The only coupling remaining in the particle systems extension is a few includes of OpenGL/GScolors.h, which only uses the non-drawing functions of the header.
113
Announcements / Re: Iji
« on: February 05, 2013, 01:30:34 pm »
The OP of the thread did offer to help test an ENIGMA port of Iji, so that is something.
Nope, no idea about how to clone you.
Nope, no idea about how to clone you.
114
Announcements / Re: Iji
« on: February 04, 2013, 06:13:56 pm »
Sounds good.
Also, I followed TheExDeus' suggestion and posted on the thread informing them about ENIGMA and the possibility of using it to port Iji.
Also, I followed TheExDeus' suggestion and posted on the thread informing them about ENIGMA and the possibility of using it to port Iji.
115
Announcements / Re: Iji
« on: February 04, 2013, 03:22:10 pm »
First off, I found some sources for documentation on the YoYoGames wiki, they provide manuals for GM 5 and GM 6: http://wiki.yoyogames.com/index.php/Old_Game_Maker_Versions
Second off, using the provided list by making empty implementations in definitions.h, as well as some minor modifications (including redefining names like "pause", "rand", etc. through "#define", as well as changing a single "instance_destroy = 0" to "instance_destroy()"), I managed to make the compiler accept the file.
This uncovered some scaling issues. First, the parsing part of the game took a long time, even though it didn't take much memory or CPU usage. It seemed to pause or wait several times during the "Add dot accessed local" part of the process. Given that it didn't require much memory or CPU usage, I assume this part was IO-bound. It should be noted that I have a standard, slow hard disk. Maybe a computer using an SSD would do this part faster.
After this part, gcc began compiling. This part had high CPU usage, and the memory began spiking as well, with upwards of 1 GB of memory used. There was a lot of compilation errors, so I didn't get the game to run after the process. However, I thought this memory usage was quite high. I then looked at the file sizes in the preprocessor part.
The biggest file was IDE_EDIT_objectfunctionality.h, of size 13.4 MB. It is also 410691 lines long. Other big files included IDE_EDIT_roomarrays.h (4 MB) and IDE_EDIT_objectdeclarations.h (2 MB).
I guess the main conclusion of this is that Iji is definitely a massive game in terms of code, and that it is an excellent test case to test the scalability of ENIGMA's parsing and compilation. I don't think pursuing Iji and GM5 compatibility is worth it right now, but after the parser is done and has been tested with other games/test cases, I think Iji and GM5 would be an obvious goal to pursue.
Second off, using the provided list by making empty implementations in definitions.h, as well as some minor modifications (including redefining names like "pause", "rand", etc. through "#define", as well as changing a single "instance_destroy = 0" to "instance_destroy()"), I managed to make the compiler accept the file.
This uncovered some scaling issues. First, the parsing part of the game took a long time, even though it didn't take much memory or CPU usage. It seemed to pause or wait several times during the "Add dot accessed local" part of the process. Given that it didn't require much memory or CPU usage, I assume this part was IO-bound. It should be noted that I have a standard, slow hard disk. Maybe a computer using an SSD would do this part faster.
After this part, gcc began compiling. This part had high CPU usage, and the memory began spiking as well, with upwards of 1 GB of memory used. There was a lot of compilation errors, so I didn't get the game to run after the process. However, I thought this memory usage was quite high. I then looked at the file sizes in the preprocessor part.
The biggest file was IDE_EDIT_objectfunctionality.h, of size 13.4 MB. It is also 410691 lines long. Other big files included IDE_EDIT_roomarrays.h (4 MB) and IDE_EDIT_objectdeclarations.h (2 MB).
I guess the main conclusion of this is that Iji is definitely a massive game in terms of code, and that it is an excellent test case to test the scalability of ENIGMA's parsing and compilation. I don't think pursuing Iji and GM5 compatibility is worth it right now, but after the parser is done and has been tested with other games/test cases, I think Iji and GM5 would be an obvious goal to pursue.
116
Announcements / Re: Iji
« on: February 04, 2013, 06:18:53 am »
TheExDeus, the source can be found under the resources section on Daniel's website, in the first source/resource pack.
I think one major reason why they might want to use ENIGMA over GM is that ENIGMA can be customized or extended far more than GM. In the email in the linked thread, Daniel writes that there are large differences between how graphics and sound in GM5.3 and GM8 are handled, and some of these differences may be difficult or impossible to handle well if porting to GM8 (for instance, I tried compiling Iji in ENIGMA, and one function that is missing is screen_gamma. I know that it could be either implemented or simulated accurately in ENIGMA, but I don't know if the same is the case for GM8).
As far as I can see it, the best way they could use ENIGMA would be to fork it, and for some parts of the port of Iji to Mac and Linux, adapt the engine to Iji, and for other parts, adapt Iji to the engine, depending on what is the best choice for each part. Some of this effort wouldn't benefit ENIGMA directly, apart from showcasing how useful ENIGMA's ability to be customized or extended is. Other parts of the effort would benefit ENIGMA directly, since these parts would involve implementing functions that are currently missing or would be useful to the main fork of ENIGMA.
That said, I think this general idea - porting great GM games to Mac and Linux through ENIGMA - has a lot of potential. There are a number of great games which are made in GM6, GM7 or GM8, and getting these games running in ENIGMA should be much easier than getting games made in GM5 or earlier running. If some of the authors of these games are interested in having their games ported to other platforms, we could either help do it for them or help them with it, and porting these games would demonstrate what ENIGMA is capable of. I personally believe that the idea should be postponed until later, since ENIGMA is still missing some important features (built-in game saving/loading, full inheritance, custom events, etc.) that most or some of these games are likely to use, but it is still useful to keep in mind while ENIGMA progresses.
I think one major reason why they might want to use ENIGMA over GM is that ENIGMA can be customized or extended far more than GM. In the email in the linked thread, Daniel writes that there are large differences between how graphics and sound in GM5.3 and GM8 are handled, and some of these differences may be difficult or impossible to handle well if porting to GM8 (for instance, I tried compiling Iji in ENIGMA, and one function that is missing is screen_gamma. I know that it could be either implemented or simulated accurately in ENIGMA, but I don't know if the same is the case for GM8).
As far as I can see it, the best way they could use ENIGMA would be to fork it, and for some parts of the port of Iji to Mac and Linux, adapt the engine to Iji, and for other parts, adapt Iji to the engine, depending on what is the best choice for each part. Some of this effort wouldn't benefit ENIGMA directly, apart from showcasing how useful ENIGMA's ability to be customized or extended is. Other parts of the effort would benefit ENIGMA directly, since these parts would involve implementing functions that are currently missing or would be useful to the main fork of ENIGMA.
That said, I think this general idea - porting great GM games to Mac and Linux through ENIGMA - has a lot of potential. There are a number of great games which are made in GM6, GM7 or GM8, and getting these games running in ENIGMA should be much easier than getting games made in GM5 or earlier running. If some of the authors of these games are interested in having their games ported to other platforms, we could either help do it for them or help them with it, and porting these games would demonstrate what ENIGMA is capable of. I personally believe that the idea should be postponed until later, since ENIGMA is still missing some important features (built-in game saving/loading, full inheritance, custom events, etc.) that most or some of these games are likely to use, but it is still useful to keep in mind while ENIGMA progresses.
117
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.
118
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.
119
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.
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.
120
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.