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 »
Works in Progress / Re: [WIP] snake revenge :D
« on: February 27, 2013, 04:52:13 PM »
Nice WIP, early in its life but still playable. There is not much challenge in the game at the moment, though I assume that you are going to address that.

One thing I noticed is that the fruits are not aligned to the grid of the snake's movement. If you align the fruits to the grid of the snake's movement, it will be easier for the player to determine when the snake is going to collide with the fruit. In the LateralGM room editor, you can adjust how large the grid should be by adjusting the "W" and "H" fields. They are by default set to 16 by 16.

Off-Topic / Re: Windows blows egg water
« on: February 23, 2013, 11:28:37 AM »
It isn't that many years since there would often be one problem or another when setting a Linux system up, such as drivers and hardware, which often required users to use the command line to try and solve it, and search for solutions online just to get simple things working. For programmers, this was often not a large burden, but for regular users, it could be difficult or impossible to figure out what to do. The situation has become considerably better the last couple of years, especially due to the improved driver support, but also due to general progress in Linux desktop environments. I think Ubuntu is getting to the point where a regular user never needs to open a terminal ever or very, very rarely, which is close to the situation on Windows, where you also never or very, very rarely as a regular user have to open a terminal. Windows "just works" for regular users, and Ubuntu (and other distributions, to some degree) is getting close to have the same property. Ubuntu is probably one of the more pragmatic distributions out there, for instance in regards to the use of proprietary drivers.

Issues Help Desk / Re: ERROR: Unable to acces jarfile l*.jar
« on: February 22, 2013, 05:16:29 PM »
The errors are due to issues with "min" and "max", which are related to the parser and are going to be fixed in the future. In the meanwhile, copy-pasting the following code in LateralGM into Enigma->Definitions should fix the issues:

Code: [Select]

#define min internal_min
double min(double x1, double x2) {
return x1 < x2 ? x1 : x2;
double min(double x1, double x2, double x3, double x4) {
double xmin = x1;
xmin = xmin < x2 ? xmin : x2;
xmin = xmin < x3 ? xmin : x3;
xmin = xmin < x4 ? xmin : x4;
return xmin;
#define max internal_max
double max(double x1, double x2) {
return x1 > x2 ? x1 : x2;

Works in Progress / Rules
« on: February 21, 2013, 01:53:35 PM »
This forum is for discussion of game projects you are working on and share your games for everybody. Useful feedback includes bug reports, suggestions, praise and criticism of the game, with the purpose of helping make the game in question better. Please stay on topic here, we have other boards for posting bug reports including a tracker that is integrated into the website and an off topic forum.

Works in progress that are posted here should be generally playable and usable, somewhat bug-free, and be realistic in their scope. They do not have to be filled with content, but there should be some gameplay available, such that useful feedback can be given on the game. You should also read the universal board guidelines and rules as they are in effect site wide.

General Guidelines and Rules

* DO NOT post spam or post virus-infected downloads, or your account may be terminated.
* Prank games and programs are only allowed if very clearly labeled, with instructions for disabling the program.
* Keep feedback to constructive criticism: do not bash other members' games for unrelated personal matters.
* Try to limit the number of images you have in your topic; nobody likes taking 6 hours to load a page. There is no set limit; if moderators feel you have too many, they will inform you.
* Try to stay on topic and not hijack a members topic bragging about how many kills you got on Call of Duty last night. It is disrespectful to them, and we have an off topic forum for such discussion.

Posting Criteria

* Please include screenshots and images in your post. Other users may like to see these before they download. Consider DropBox, ImageShack, Tinypic, PostImage, ImageUpload, etc.
* Information regarding the download size of your game is also helpful for other members.
* Try to be concise without cutting out important details in your description. It is also nice to include information regarding the genre, and other specifics.

Rules by forthevin and Robert B. Colton.

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.

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.

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.

General ENIGMA / Re: The particle systems extension is complete
« on: February 11, 2013, 03:01:51 AM »
Very cool.

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.

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.

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.

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.

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.

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:

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.

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.

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