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.
61
General ENIGMA / Re: Innacurate Framerate Counter
« on: May 25, 2013, 09:36:04 am »
Robert, I can see how people can do that manually, but it seems to me that doing it manually can be problematic. For instance, if you want to have 30 updates per step, and 120 draw events per step, you could repeat the draw events 4 times each step. But if you do that and the drawing is relatively very quick, there is the risk that the draw events are not spaced out properly between updates, but instead is done in one quick batch just after the update, effectively becoming one draw event. You could then try to sleep manually, but that tend to have very low resolution and other issues. Therefore, I believe it would make sense to support it in the engine if we want that functionality.
Then again, you said that people do that manually, not that it is a good way to do things. What is your opinion on doing things that way?
Then again, you said that people do that manually, not that it is a good way to do things. What is your opinion on doing things that way?
62
General ENIGMA / Re: Testing and logging fps on different systems
« on: May 25, 2013, 09:22:37 am »
polygone: Many thanks, I had totally forgot about that part, and when I tested the logging I had reverted that part locally.
Robert: Thank you very much, I would also appreciate it if you also post which processor/how many cores you have, the number of cores can have affect on the scheduling and the resolution of the timers.
I have committed a revert of that part, so I would appreciate if you would try again with the latest commit.
Robert: Thank you very much, I would also appreciate it if you also post which processor/how many cores you have, the number of cores can have affect on the scheduling and the resolution of the timers.
I have committed a revert of that part, so I would appreciate if you would try again with the latest commit.
63
General ENIGMA / Testing and logging fps on different systems
« on: May 25, 2013, 08:14:15 am »
As you may know, there are big issues with the fps on several different systems. In order for me to figure out the issues and fix them, it would be very helpful if I could get some data on the fps on different systems. I have already fixed the issues on the systems I have direct access to myself.
What I would like you to do is to download the following test, run it with ENIGMA, and copy the results from the resulting file "fps_loggin_data.txt", along with information about your OS, the version/distribution of it, and what CPU your computer has/how many cores it got. If you are using a VM, you should instead skip this test, since VMs tend not to be reliable in regards to precise timing.
The link to the test: https://www.dropbox.com/s/9p7kszhy2sngns1/fps_logging.gm81
What I would like you to do is to download the following test, run it with ENIGMA, and copy the results from the resulting file "fps_loggin_data.txt", along with information about your OS, the version/distribution of it, and what CPU your computer has/how many cores it got. If you are using a VM, you should instead skip this test, since VMs tend not to be reliable in regards to precise timing.
The link to the test: https://www.dropbox.com/s/9p7kszhy2sngns1/fps_logging.gm81
64
General ENIGMA / Re: Innacurate Framerate Counter
« on: May 25, 2013, 07:39:00 am »
Robert, I think I understand (4) now, the desired functionality is that the updating rate and the drawing rate are fixed for a given room, but that they may be different from each other. Before I begin looking at that, I would first like to ensure that the current fps-handling works correctly on all systems.
In regards to sleeping, the current fps-handling does skip calling sleep under certain circumstances.
In regards to sleeping, the current fps-handling does skip calling sleep under certain circumstances.
65
General ENIGMA / Re: NaturalGM Object Editor
« on: May 24, 2013, 08:51:32 am »
Robert, is this text in your prototype meant to be funny?:
Code: [Select]
if (joshanidiot = true) {
joshtext = "idiot";
joshisanidiot();
}
66
General ENIGMA / Re: Innacurate Framerate Counter
« on: May 24, 2013, 07:13:59 am »
Robert:
1) On the systems I have tested, the fps is very accurate. That said, I only have access to very few systems, so it may well be the case that many, possibly most systems have issues with the fps.
2) That is definitely an issue. If ENIGMA is faster than GM, and yet the fps-handling makes it seem slower, that should be fixed.
3) Uncapped fps is supported internally in the currently implemented fps-handling. Implement support for setting the room_speed to 0 in your LateralGM version, and the fps should be unbounded no matter what (the sleep function is never called if the room_speed is 0 internally in neither xlib or Win32).
4) If I understand you correctly, the users that allow uncapped updating lets the game simulation depend on how many steps are taken each step, basically variable delta time. That is in general not a very good idea. See this link for more information: http://gafferongames.com/game-physics/fix-your-timestep/.
5) If I understand correctly, the uncapping is due to issues in the current fps-handling for some systems. Setting room_speed to 0 should bypass these problems, because "sleep"/"usleep" is never called when room_speed is 0.
I haven't read up on how Unity does things, but I will read up on it later.
Josh: I changed how fps is handled in xlib and Win32, so the system acts in a more complicated way than just sleeping a fraction of 1000/room_speed.
1) On the systems I have tested, the fps is very accurate. That said, I only have access to very few systems, so it may well be the case that many, possibly most systems have issues with the fps.
2) That is definitely an issue. If ENIGMA is faster than GM, and yet the fps-handling makes it seem slower, that should be fixed.
3) Uncapped fps is supported internally in the currently implemented fps-handling. Implement support for setting the room_speed to 0 in your LateralGM version, and the fps should be unbounded no matter what (the sleep function is never called if the room_speed is 0 internally in neither xlib or Win32).
4) If I understand you correctly, the users that allow uncapped updating lets the game simulation depend on how many steps are taken each step, basically variable delta time. That is in general not a very good idea. See this link for more information: http://gafferongames.com/game-physics/fix-your-timestep/.
5) If I understand correctly, the uncapping is due to issues in the current fps-handling for some systems. Setting room_speed to 0 should bypass these problems, because "sleep"/"usleep" is never called when room_speed is 0.
I haven't read up on how Unity does things, but I will read up on it later.
Josh: I changed how fps is handled in xlib and Win32, so the system acts in a more complicated way than just sleeping a fraction of 1000/room_speed.
67
Announcements / Re: Huge speed increase
« on: May 24, 2013, 06:47:17 am »
I have an apology and a correction. sleep_for_framerate does not sleep in any way, it only sets the current room_speed. The bad name is my fault, and I apologize for it. While the function used to be correctly named, I changed it while working on improving the fps-handling, and I must have forgotten to change the name to reflect the new behaviour. The only reason the change you made works, is that the fps-handling system for the platform systems Win32 and xlib are configured to treat room_speed == 0 as being the same as unbounded room_speed. So, with the newest changes, if the room_speed is set to 190, the room_speed will be unbounded. This is buggy behaviour on systems where the fps above 170 worked correctly before. Before on my Windows system, when I set a room to have a room_speed of 213 or 1042, I got a fps of 213 or 1042, respectively. (Note that I have not tested this on a Linux system, primarily because my own Linux box is capped to 60 for whatever reason, but the overall method I implemented for handling fps is the same between Linux and Windows). With the current system, a room_speed of 213 results in a fps of about 1200-1800 (with most values lying around 1780-1795). I have only tested this on my Windows system; on my Linux box, I can at most get an fps of 60. I haven't tried on the same hardware with a virtual box, due to virtual boxes potentially bothering precise fps-handling.
I would also like to note that the current fps-handling system for the Win32 and xlib platform systems are designed to try to gracefully handle slow-downs as well as abrupt stops (like once in a while, a single step taking something like half a second). I designed the behaviour to be similar to that I believe GameMaker to have in this regard; according to my tests, GM also tries to gracefully handle slow-downs and abrupt stops.
Excellent find regarding the room caption; it slows my uncapped system from 1700-1800 to 500-600 when the window_set_caption is commented in. I have added an issue for it on the tracker.
In regards to process priority on Linux, it should be noted that on Linux, a lower process priority value, or niceness value, means a higher actual priority.
Robert, I would also like to request that you ensure that the room_speed can be set to zero in the new versions of LateralGM (if you haven't already done it); I don't think 1.6 of LateralGM allows a room_speed zero, while the system treats 0 as unbounded. On systems where the fps-handling works correctly, there is not really any difference between setting the room_speed to 0 or to a lot higher than the maximum effective fps; however, it seems that on systems where the fps-handling does not work correctly, there is such a difference, given that the newest updates sets the room_speed to zero when the user-set room_speed is above 170.
I would also like to note that the current fps-handling system for the Win32 and xlib platform systems are designed to try to gracefully handle slow-downs as well as abrupt stops (like once in a while, a single step taking something like half a second). I designed the behaviour to be similar to that I believe GameMaker to have in this regard; according to my tests, GM also tries to gracefully handle slow-downs and abrupt stops.
Excellent find regarding the room caption; it slows my uncapped system from 1700-1800 to 500-600 when the window_set_caption is commented in. I have added an issue for it on the tracker.
In regards to process priority on Linux, it should be noted that on Linux, a lower process priority value, or niceness value, means a higher actual priority.
Robert, I would also like to request that you ensure that the room_speed can be set to zero in the new versions of LateralGM (if you haven't already done it); I don't think 1.6 of LateralGM allows a room_speed zero, while the system treats 0 as unbounded. On systems where the fps-handling works correctly, there is not really any difference between setting the room_speed to 0 or to a lot higher than the maximum effective fps; however, it seems that on systems where the fps-handling does not work correctly, there is such a difference, given that the newest updates sets the room_speed to zero when the user-set room_speed is above 170.
68
Proposals / Re: While we (as in forthevin) are moving shit
« on: May 24, 2013, 05:30:07 am »
Josh, sorry about the confusion regarding aliasing, I meant aliasing them by writing an inlined function. Given that there seemingly are very few overloaded [snip]#define[/snip]'d user functions, I don't think using inlined function will be much work or be very verbose.
In regards to function pointers, that is still the way it is implemented in the OpenGLES graphics system, while it is implemented through inlined functions in all the other graphics systems. I agree with you about the function pointers, it is not the best option. One thing I am wondering about is whether a template could be used to do the inlining and avoid the issues with a macro. But I still think simple inlined functions should be sufficient for our needs. If things change, we can always reconsider.
Regarding the snippet tag, I don't think it is bad when used for proper C++ code, but it doesn't look nice with Unix commands or the defines.
polygone, draw_get_pixel is indeed added as a macro to draw_getpixel, but draw_getpixel is not an overloaded function, so it would be easy to use an inlined function instead.
In regards to 3D objects, it would be very nice to have them at some point. One issue that I see with the proposed solution is that not all functions are easy to extend. For instance, move_contact_* and move_outside_* take directions as arguments. Would an extra directional argument be provided for the 3D object, such as a latitude-direction? That question also depends on how the 3D object is represented in object_spatial. An alternative to generalizing the different functions dependent on object_planar is to create 3D versions for them to use with the 3D objects instead, but that has some issues as well.
I also have another question, namely how the user should switch between 2D and 3D objects. Will it be switchable as a subsystem in the editor for all objects? And will the switching internally be implemented as a subsystem, or implemented some other way?
In regards to function pointers, that is still the way it is implemented in the OpenGLES graphics system, while it is implemented through inlined functions in all the other graphics systems. I agree with you about the function pointers, it is not the best option. One thing I am wondering about is whether a template could be used to do the inlining and avoid the issues with a macro. But I still think simple inlined functions should be sufficient for our needs. If things change, we can always reconsider.
Regarding the snippet tag, I don't think it is bad when used for proper C++ code, but it doesn't look nice with Unix commands or the defines.
polygone, draw_get_pixel is indeed added as a macro to draw_getpixel, but draw_getpixel is not an overloaded function, so it would be easy to use an inlined function instead.
In regards to 3D objects, it would be very nice to have them at some point. One issue that I see with the proposed solution is that not all functions are easy to extend. For instance, move_contact_* and move_outside_* take directions as arguments. Would an extra directional argument be provided for the 3D object, such as a latitude-direction? That question also depends on how the 3D object is represented in object_spatial. An alternative to generalizing the different functions dependent on object_planar is to create 3D versions for them to use with the 3D objects instead, but that has some issues as well.
I also have another question, namely how the user should switch between 2D and 3D objects. Will it be switchable as a subsystem in the editor for all objects? And will the switching internally be implemented as a subsystem, or implemented some other way?
69
Proposals / Re: While we (as in forthevin) are moving shit
« on: May 23, 2013, 01:35:17 pm »
I looked through the commits containing the migration to enigma_user, and it seems that the only [snip]#define[/snip]s I touched was the ones in the mathnc.{cpp,h} files.
You have a good point regarding the confusing renaming and errors. As for whether the overloads should all be aliased, or a parser macro should be implemented instead to handle it, they would give the same result for the user if I understand things correctly. I decided to try to estimate how many overloaded [snip]#define[/snip]'d user functions we have. I searched for them using "grep" ([snip]grep -R '#define [a-zA-Z_][a-zA-Z0-9_]* [a-zA-Z_][a-zA-Z0-9_]*$' *[/snip]), and after filtering out false positives, I ended up with 16 candidates, and it turned out 1 of them was overloaded (namely the [snip]#define irandom random_integer[/snip] case). While I am not certain that the search have caught all overloaded [snip]#define[/snip]'d user functions, I do believe it gives a good guess of how many overloaded functions there are. So, given that there seems to be very few overloaded [snip]#define[/snip]'d user functions, I would propose that we alias the non-overloaded as well as the overloaded ones, unless we find/write more overloaded [snip]#define[/snip]'d user functions.
You have a good point regarding the confusing renaming and errors. As for whether the overloads should all be aliased, or a parser macro should be implemented instead to handle it, they would give the same result for the user if I understand things correctly. I decided to try to estimate how many overloaded [snip]#define[/snip]'d user functions we have. I searched for them using "grep" ([snip]grep -R '#define [a-zA-Z_][a-zA-Z0-9_]* [a-zA-Z_][a-zA-Z0-9_]*$' *[/snip]), and after filtering out false positives, I ended up with 16 candidates, and it turned out 1 of them was overloaded (namely the [snip]#define irandom random_integer[/snip] case). While I am not certain that the search have caught all overloaded [snip]#define[/snip]'d user functions, I do believe it gives a good guess of how many overloaded functions there are. So, given that there seems to be very few overloaded [snip]#define[/snip]'d user functions, I would propose that we alias the non-overloaded as well as the overloaded ones, unless we find/write more overloaded [snip]#define[/snip]'d user functions.
70
General ENIGMA / Re: Critical Change, Function Renaming
« on: May 23, 2013, 03:47:26 am »
VBO's are actually very flexible. They can be used to transfer arbitrary data, both texture coordinates, points (1D, 2D, 3D and 4D), colors, etc. I don't know how significant the difference is between transferring 2 or 3 coordinates, but I believe it depends on the specific case (how fast the hardware transfer from the CPU to the GPU, how much other data is being transferred per vertex, etc.). Once a point arrives in the GPU, I believe it is generally transformed into 4D homogeneous coordinates once outputted from the vertex shader.
71
Proposals / Re: While we (as in forthevin) are moving shit
« on: May 22, 2013, 09:33:24 am »
Yes, I migrated several [snip]#define[/snip]'d functions as inlined functions. I didn't think it would break anything, but you are right that it will break overloads. As for a parser macro, I think that is overkill; I mostly did it because I thought it wouldn't break anything, and when all else is equal, inlined functions are nicer than macros. I think it is fine to use macros otherwise for these cases, since the macros in question are generally quite simple. I can go through the commits I made regarding enigma_user and revert the different macro-to-inlined migrations if you want (I see that you have already fixed one case in mathnc.h).
72
Tips, Tutorials, Examples / Modern OpenGL tutorial series
« on: May 21, 2013, 12:03:47 pm »
I found a new tutorial series about how to use modern OpenGL. There are current 3 articles in the series:
Getting started: http://solarianprogrammer.com/2013/05/10/opengl-101-windows-osx-linux-getting-started/
Drawing primitives: http://solarianprogrammer.com/2013/05/13/opengl-101-drawing-primitives/
Textures: http://solarianprogrammer.com/2013/05/17/opengl-101-textures/
The articles explain things bit by bit, and the source code for each program can be found on GitHub.
Getting started: http://solarianprogrammer.com/2013/05/10/opengl-101-windows-osx-linux-getting-started/
Drawing primitives: http://solarianprogrammer.com/2013/05/13/opengl-101-drawing-primitives/
Textures: http://solarianprogrammer.com/2013/05/17/opengl-101-textures/
The articles explain things bit by bit, and the source code for each program can be found on GitHub.
73
Proposals / Re: Manual, the Button
« on: May 17, 2013, 10:10:05 am »
...whoops, I actually looked at that page earlier when checking that there indeed was no overview, guess I skimmed through it a bit too quickly 
.
.
74
Proposals / Re: Manual, the Button
« on: May 17, 2013, 05:53:19 am »
I agree about providing both an online and an offline version of the manual.
In regards to the form, I think the Wiki both has a lot of good content and is quite open for modification. One issue is that the Wiki contains both documentation for the development of ENIGMA, LateralGM and others, as well as documentation for using ENIGMA and the other tools for creating games. While this is not a big issue, it can make it more difficult for users to get the right search results when using the Wiki. Another issue with the Wiki is that it currently doesn't have a general overview for the different pages, as some of the previous GM manuals had. While GM:Studio has preserved some of this structure, they have decided to alphabetize the ordering of some of their content, meaning that the previous and meaningful order was lost. For an example of what I am talking about, there is this page for the manual for GM 7.0: http://gamemaker.info/en/manual. The section on GML has a good order, with basic parts first, and more advanced or niche parts later. I think both of these issues can be alleviated somewhat, by creating a Wiki page that contains an overview of all the user documentation, possibly with an format inspired by the GM 7.0 manual page, and then let the manual UI item in LateralGM link to that specific page.
As for the handling of the offline version, I think having a cached version is an interesting idea. I would like to suggest that an offline version is also bundled together with the editor, such that the user always have some sort of documentation available, even if it is somewhat outdated.
One potential reason for having a differently supplied manual is that we may or may not provide compatibility versions for old GM versions, which would be useful for games created for old GM versions. And in those cases, the manual for the given GM version would be useful to have. As for launching the given manual, I would suggest that we let the user specify a folder for documentation instead of launching a specific manual. That way, the user can put all their manuals and documentation in that folder, and we can just let the user/system choose which application to use to view the given documentation.
In regards to the form, I think the Wiki both has a lot of good content and is quite open for modification. One issue is that the Wiki contains both documentation for the development of ENIGMA, LateralGM and others, as well as documentation for using ENIGMA and the other tools for creating games. While this is not a big issue, it can make it more difficult for users to get the right search results when using the Wiki. Another issue with the Wiki is that it currently doesn't have a general overview for the different pages, as some of the previous GM manuals had. While GM:Studio has preserved some of this structure, they have decided to alphabetize the ordering of some of their content, meaning that the previous and meaningful order was lost. For an example of what I am talking about, there is this page for the manual for GM 7.0: http://gamemaker.info/en/manual. The section on GML has a good order, with basic parts first, and more advanced or niche parts later. I think both of these issues can be alleviated somewhat, by creating a Wiki page that contains an overview of all the user documentation, possibly with an format inspired by the GM 7.0 manual page, and then let the manual UI item in LateralGM link to that specific page.
As for the handling of the offline version, I think having a cached version is an interesting idea. I would like to suggest that an offline version is also bundled together with the editor, such that the user always have some sort of documentation available, even if it is somewhat outdated.
One potential reason for having a differently supplied manual is that we may or may not provide compatibility versions for old GM versions, which would be useful for games created for old GM versions. And in those cases, the manual for the given GM version would be useful to have. As for launching the given manual, I would suggest that we let the user specify a folder for documentation instead of launching a specific manual. That way, the user can put all their manuals and documentation in that folder, and we can just let the user/system choose which application to use to view the given documentation.
75
General ENIGMA / Re: Encapsulating EDL types and functions in their own namespace
« on: May 16, 2013, 03:16:59 pm »
Supporting a particle system with 3D effects would be very useful to certain games. I don't think it would be easy to extend the current system to support 3D effects, but I do think I could refactor it into making it easier to support such an extension. I could well do that while I refactor the system to solve the current issues with it.
A particle effects designer would be very useful; there are particle effects designers for GM currently, but they are not cross-platform.
Being able to flip between different perspectives easily and according to what perspective the current game or room needs sounds very useful. I can also imagine being able to flip between them in a 3D game would be great when designing levels; getting an overview using the orthographic camera, and using the perspective camera when building the different rooms/sections.
In other news, most of the user-level constants, variables and functions have been moved to the enigma_user namespace. All the current extensions have been moved (except for the particle systems, which I will move after I have fixed and refactored them to the new system), the OpenGL 1.0 and 3.0 graphics systems have been moved, everything in Universal_System have been moved, OpenAL and FMOD music systems have been moved, BBox, BBox3d and Precise collision systems have been moved, and both the Linux and Windows code in Platforms have been moved. I haven't moved DirectX 10.0, mostly because it doesn't run yet, but it should be easy to move now that most of the other stuff have been moved, including the OpenGL 1.0 and 3.0 graphics systems. I have also fix a few bugs here and there, and I have refactored mathnc.{cpp,h} as well; Once the switch to enigma_user has been made, a couple of changes will need to be made there (basically just deleting and uncommenting a couple of lines and testing that it works).
Josh, in regards to the switch to enigma_user, I would like to request you to notify me once the switch is ready so I can try out the switching before it is implemented in the master branch. While most things have been moved, there may be some things I have missed, and so I would like to try and run some different games and tests to ensure that they compile and run, and fix any potential issues that occurs after switching, before the switch is committed to the master branch.
My plan for the future is right now to fix any issues that may crop up due to the move to enigma_user, and otherwise work on the particle systems.
A particle effects designer would be very useful; there are particle effects designers for GM currently, but they are not cross-platform.
Being able to flip between different perspectives easily and according to what perspective the current game or room needs sounds very useful. I can also imagine being able to flip between them in a 3D game would be great when designing levels; getting an overview using the orthographic camera, and using the perspective camera when building the different rooms/sections.
In other news, most of the user-level constants, variables and functions have been moved to the enigma_user namespace. All the current extensions have been moved (except for the particle systems, which I will move after I have fixed and refactored them to the new system), the OpenGL 1.0 and 3.0 graphics systems have been moved, everything in Universal_System have been moved, OpenAL and FMOD music systems have been moved, BBox, BBox3d and Precise collision systems have been moved, and both the Linux and Windows code in Platforms have been moved. I haven't moved DirectX 10.0, mostly because it doesn't run yet, but it should be easy to move now that most of the other stuff have been moved, including the OpenGL 1.0 and 3.0 graphics systems. I have also fix a few bugs here and there, and I have refactored mathnc.{cpp,h} as well; Once the switch to enigma_user has been made, a couple of changes will need to be made there (basically just deleting and uncommenting a couple of lines and testing that it works).
Josh, in regards to the switch to enigma_user, I would like to request you to notify me once the switch is ready so I can try out the switching before it is implemented in the master branch. While most things have been moved, there may be some things I have missed, and so I would like to try and run some different games and tests to ensure that they compile and run, and fix any potential issues that occurs after switching, before the switch is committed to the master branch.
My plan for the future is right now to fix any issues that may crop up due to the move to enigma_user, and otherwise work on the particle systems.