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 »
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.

Announcements / Re: 1,000,000 Cubes
« on: May 25, 2013, 10:00:21 AM »
I am getting an fps around 25-28 when viewing from the start location on a laptop with an integrated graphics card from Intel. Very, very nice.

EDIT: For a temporary fix to the issue with building the file, go into ENIGMAsystem/SHELL/Makefile, and edit line 23 from:

Code: [Select]


Code: [Select]

That should fix the issue (remember to still select OpenGL3 in the editor).

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.

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?

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.

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:

Announcements / Re: 1,000,000 Cubes
« on: May 25, 2013, 07:47:02 AM »
Josh, I have changed the fps-handling for Windows to use usleep instead of Sleep. usleep resides in the unistd.h header, and Sleep is contained in sys/time.h. I am not quite certain I understand your request regarding nanosleep, but I looked at the runtime libraries and headers for MinGW (version 3.20), and it does not contain nanosleep, only usleep and Sleep.

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.

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";

General ENIGMA / Re: Innacurate Framerate Counter
« on: May 24, 2013, 07:13:59 AM »

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:
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.

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.

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 #define'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?

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 #defines 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 #define'd user functions we have. I searched for them using "grep" (grep -R '#define [a-zA-Z_][a-zA-Z0-9_]* [a-zA-Z_][a-zA-Z0-9_]*$' *), and after filtering out false positives, I ended up with 16 candidates, and it turned out 1 of them was overloaded (namely the #define irandom random_integer case). While I am not certain that the search have caught all overloaded #define'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 #define'd user functions, I would propose that we alias the non-overloaded as well as the overloaded ones, unless we find/write more overloaded #define'd user functions.

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.

Proposals / Re: While we (as in forthevin) are moving shit
« on: May 22, 2013, 09:33:24 AM »
Yes, I migrated several #define'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).

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