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 »
136
Proposals / Automatic updating for particle systems
« on: December 06, 2012, 01:35:34 PM »
I have implemented a very basic version of particle systems, which can be seen in this fork: https://github.com/forthevin/enigma-dev. Recently, I have worked with implementing automatic updating of particle systems. In GameMaker, particle systems can be either updated automatically (the default setting), or updated by hand. I have determined that GameMaker updates the particle systems between the end-step events and the draw events.

The issue is now that updates and changes in GameMaker generally happens as part of instances and their events, and not outside them. This is reflected in ENIGMA's handling of events, since function calls (as far as I can tell) cannot be put directly in between events. Since particle systems are independent of instances and their events, they are an exception to the rule. Therefore, updating particle systems between the end-step event and the draw event seems non-trivial, since only events can be updated between events.

I have found two solutions to the problem. The first is to create a hacky event, that does not go through instances, but just calls a single function. It could look like this in event.res:

Code: [Select]
particlesystemsupdate: 100000
Name: Particle Systems Update
Mode: None
Default: ;
Instead: enigma::update_particlesystems();

The above code would be placed in between the end-step and draw events. This code solves the issue. The only thing of notice is that it also generates a superfluous virtual function in the object superclass. This solution is currently implemented in the fork and works.

The second solution I have found would be to extend the format of event.res, such that the format allows the above solution but without generating a superfluous virtual function in the object superclass.

My suggestion is now that the first solution is used as it is, while the second solution is postponed until further notice. Since the superfluous virtual function is never called, it shouldn't cause much (if any) overhead.

137
Running "java -jar enigma.jar [path-to-game]" in the plugins directory gave me errors, but running it in the main directory as in "java -jar plugins/enigma.jar [path-to-game]" caused it to compile the game and create an executable in the directory of "[path-to-game]".

138
Announcements / Re: Thanksgiving Holiday Updates
« on: November 26, 2012, 07:16:51 PM »
I have committed a patch that changes the return type to enigma::instance_t for those functions that return an instance id.

139
Announcements / Re: Commit Privileges
« on: November 26, 2012, 06:37:55 PM »
I still have the old fork that I can use, so it is not so bad.

140
Announcements / Re: Commit Privileges
« on: November 25, 2012, 07:58:47 PM »
How can I throw you off the scent if there is no scent to follow? :P

In other news, I have looked a bit into particle systems, and am slowly beginning to implement the basics. My current plan is to do the implementation in my own fork, and once the system stabilizes, I will merge it into the main repository.

141
Announcements / Re: Commit Privileges
« on: November 23, 2012, 09:04:10 PM »
I do read the GMC forums occasionally, but I don't really post there, so I don't have any need for a user account. So I am not surprised that you have trouble finding my user account :P .

142
Announcements / Re: Commit Privileges
« on: November 20, 2012, 03:46:30 PM »
Yes, it first checks to ensure that the bounding boxes do overlap before going on to checking masks.

143
Announcements / Re: Commit Privileges
« on: November 19, 2012, 06:28:56 PM »
IsmAvatar:
In regards to the binary search, using binary search for finding the contact position should work correctly when used for a point along a line. The basic idea is to check half the distance for collisions, for instance using collision_line. If the check turns up nothing, there are no collisions in the first half, and so only the second half needs to be searched. If the check does turn up something, there are collisions in the first half, the first collision point will therefore be in the first half, and the second half does not need to be searched. In both cases, the search space is halved. The procedure is then repeatedly applied on the new remaining distances to be searched, until the remaining distance becomes 1 or less. It isn't exactly binary search as understood for sorted sequences, but the name still fits somewhat well. EricDB's collision_line_first is implemented somewhat similar to that way.
In regards to commits, I will avoid flooding git with many small commits in the future.

Josh:
I do believe that circumstance could occur quite often in certain games. In games that have medium or big sprites with long, thin structures, move_contact from certain points and angles would be very likely to encounter that circumstance. With subtraction implemented in move_contact, the behaviour for move_contact should be the same in ENIGMA and GameMaker, and the performance should be equal in the worst case, and considerably better in most cases.

I don't understand the part about the bounding box not being usable as a hint. Doesn't the bounding box always cover everything in the sprite, even under rotation and scaling? Manually changing the bounding box in GameMaker and using precise makes only the area inside the bounding box to be checked precisely, the rest of the sprite is ignored.

polygone:
Np, I first realized it was a depth problem after I commented out the assignment to depth and the bug was suddenly gone. I knew that the cause had something to do with the candle being drawn twice, because of the z-fighting and the increased color from the blend mode bm_add being used, but I didn't quite understand why it was being drawn twice until I commented out the depth. That also explained why the bug only occurred when walking towards the candle, not away from it: the depth for a candle becomes more negative when walking towards it, and so the draw event for the candle was executed twice.

144
Announcements / Re: Commit Privileges
« on: November 18, 2012, 03:04:50 PM »
Subtraction is used in move_contact and move_bounce in bbox, and I have just added subtraction to move_contact in precise.

The current implementation of move_bounce in precise is similar in behaviour and speed to move_bounce in GameMaker. It only uses a constant number of collision checks, which is fast, but not very accurate. Subtraction would only be useful if move_bounce is made more accurate, but I think that making it more accurate would make it slower than the implementation in GameMaker.

I have thought about using binary search for move_contact as well, but I think it can only be used correctly if the collision mask is "stretched"/repeated along a line for each check. Else, the binary search might skip collisions. Since "stretching" a bit mask along a line is quite slow for medium and large bit masks, it would probably be slow in most cases to use binary search in move_contact in precise. Since a line can be "stretched" quickly, I think binary search could be used for something like collision_line_contact. Certain polygons may also be fast to "stretch".

145
Announcements / Re: Commit Privileges
« on: November 14, 2012, 01:59:34 PM »
I got the Kingspace engine demo running correctly with lights, the latest commit should fix it. I fixed the directional lights and the light position update (it was being updated in the wrong place). The screenshot you uploaded fits with what I get after the latest fixes.

I had some trouble getting the Kingspace engine demo up and running on Linux. I found out that the path was formatted wrongly in file_bin_open in fileio.cpp - amongst other things, the path returned from get_working_directory() didn't include a starting slash.

146
Announcements / Re: Commit Privileges
« on: November 13, 2012, 09:13:42 PM »
Hi polygone, I have committed a change that should fix the lighting for positional lights. Note that not all lights may be active, since in some cases, OpenGL only offers 8 lights. This seems consistent with GameMaker:Studio, since its manual says that at most 8 lights should be active at once. I have also fixed the normal for the walls, and the normal for the floor is correct if the floor is not slanted.

147
Announcements / Re: Commit Privileges
« on: November 12, 2012, 03:01:33 PM »
You are absolutely correct regarding the events. I had tested move_bounce extensively with non-solid objects, and gotten the same behaviour, so then solid failed, I assumed it was due to the collision events handling of solid, and when changing the events "fixed" things, I jumped to the wrong conclusion. It turns out that (as far as I can see) my original findings a couple of months ago regarding solid were correct. I didn't implement solid correctly back then, only partially, but one of the most recent commits should implement solid correctly in the collision event.

I have made a number of changes to move_bounce. I am convinced that the moving-back should not be based off the speed, but off the previous position. I tested this by putting a non-solid player in one side of a room, put a non-solid block at the other end, give the player a low speed, and then teleport the player directly into the block and use move_bounce_all in the collision event. This results in the instance ending up at its original position (with its direction changed). For that reason, I believe it should be the previous position and not the speed. The latest commit changes things, such that move_bounce only moves the instance to the previous position if there is a collision currently.

The funny thing about the above scenario is that, if you make the block solid, teleporting the player into the block has no effect at all on the player, neither in position or speed. This can be explained by the correction you make regarding return false if has_coll(x+hspeed, y+vspeed) gives null. So I have added and tested your correction and verified that it works.

There are also a couple of other changes; the House Effects Demo uncovered several other, smaller bugs.

I have also tested the recent changes with some platformers and other examples, so the recent changes should work somewhat well.

148
Announcements / Re: Commit Privileges
« on: November 12, 2012, 10:03:41 AM »
Well, it actually turns out move_bounce is not buggy. Instead, it is the collision event handling of solid I wrote that is to blame. Since the code I wrote worked according to the description of solid collisions in the GameMaker manual and the YoYoGames wiki, that means that those descriptions are wrong. I have experimented a bit with a different handling of solid, and the new handling of solid I just committed seems to work the same in both GameMaker and ENIGMA for the House Effects Demo, as well as some other examples using solid. The way it works now is that, after the collision event, if the other object is solid and there is still a collision with the other object, return the current object to its previous position. In regards to the manual, it should be noted that the description is wrong in both the old (GM6) and the new (Studio) version of the manual, even though the collision event section has been rewritten in the new version.

I think I will document my new understanding of solid in the ENIGMA wiki, once I have tested out a couple more examples with solid and verified they work the same in GM and ENIGMA.

Finally, I hope that my naïve and misguided trust in the documentation ability of YoYoGames will not prevent me from shifting the blame to them :P.

149
Announcements / Re: Commit Privileges
« on: November 11, 2012, 07:06:08 PM »
In case anyone is curious, I have finished the precise collision system. The collision functions have been implemented and tested, and BBox has also been debugged a bit in the process. The performance is generally on par with GameMaker, which I believe is good enough for now.

In regards to the behaviour of the functions, I have tried to mimic the behaviour of the corresponding GameMaker functions. Some of the details are not quite the same, for instance, move_bounce_all(true) in GameMaker seems to always round the resulting angle to a multiple of ten, which move_bounce_all(true) in ENIGMA does not. But the overall behaviour is generally the same for each function and its corresponding function.

In regards to my future plans, I have decided to work on a simple implementation of a system for particle systems. Since the overall structure and design of the system has not been created yet, I will develop the system in a fork until it is stable enough to be merged into the main branch.

150
Proposals / Re: Collision shape options
« on: November 08, 2012, 07:34:15 PM »
Thanks for the notice, I have fixed object and all in the move_* functions. Why should DMIN be used instead of 1 to increment in the "for" loops?

I don't really have any future plans about what to work on in ENIGMA, apart from doing various small fixes. I do have a couple of ideas, but I haven't decided on any of them yet. Once the precise collisions are done, I will take some time to figure out what to work on, and then tell about my plans then.

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