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 »
I cannot find any recent changes that should affect the instance system. cheeseboy, is the error reproducible, and if so, could you provide the source and instructions for how to reproduce it?

I am currently fixing a couple of issues, but the integration testing branch should be ready for merging into master. I have tested that a test report can be generated on both Linux and Windows. I have also created a new version of the plugin based on the current plugin source, which contains the changes needed to run the tests. It can be found here: Note that it has been built for Java 1.6, and that it can only be used together with the latest LGM1.8 by Robert.

Robert: I made it work by using the LGM1.8 jar instead of the repository's source for the LGM library.

Josh: Yes, a server is needed for running Jenkins ( on. I don't currently have a server set up myself, so if you are interested in handling that aspect, it would be very nice. My (somewhat limited) experience is that once Jenkins itself has been set up, most things can be handled through its GUI, including installing plugins for it and setting the plugins up. It has a Git plugin and a GitHub plugin (instructions for getting it to pull automatically from GitHub when a new commit has been made can be found here:, and it comes built-in with a system for handling test results.

In regards to setting it up with the integration tests, the tests should be run as the last step of building (using the command [snip]python3 integration_tests/[/snip]). To publish the test results, a post-build action must be used to retrieve the test results. While it expects the results to be in a JUnit test result report format, the current testing system supports that format, and reports in that format are automatically generated in "integration_tests/output_temporary/testreport_jenkins.xml" whenever tests are run.

General ENIGMA / Re: Frustum Culling and View Hashing
« on: August 08, 2013, 04:39:05 pm »
I investigated similar data structures some time ago when I looked into broad-phase collision detection. A variation of k-d trees ( could be a possibility for tiles. k-d trees are normally just for points, but it is possible to modify them to support bounding boxes, meaning that you could skip the distance check that you would need for the quad tree. While I recall they are relatively expensive to create and modify, meaning quad trees would likely be a better solution for moving objects, you rarely need to modify tiles, and they should have decent performance for querying areas of tiles (especially tiles that have regular sizes and are spread out in somewhat uniform density). That said, I don't know how much of a speed up it would provide, unless the room with tiles is very, very large relative to the view, in which case I think it could be well worth it.

As for collision detection, I think they can easily be worth it, given that the number of collision can be quadratic in the number of instances (if you have two about equally large groups of instances where the groups collide with each other), and a k-d tree should in most cases reduce the number of collision from O(N^2) to O(N*log(N)) or something similar.

Announcements / Re: XInput, Gamepads, and Windows Joysticks
« on: August 08, 2013, 04:06:16 pm »
In regards to the image, it seems like a modified version from someone describing how to set up an X-box controller on Linux to play Cave Story ( If it turns out to be a problem, we can always take it down and replace it with another image. YoYoGames are using a different image in any case.

In regards to the controller support, nicely done :).

General ENIGMA / Re: ENIGMA for classroom?
« on: August 08, 2013, 03:50:43 pm »
Josh: Yes, that is entirely possible, simply compiling, running and checking that they don't crash for a few seconds is currently supported (compilation error or crashing is detected and recorded as a test failure). However, it is somewhat bothersome to implement, given that each game file would have to be modified somewhat. Given that it would be nice to do this for many other game files as well, I think it would make sense to support compilation + running without any modification to the game files to be tested. Implementing that shouldn't be difficult, though I expect it to be a while before I come around to it.

TheExDeus: Running the tests manually is just a temporary option until we get them automated. Since it is somewhat bothersome to run the tests every time, I don't personally expect anyone to run them manually as well (though they would be welcome to).
In regards to the end-goal, the idea is indeed to have them fully automated. One way to do that would be to have multiple development branches like Josh previously proposed; developers commit new changes to the testing branch, the tests are run automatically for each tests and the results reported online, and if it looks good, the changes are then ported to the master branch (where building and testing is likewise done).
The nice thing about this is that automated building + testing is relatively easy to set up with a continuous integration system. I looked into using Jenkins for it, and it seems that it is really easy to get Jenkins to automatically detect whenever any changes have happened to a branch in a GitHub repository, and then build + run all tests and report the results (just install the GitHub plugin for it and configure it in the dashboard). Some of the nice things about the automated testing in Jenkins is that it shows an overview over tests, how many commits it is since a failed test first failed, and graphs over the count of failed/passed tests from build to build. Here is the Jenkins dashboard for one of Apache's Hadoop build tasks:

Robert: That sucks, I hope it gets sorted out soon. I might be able to build it some other way, don't worry about it too much.

Yes, having it up and running would be very nice. While I can run the tests locally, others can not, and they aren't run automatically or tracked by a continuous integration system. That said, once I have built the plugin from source and replace the current version of the plugin, it will be really easy for others to run the tests: Simply switch branches to integration_tests, and run the command [snip]python3 integration_tests/[/snip]. Then open the file integration_tests/output_temporary/testreport.html and look through the tests to see what succeeded and what failed. There are currently 8 tests of varying scope and size, including tests I created for bugs I have fixed, as well as bugs that have not yet been fixed.

General ENIGMA / Re: ENIGMA for classroom?
« on: August 04, 2013, 03:57:24 pm »
2) In my opinion, ENIGMA is not quite there in regards to deployment, reliability and stability, especially for computer novices (which I get the impression your users are, given that you will introduce them to Office and the like). While we are slowly improving those issues*, I think it will be at least half a year or a year before ENIGMA gets to a level where its stability is acceptable for use by computer novices. That said, if the odd bug and the challenge of getting ENIGMA set up is not an issue, ENIGMA can definitely be used to create games with.

(*we are continually doing general improvements and bug fixes, and we are currently working on getting automated regression testing up and running, which should help quality and stability considerably over time).

Proposals / Re: Vertex color
« on: July 29, 2013, 06:04:57 pm »
I like the solution where it draws the same as GM as long as only one of d3d_model_vertex and d3d_model_vertex_color is used. For those cases where the functions are mixed, I think it is fine if we deviate from GM in regards to how it is drawn, as long as it does not crash and we document on the wiki that we don't give any guarantees about the drawing if d3d_model_vertex and d3d_model_vertex_color are mixed. Mixing color and non-color is IMO tricky and unintuitive, and I believe the vast majority of usage do not mix the two functions.

Off-Topic / Re: YoYoGames Compiler for 300$
« on: July 29, 2013, 05:33:43 pm »
On the thread talking about the GMC forums, it seems that they had an open beta for a long period before they announced the price for the compiler. Another issue they talked about is the lack of upgrade options for those who bought versions of GM:Studio on Steam: The upgrade discount options that customers who bought directly from YoYoGames have, aren't available to those customers who bought over Steam. This is partially explained by the decreased price of the products due to sales on Steam, but some of the users on Steam bought the products for the full price, and they are not offered the upgrade discounts.

Combined with the other issues (the pirate sprite overwriting, selling of unsupported software like GM4Mac without informing potential buyers that it is unsupported, etc.), it seems clear to me that YoYoGames' business model does not rely on building a good reputation amongst its customers. I don't know if that will work out for them in the long run. I get the impression that they are relying on two things: the momentum that Game Maker helped build over the years, as well as using the lack of real alternatives to squeeze money out of their customer base - GM is still a very good product, and people will likely bite the bullet if they don't have other options.

Of course, this business model just helps ENIGMA. I think the turning point will come when two things happens: ENIGMA becomes easy, reliable and stable enough for most users, and we get close to feature parity on important areas with GM. We have all worked hard on the latter point, and I think continuous integration and automated regression testing will be the missing piece of the puzzle to fix the former point.

Very nice, having DirectX set up and working will make further development on it much easier. While it in principle ought to be enough to be able to use OpenGL, that may not be the best solution on Windows for a given game, and supporting DirectX will give them the choice of which graphics system to use. While it may be an extra burden, it can be expanded upon bit by bit, and with a future test suite over the graphics, all the tests that we write for the OpenGL graphics systems can be reused for DirectX, and vice versa, given that the interface for using the graphics system is the same between implementations.

In regards to the issues with approximate results, I think using wide bounds checking for most cases instead of checking for precise values will be a decent solution. While the test will not detect small deviations, using wide bounds should avoid any false positives, and we still get a lot of the advantages of testing it, including if it compiles. For those cases where we can figure out how to do precise checking without any false positives, we of course ought to do that. I agree that things like data structures and strings should work very well.

It would also be very nice if we could get the installer for Windows to be automatically created as part of the continuous integration. For instance, we could set up a job that creates a new installer once a week/when we request it, with the latest commit which built successfully.

On a side-note, the testing system depends on the latest version of the plugin, which has not been built and uploaded yet. As far as I can tell, I cannot do that by myself at the moment, unless I modify the to load package information from another place. So, I would like to kindly request that it is built and uploaded :).

General ENIGMA / Re: Overuse of the CPU ?
« on: July 27, 2013, 06:00:32 am »
Ah, ok, that's probably it. Then the change will probably help avoid any future issues.

Thanks, I am happy to help :).

Josh, that reminds me of another thing I have thought about: I think the automated regression testing would work really well together with the idea you previously proposed about having multiple branches here. By doing that, development could go like this: Developing stuff, commit the stuff to the testing branch, wait for the tests on the testing branch to finish running on multiple platforms by the continuous integration system, check that there are no regressions, and merge the changes into master. That way, it would require almost no work to run all tests on multiple platforms before committing to master. What do you think?

General ENIGMA / Re: Overuse of the CPU ?
« on: July 27, 2013, 03:45:49 am »
Hey egofree, I have pushed a change which may fix the issue. Could you test with the new version and see if it solves the issue?

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