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.
46
Issues Help Desk / Re: Out of memory error while compiling
« on: May 30, 2013, 02:22:50 pm »
2 GB is far too much, cc1plus should not use nearly so much memory. It may be the same issue as when compiling Iji.
After trying to run on Windows, could you give us how many lines the file ENIGMAsystem/SHELL/Preprocessor_Environment_Editable/IDE_EDIT_object_functionality.h contains?
After trying to run on Windows, could you give us how many lines the file ENIGMAsystem/SHELL/Preprocessor_Environment_Editable/IDE_EDIT_object_functionality.h contains?
47
General ENIGMA / Re: The particle systems extension is complete
« on: May 30, 2013, 01:55:46 pm »
The only GL dependent parts are the graphics systems bridges, which sum to about 600 lines of code. A lot of the code is not related to graphics, only to handling the particles themselves. The number of lines of code in the particles extension is about 6500. Each of OpenGL{1,3} is in the range of 8000-9000 lines of code. Given their size, and that there is a lot of the code that does not deal with graphics, I think it makes sense to isolate them as an extension. The bridges to OpenGL1 and OpenGL3 are relatively small, about 200 and 400 lines of code, respectively.
I agree with the part about them being in the API selection if other particle systems are to be written.
I agree with the part about them being in the API selection if other particle systems are to be written.
48
General ENIGMA / Re: The particle systems extension is complete
« on: May 30, 2013, 12:36:23 pm »
Most of the particles extension is independent of the graphics system used. While I think it could make sense to put it in the general part of the graphics systems folder, I believe we should not do this for two reasons: First, it would be nice to be able to turn off the particles if you don't use them. Many games do not use particle systems. Second, it may be nice to create a different particle systems implementation in the future. Robert have suggested that we should add 3D capabilities to the current system, and Unity seems to do particles in a good way, which it would be nice to support in the future. The best way to support these systems would in my opinion be to change particle systems to a main system instead of an extension. At the moment, I think it is fine that we postpone such an upgrade, and let the current system stay an extension, until we begin work on another particle systems implementation.
49
General ENIGMA / Re: The particle systems extension is complete
« on: May 30, 2013, 11:37:09 am »
I originally preferred that the particles extension was not on by default, since most games do not use it. That said, particle systems are a core part of GM, so I think it could make sense to make it on by default.
50
General ENIGMA / Re: Website and IRC Problems Version Control Could Fix
« on: May 27, 2013, 02:58:30 pm »
In regards to the licenses, I am certain that GPL3 and 3-clause BSD are compatible, since the Free Software Foundation states that they are compatible: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses.
In regards to distribution, the issue is that SMF versions 1.0 and 1.1 are licensed under the Simple Machines license, while SMF 2.0+ are licensed under 3-clause BSD. I looked into the source for SMF 1.1, and their themes are also licensed under the Simple Machines license. Therefore, the themes cannot be redistributed without their permission.
I am not certain whether we can redistribute the SMF 2.0+ software, though it may be allowed, since I don't think using SMF 2.0+ with a 1.x theme counts as a modification or derivative to the 1.x theme.
In regards to security, I think there's a better view of things: I think it is a safe bet that no matter what we do, the website is going to get cracked sooner or later. Open sourcing parts or not will not make much of a difference in regards to security, either positively or negatively, but it will make a considerable positive difference in regards to development and maintenance. Therefore, I think the best idea is to version control the things we want to version control, try our best to make things secure, and otherwise ensure that nothing is lost when the website gets cracked. This means that we shouldn't have any personal information anywhere, that we should discourage people from writing things they don't want in public in PMs, and encourage people to only use passwords on the website that are entirely unlike any of their other passwords, and finally backup anything that we would not like to get lost.
One of the things that convinced me of this was looking into how SMF hashes passwords. In the current version of SMF, SMF 2.0.4, password hasing is done by using the username as the salt, and using SHA-1 for the hashing. This is not a very good way of doing things, as explained on this website: http://crackstation.net/hashing-security.htm. Given that SM does not get that part right, I suspect that there are other parts in SMF that they do not get right either.
In regards to distribution, the issue is that SMF versions 1.0 and 1.1 are licensed under the Simple Machines license, while SMF 2.0+ are licensed under 3-clause BSD. I looked into the source for SMF 1.1, and their themes are also licensed under the Simple Machines license. Therefore, the themes cannot be redistributed without their permission.
I am not certain whether we can redistribute the SMF 2.0+ software, though it may be allowed, since I don't think using SMF 2.0+ with a 1.x theme counts as a modification or derivative to the 1.x theme.
In regards to security, I think there's a better view of things: I think it is a safe bet that no matter what we do, the website is going to get cracked sooner or later. Open sourcing parts or not will not make much of a difference in regards to security, either positively or negatively, but it will make a considerable positive difference in regards to development and maintenance. Therefore, I think the best idea is to version control the things we want to version control, try our best to make things secure, and otherwise ensure that nothing is lost when the website gets cracked. This means that we shouldn't have any personal information anywhere, that we should discourage people from writing things they don't want in public in PMs, and encourage people to only use passwords on the website that are entirely unlike any of their other passwords, and finally backup anything that we would not like to get lost.
One of the things that convinced me of this was looking into how SMF hashes passwords. In the current version of SMF, SMF 2.0.4, password hasing is done by using the username as the salt, and using SHA-1 for the hashing. This is not a very good way of doing things, as explained on this website: http://crackstation.net/hashing-security.htm. Given that SM does not get that part right, I suspect that there are other parts in SMF that they do not get right either.
51
General ENIGMA / Re: SwapBuffers Issue
« on: May 27, 2013, 08:03:16 am »
I haven't looked into the issue, but I think this page is useful for understanding how GM handles repainting: http://gamemaker.info/en/manual/405_11_repaint.
52
General ENIGMA / Re: Website and IRC Problems Version Control Could Fix
« on: May 26, 2013, 03:27:34 pm »
I think this sounds like an excellent idea, and the plans seem sound overall.
Forums:
In regards to the license, version 2.0+ of SMF uses a 3-clause BSD license, which is compatible with GPL3. As far as I can tell from the description on Wikipedia as well as the license description (http://www.simplemachines.org/about/smf/license.php), redistribution of source code or software license with the Simple Machines License, as well as any modifications, requires written permission from SMF. The themes from SMF 1.x are licensed under the Simple Machines License, but I don't think it would make any sense if the webpages generated using a theme are also licensed under the Simple Machines License, since then even basic usage of SMF would require written permission. Therefore, given that we are not currently, and do not plan to, redistribute either SMF or any themes for any version, or any modifications of those, I am convinced that there are no issues.
That said, in the long-term it would be nice if we could upgrade the theme to 2.0+, but I am convinced that there are no problems with the current plans.
Site:
Excellent plans. I have personally thought about adding automatically run tests to ENIGMA, primarily as an aid to development. I also think some of those tests could be run for releases, to see statistics of the tests (how many passed, how many failed, etc.), and possibly reject releases that do not work at all. A tests page could also be added to the site, and tests run daily/weekly or something like it, and statistics shown for each run, such that developers could more easily track regressions in bugs and see which bugs have been solved.
EDC:
Good points in general.
In regards to the download links, it would be useful to have platforms for each download link. I also think it would be useful to have some sort of option for playing the game directly on the page or on another page instead of downloading, when we get HTML5 support. That could be very nice. An option for downloading the source would also be very nice.
I think it will definitely be necessary to be able to search for games. I also think adding tags to a game, such that users can search for names and/or certain tags (such as genres), is a good idea.
An updating/reupload mechanism for games may also be a good idea, in case the user adds more content or fixes bugs.
In regards to viruses, there needs to be a mechanism at some point for "moderators" to remove games that contain/are viruses. I don't think it is needed in the start, but as the EDC grows, I think it will be necessary in order to scale.
And polygone is being silly, Josh is confused, and Robert says he is happy today.
Forums:
In regards to the license, version 2.0+ of SMF uses a 3-clause BSD license, which is compatible with GPL3. As far as I can tell from the description on Wikipedia as well as the license description (http://www.simplemachines.org/about/smf/license.php), redistribution of source code or software license with the Simple Machines License, as well as any modifications, requires written permission from SMF. The themes from SMF 1.x are licensed under the Simple Machines License, but I don't think it would make any sense if the webpages generated using a theme are also licensed under the Simple Machines License, since then even basic usage of SMF would require written permission. Therefore, given that we are not currently, and do not plan to, redistribute either SMF or any themes for any version, or any modifications of those, I am convinced that there are no issues.
That said, in the long-term it would be nice if we could upgrade the theme to 2.0+, but I am convinced that there are no problems with the current plans.
Site:
Excellent plans. I have personally thought about adding automatically run tests to ENIGMA, primarily as an aid to development. I also think some of those tests could be run for releases, to see statistics of the tests (how many passed, how many failed, etc.), and possibly reject releases that do not work at all. A tests page could also be added to the site, and tests run daily/weekly or something like it, and statistics shown for each run, such that developers could more easily track regressions in bugs and see which bugs have been solved.
EDC:
Good points in general.
In regards to the download links, it would be useful to have platforms for each download link. I also think it would be useful to have some sort of option for playing the game directly on the page or on another page instead of downloading, when we get HTML5 support. That could be very nice. An option for downloading the source would also be very nice.
I think it will definitely be necessary to be able to search for games. I also think adding tags to a game, such that users can search for names and/or certain tags (such as genres), is a good idea.
An updating/reupload mechanism for games may also be a good idea, in case the user adds more content or fixes bugs.
In regards to viruses, there needs to be a mechanism at some point for "moderators" to remove games that contain/are viruses. I don't think it is needed in the start, but as the EDC grows, I think it will be necessary in order to scale.
And polygone is being silly, Josh is confused, and Robert says he is happy today.
53
General ENIGMA / Re: SwapBuffers Issue
« on: May 26, 2013, 06:18:54 am »
I get the issue on my Windows system, but not my Linux system.
54
General ENIGMA / Re: Innacurate Framerate Counter
« on: May 26, 2013, 06:12:53 am »
True, it can let it sleep as long as it would like, but the scheduler would be very unreasonable if it slept for a long time when there is no load on the system.
55
General ENIGMA / Re: Testing and logging fps on different systems
« on: May 26, 2013, 06:10:42 am »
TheExDeus: Many thanks, that is very useful.
So far, it seems like the fps-handling now works as it should, except in regards to the 60 fps cap on some systems.
So far, it seems like the fps-handling now works as it should, except in regards to the 60 fps cap on some systems.
56
General ENIGMA / Re: Innacurate Framerate Counter
« on: May 26, 2013, 04:31:06 am »
In regards to having more draw steps than update steps, I agree that it would be peculiar, but there may be situations there it theoretically could be useful. For instance if you interpolate between two consecutive game states (I have heard that some physics simulations support interpolating between two states, though I don't know much about it), or extrapolate from the previous game state. I agree that it seems like a lot of work and a lot of complexity and potential issues for no or very little gain, but it is still something that has been talked about. But I don't have any beef with not bothering with it in any way 
.
In regards to sleep functions that have a granularity of 1 millisecond or more, it is only impossible to get a higher framerate than 1000 if you sleep in every step. As IsmAvatar mentioned before, it is possible to fudge it by not sleeping in every single step, and this is what I implemented some months ago when seeking to improve the fps-handling for both Linux and Windows. That is also why it has been possible for some time now to get a fps of more than 1000 on Windows even when the implementation used Sleep.
In regards to whether the fps issues have anything to do with different rates for the updating and the drawing, I agree, but they do have something to do with the fps-handling in general, at least if you want to support it in the engine. And that can be useful. If you just call screen_redraw() 5 times in an alarm event, you risk the draw events not being properly spaced out, depending on how fast drawing is and how many resources there are available. And that can be difficult to deal with correctly and accurately manually in the game, and much easier if done at the engine-level. But it seems that we agree that such functionality should not be supported by us, so that case is closed. Besides, if someone really wants to do that, they can always fork, modify and extend their version of ENIGMA.
Josh, I don't understand the point you are trying to make regarding the CPU scheduler. First, I think the CPU scheduler you describe is not generally representative for the CPU schedulers found on Linux or Windows. For instance, look at the CFS (http://en.wikipedia.org/wiki/Completely_Fair_Scheduler) CPU scheduler for desktop Linux. According to the Wikipedia page, it does not penalize processes that sleeps a lot, but tries to ensure that they get their share of the CPU when they need. Your description of a scheduler that puts the program to rest until the user interacts with it if it calls sleep too often seems very wrong. If I call sleep(1 millisecond) in a program once in a while, I think it would be utterly horrible if the CPU scheduler with a CPU not under heavy load just decided to put my application randomly on hold for several seconds because the user has not interacted with it. I really don't think there are any CPU schedulers out there like that. I also don't know how useful it is to use a GUI program like a calculator as an example of what will happen; a GUI program like that with no non-user-activities (apart from the rare sending of information of usage data, but that can be implemented by using a timer and getting events that way) waits on external events instead of sleeping, and just let its framework redraw things for it. I don't know if I understand you correctly, or if my description and understanding here of CPU schedulers and all that stuff is accurate, it has been a while since I looked at CPU scheduling.
Second, I don't think how the CPU scheduler schedules things should have much impact on how timing happens. As long as the CPU scheduler is somewhat rational and efficient, I think it is fair to expect the fps-handling to have full fps when there is no load on the system or the game, and degrade smoothly when there is some load. This also brings me to other requirements for the fps-handling. Apart from having full fps with no load, and degrading smoothly under increasing load, I also have the requirement that if there are sudden stops, ie. one step taking far too long compared to other steps, that the fps-handling does not suddenly go through a lot of steps, causing the game to jump a lot in time, in order to catch up. It took a while and a fair amount of work, discussion and feedback to get it right, but I think the current implementation fulfills those requirements pretty well.
In regards to the users' expectation, while it is not smart of them if they expect their game to run at full fps independent on the load or the machine, I do think it is fair if they expect the performance to degrade smoothly if the game is run under stress and/or on a machine with few available resources.
.In regards to sleep functions that have a granularity of 1 millisecond or more, it is only impossible to get a higher framerate than 1000 if you sleep in every step. As IsmAvatar mentioned before, it is possible to fudge it by not sleeping in every single step, and this is what I implemented some months ago when seeking to improve the fps-handling for both Linux and Windows. That is also why it has been possible for some time now to get a fps of more than 1000 on Windows even when the implementation used Sleep.
In regards to whether the fps issues have anything to do with different rates for the updating and the drawing, I agree, but they do have something to do with the fps-handling in general, at least if you want to support it in the engine. And that can be useful. If you just call screen_redraw() 5 times in an alarm event, you risk the draw events not being properly spaced out, depending on how fast drawing is and how many resources there are available. And that can be difficult to deal with correctly and accurately manually in the game, and much easier if done at the engine-level. But it seems that we agree that such functionality should not be supported by us, so that case is closed. Besides, if someone really wants to do that, they can always fork, modify and extend their version of ENIGMA.
Josh, I don't understand the point you are trying to make regarding the CPU scheduler. First, I think the CPU scheduler you describe is not generally representative for the CPU schedulers found on Linux or Windows. For instance, look at the CFS (http://en.wikipedia.org/wiki/Completely_Fair_Scheduler) CPU scheduler for desktop Linux. According to the Wikipedia page, it does not penalize processes that sleeps a lot, but tries to ensure that they get their share of the CPU when they need. Your description of a scheduler that puts the program to rest until the user interacts with it if it calls sleep too often seems very wrong. If I call sleep(1 millisecond) in a program once in a while, I think it would be utterly horrible if the CPU scheduler with a CPU not under heavy load just decided to put my application randomly on hold for several seconds because the user has not interacted with it. I really don't think there are any CPU schedulers out there like that. I also don't know how useful it is to use a GUI program like a calculator as an example of what will happen; a GUI program like that with no non-user-activities (apart from the rare sending of information of usage data, but that can be implemented by using a timer and getting events that way) waits on external events instead of sleeping, and just let its framework redraw things for it. I don't know if I understand you correctly, or if my description and understanding here of CPU schedulers and all that stuff is accurate, it has been a while since I looked at CPU scheduling.
Second, I don't think how the CPU scheduler schedules things should have much impact on how timing happens. As long as the CPU scheduler is somewhat rational and efficient, I think it is fair to expect the fps-handling to have full fps when there is no load on the system or the game, and degrade smoothly when there is some load. This also brings me to other requirements for the fps-handling. Apart from having full fps with no load, and degrading smoothly under increasing load, I also have the requirement that if there are sudden stops, ie. one step taking far too long compared to other steps, that the fps-handling does not suddenly go through a lot of steps, causing the game to jump a lot in time, in order to catch up. It took a while and a fair amount of work, discussion and feedback to get it right, but I think the current implementation fulfills those requirements pretty well.
In regards to the users' expectation, while it is not smart of them if they expect their game to run at full fps independent on the load or the machine, I do think it is fair if they expect the performance to degrade smoothly if the game is run under stress and/or on a machine with few available resources.
57
General ENIGMA / Re: Networking Systems *forthevin*
« on: May 26, 2013, 03:33:45 am »
Hey Robert, I think Josh knows more about this stuff than me, but looking at the CompilerSource/compiler/compiler.cpp file, I think there is one extra place you have to modify, namely where the string to execute the build is constructed. Around line 550, you can see some of the arguments being passed in, namely those that assigns to GRAPHICS, COLLISION, etc. for the makefiles.
58
General ENIGMA / Re: Testing and logging fps on different systems
« on: May 26, 2013, 03:24:00 am »
Also TheExDeus, what CPU and OS do you have?
59
General ENIGMA / Re: Testing and logging fps on different systems
« on: May 25, 2013, 10:03:27 am »
Both of the results look just like they should, the fps does not degrade until it reaches the cap, and it stays at that cap.
60
General ENIGMA / Re: NaturalGM Object Editor
« on: May 25, 2013, 09:37:04 am »
Ah, that makes sense . I am very much out of the loop in regards to the IRC, so there are some things I do not catch.
. I am very much out of the loop in regards to the IRC, so there are some things I do not catch.