ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on October 22, 2012, 09:03:39 pm

Title: Commit Privileges
Post by: Josh @ Dreamland on October 22, 2012, 09:03:39 pm
I'm swamped with college. TGMG's swamped with college, or "uni" (as in "university") as they call it in whatever ghetto he's from (And, well, everywhere else but America). Ism's swamped with "irl things," ie, her job. That's it for the "primary" developers. HaRRi and polygone have also not committed much recently.

In fact, you may have noticed that the lion's share of recent commits belong to forthevin. I haven't received any notices of him fucking anything up to date, and I've just merged another pull request of his which I haven't the time to test, so I decided that the best solution is just to instate him as a contributor with commit access.

So, everyone welcome forthevin to the development team.

Also, go ahead and direct all bitching at the missing primary developers here as well.

As for you, forthevin, don't worry; no additional responsibility seems to come with the title. Apparently. Except maybe fixing things if you fuck them up.
Title: Re: Commit Privileges
Post by: forthevin on October 23, 2012, 05:05:20 pm
Thanks for the commit access, I am ok with fixing anything I break.

In case anyone is curious, my current plan is to continue implementing the precise collision system, which is coming along well (the basic collisions work, including rotation and scaling, some collision types are not fully supported yet, such as diamond and ellipse, and there are a number of other functions that are still missing). If anyone wants to try it out, select Enigma->Settings->API->Collision->Precise in LateralGM.
Title: Re: Commit Privileges
Post by: TheExDeus on October 24, 2012, 04:45:01 pm
Good to hear there is progress. I also have a metric ton of shit to do. Mostly uni (yay, I'm from ghetto), job and like 3 edx courses I stupidly started to take.

Most of my complaints about ENIGMA right now are:
1) Something I have been bitching for years about - COMPILE FINISHED GAME BUTTON (so icon's, all of the optimizations, removed console and so on).
2) Texteditor seems quite buggy, but the one that I hate the most is this: https://dl.dropbox.com/u/21117924/lgm_bug.png which I also informed Josh about.
3) Parser still not done, so things like variable access in scripts is mostly broken

That is all I can remember. Only thing I could commit (or give someone else to commit like forthevin) is the fix for keyboard_char on windows.
Title: Re: Commit Privileges
Post by: IsmAvatar on October 24, 2012, 06:19:27 pm
Cool, you were able to stick that into LGM's settings panel without modifying LGM, so we must have done something right with the modularity. If you need any help with poking at the LGM-side of things, you know where to find me.

Harri: yeah, the texteditor has always been a pain. Before I got swamped, I was kinda working on making both JEdit and JoshEdit modules match in API so that you could swap them out easily (mainly so we could restore JEdit)
Title: Re: Commit Privileges
Post by: Josh @ Dreamland on October 24, 2012, 08:29:19 pm
I knew that'd be a good idea. ^_^
Which is good, because we're kind of overdue for a good idea.

My schedule:

Thursday: Prepare elaborate cheat sheet for statistics midterm. Do some math homework.
Friday: Quiz over some math stuff. Statistics midterm. Continue math homework. Continue stats homework. Finish starting computer architecture homework.
Saturday: Finish math homework. Finish statistics homework. Continue computer architecture homework.
Sunday: Continue computer architecture homework. You really don't understand how long this assignment is.
Sunday: Continue computer architecture homework. You really don't understand how long this assignment is.
Monday: Business as usual. Submit math homework. Continue computer architecture homework. It's a long assignment.
Tuesday: Spend all morning finishing computer architecture homework, arrive late to class and submit it.
Wednesday: Business as usual. Submit statistics homework. Mourn the grade I'm going to get on architecture homework.
Thursday: For the first time in eleven years, maybe find some time to work on ENIGMA.
Title: Re: Commit Privileges
Post by: IsmAvatar on October 25, 2012, 01:08:14 am
That was his schedule last week, too, and he spent the free day making fun of the deplorable state of the project (and maybe being productive enough to pull vin's changes) :-p
Title: Re: Commit Privileges
Post by: Josh @ Dreamland on October 25, 2012, 07:15:40 pm
Meh. I know exactly what I would do to the project if I had any time to work on it (and do a good job of it, I mean). :P
Title: Re: Commit Privileges
Post by: forthevin 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, [snip]move_bounce_all(true)[/snip] in GameMaker seems to always round the resulting angle to a multiple of ten, which [snip]move_bounce_all(true)[/snip] 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.
Title: Re: Commit Privileges
Post by: polygone on November 11, 2012, 08:45:53 pm
How much testing have you done with the precise collisions? Have you tried running some game maker examples (like a plat-former with slopes) to see if it works the same in enigma as GM? Just to mention in the API settings it still says (Not Implemented) alongside precise.

Good luck with the particles they have been a long time unimplemented because everyone is too lazy to bother with them :P
Title: Re: Commit Privileges
Post by: polygone on November 11, 2012, 09:19:19 pm
Ok I deciding to try a few files out myself so this is unfortunately the part where I start to do your nut in forthevin :P

I did a quick test of move_bounce and it's not behaving exactly right. If you download this example game you will see:
http://enigma-dev.org/edc/games.php?game=35

Basically when you run into a wall it should just bounce you off which you will see happens using bbox or in GM but it stops you when using precise. Anyways don't ask me to try and debug it; writing that move_bounce function for bbox system did my head enough for one lifetime :)
Title: Re: Commit Privileges
Post by: polygone on November 11, 2012, 09:39:52 pm
OK, I tested out the generally collisions though and they seem to be working very splendidly :)

For anyone that wants working proof you can try this basic collision engine I used for testing:
http://enigma-dev.org/edc/games.php?game=36
Title: Re: Commit Privileges
Post by: forthevin 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.
Title: Re: Commit Privileges
Post by: polygone on November 12, 2012, 10:40:32 am
Hmm I'm not sure: I seem to remember if you check the x,y coordinates in the collision event with a solid in GM they will show that it has moved back before the event code happens? I can't check that myself right now.

Maybe GM calls a check before and after would this still make things work correctly?

I see in the function you used:

Code: [Select]
    inst1->x = inst1->xprevious;
    inst1->y = inst1->yprevious;
I wouldn't rely on those values, also I think you need to do a place meeting check before hand because have you tested using move_bounce in the step event as well as the collision event? I used instead at the start:

Code: [Select]
    if (place_meeting(inst1->x, inst1->y, object))
    {
        inst1->x -= inst1->hspeed;
        inst1->y -= inst1->vspeed;
    }
    else if (!place_meeting(inst1->x+inst1->hspeed, inst1->y+inst1->vspeed, object))
        return false;
I think you should be using the same.
Title: Re: Commit Privileges
Post by: forthevin 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.
Title: Re: Commit Privileges
Post by: polygone on November 12, 2012, 03:36:12 pm
OK I still can't test anything but it sounds like you have tested and sorted it out correctly. Don't be surprised though if in a weeks time you find something else wrong with it :P It seems to be the way with these functions.

By the way are you familiar with opengl much at all? I'm still looking for someone to try and sort the lighting out, I can't work out what's wrong with the normals and it's troublesome.
Title: Re: Commit Privileges
Post by: forthevin 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.
Title: Re: Commit Privileges
Post by: polygone on November 14, 2012, 09:01:31 am
The normals haven't been added to the basic shapes at all, but that is a different story. If you run this 3d example in ENIGMA and GM you will see the difference:
http://enigma-dev.org/edc/games.php?game=31

Here's a screenshot comparing (ENIGMA on the left, GM on the right):
http://i.imgur.com/HkpzC.png

You will see it with other examples as well on the EDC, it's like the normals aren't being used at all; even though the normals are being set manually in the d3d_model_vertex_normal functions used in the model drawing. I know the normal values in the games are right because they are working fine with GM and the model function calls are fine since everything is in the right position in ENIGMA.
Title: Re: Commit Privileges
Post by: forthevin 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.
Title: Re: Commit Privileges
Post by: Josh @ Dreamland on November 14, 2012, 03:43:56 pm
Please stop fucking using get_working_directory(). All of you.
Title: Re: Commit Privileges
Post by: polygone on November 14, 2012, 03:52:36 pm
You can macro it and add an option for it if you want it to be sorted.
Title: Re: Commit Privileges
Post by: polygone on November 14, 2012, 03:58:00 pm
And nice one forthevin for sorting out the lighting! Been an annoying problem. I see it's handy having somebody who's actually used opengl lighting before as opposed to me trying to get it to work when I've never worked with opengl before.

I would love to test it right now but it appears that something is going horribly wrong, most like due to one of the recent commits by josh.
- to the irc I fly
Title: Re: Commit Privileges
Post by: polygone on November 14, 2012, 04:26:45 pm
That segfault has been sorted, and it looks like the lighting works yay! I shall now come to you with all my problems :)
Ok I'll give you a break so you can get on with your particles. I do have another problem with a collision engine but I'll try and debug that a little myself first as I doubt it's specific to what you committed.
Title: Re: Commit Privileges
Post by: Josh @ Dreamland on November 14, 2012, 09:50:09 pm
I don't want it to have an option; it should never appear in your code. Ever. The operating system handles it. Or at least it should, in a correct implementation, which I WILL have it use in the near future.

Anyway, I saw your request to remove the tracker link from the title bar, and I decided to make titles shiny instead.
Also, went ahead and fixed the avatar gallery, since that's been broken for God knows how long.
Title: Re: Commit Privileges
Post by: TheExDeus on November 15, 2012, 01:54:22 am
Yes, all references for get_working_directory() should be removed and instead the ENIGMA should be fixed in that respect. So just changing directory before running the game.
Title: Re: Commit Privileges
Post by: Josh @ Dreamland on November 16, 2012, 10:45:03 am
Okay, gentlemen; I just noticed you were talking about move_bounce. I am not privy to how you implemented it or move_contact, but I am hoping that for bbox, you just do some subtraction, and then for precise, you do some subtraction and then do a binary search (add one, add two instead, add four instead, add eight instead, add sixteen instead, add twelve instead, add eleven instead). Otherwise, I have more cleaning up to do when I'm finally free.
Title: Re: Commit Privileges
Post by: forthevin 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".
Title: Re: Commit Privileges
Post by: polygone on November 18, 2012, 03:34:08 pm
Note that with precise that the instance could collide with the bbox of an object but then not actually collide with the object in precise when moving forward. You could keep checking to see if the instance moves past the object without colliding then do a further bbox check beyond that; however it's probably not common enough a scenario for that to be efficient.

Looking at your code I'm also confused what this part is doing in there:

Code: [Select]
    double current_dist = DMIN;
    {
        double next_x = x + mid_dist*cos_angle;
        double next_y = y - mid_dist*sin_angle;
        if (collide_inst_inst(object, solid_only, true, next_x, next_y) == NULL) {
            inst1->x = next_x;
            inst1->y = next_y;
            current_dist = mid_dist;
        }
    }
I don't think it should be there at all.
Title: Re: Commit Privileges
Post by: polygone on November 18, 2012, 04:53:17 pm
As a testament to the precise collision system working I have posted a sonic engine at the EDC:
http://enigma-dev.org/edc/games.php?game=37

The slopes and loop seem to be functioning completely correctly.
Title: Re: Commit Privileges
Post by: polygone on November 18, 2012, 05:32:25 pm
Forthevin can I just ask when you tried the house effects demo did you see some bugged random flicking in the candle glow when you moved around the scene? Like this:
http://s8.postimage.org/f5f9r238l/Open_GL_Alpha_Primitive_Issue.png

It's rather annoying. It's being causes because the glow is transparent and being drawn with random scaling each step:
Code: [Select]
d3d_transform_add_scaling(1,.8+random(.1),.9+random(.1));
But yeah this crap isn't happening in GM, I wonder if it can even be fixed or not.

There's another small niggle as well, you can see in the image at the candle base there is a kind of white outlining to the bottom of the cone which isn't very pretty. You can see it at the bottom of the curtains as well but not at the bottom of the big cylinder pillars for some reason. I don't know what's causing this, it's not the interpolation this time as it happens when that's turned off as well.
EDIT: I see if I get rid of the reflect it goes and I can see it more clearly just drawing the reflect that the white is being drawn at the bottom of the reflected candle cone for some reason.
EDIT2: OK I see it's just the z-fighting with the floor meh. OpenGL seems to have much worse z-fighting niggles than DirectX does.
Title: Re: Commit Privileges
Post by: IsmAvatar on November 19, 2012, 01:31:01 am
That looks like Z-fighting. (Edit: Yup, you already figured it out)

As for the binary search, I must be misunderstanding where you plan on applying it, as it wouldn't work for a search loop, simply because of small objects being overlooked that way. A binary search is only useful on sorted data. In a collision search loop, there is no sorting. The data is 1's and 0's (collision or free), in no order.

forthevin: By the way, you can clump a bunch of similar changes together in 1 commit, or even make a group of commits and then squash them before pushing. That way the git doesn't seem flooded with small commits. Just a thought. You can do it however you want, since we're a small team.
Title: Re: Commit Privileges
Post by: Josh @ Dreamland on November 19, 2012, 02:53:39 pm
I can see your point, forthevin, but I think we should examine the typical use case. For a binary search to fail where brute force would succeed,  the colliding pixels would have to be fewer in breadth than 2**(n-1), where n is the distance from the bounding box edge to the pixel. So for a one-pixel collision to miss, it has to be at least three pixels from the bbox edge. Otherwise, the check with d = 1 or d = 2 would catch it. The check with d = 4 would potentially miss it.

So, that circumstance *could* arise, but I'd argue that it wouldn't. If we want to build it for every case, then we can't use the bounding box as a hint, either—the bounding box can be placed away from the actual collidable area.

I'm not that worried about it, though, as the function dogged it in GM so people learned to avoid it. Besides, no offense to you or anyone else, but I intend for ENIGMA to default to polygon based collisions if I (or anyone else) ever have a chance to work on them.
Title: Re: Commit Privileges
Post by: polygone on November 19, 2012, 04:10:40 pm
I don't think a binary search should be used either, it doesn't make sense to me to use it for this. However you make a good point about the bounding box, does manually changing the bounding box in GM affect move_contact?
Title: Re: Commit Privileges
Post by: polygone on November 19, 2012, 05:58:56 pm
Thanks forthwin for sorting the depth draw bug, that's been in enigma a while - it was suggested using a pre-calculated list for the depth but nobody got round to it. And I can see that it has resolved that bug I was having with the alpha glow and whatnot, I was thinking about the depth as well I don't know why I didn't consider it being related to changing the depth in the draw event; it didn't cross my mind for some reason.
Title: Re: Commit Privileges
Post by: forthevin 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.
Title: Re: Commit Privileges
Post by: IsmAvatar on November 20, 2012, 01:59:01 pm
Ah, I didn't think of the data being a collision line, rather than a collision point. Excellent, that'll work great, then, because the data is sorted (strange way to think of sorting, but again, the data is either 1 for collision or 0 for no collision, so as long as all data is contiguous except for the turnover point, it's sorted).
Title: Re: Commit Privileges
Post by: TheExDeus on November 20, 2012, 03:03:00 pm
Does the precise collision detection uses bbox check the first time and only if collision is detected it checks masks? Too lazy to check code right now to see.
Title: Re: Commit Privileges
Post by: forthevin 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.
Title: Re: Commit Privileges
Post by: polygone on November 23, 2012, 06:37:24 am
Hmm by the sounds of thing you use the GMC forums forthevin, I'm trying to figure out who you are? :)

I'm guessing you don't want people to know though and you leave no clues :P
Title: Re: Commit Privileges
Post by: forthevin 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 .
Title: Re: Commit Privileges
Post by: polygone on November 25, 2012, 10:39:59 am
hmm, that or you're trying to throw me off the scent? :p
Title: Re: Commit Privileges
Post by: forthevin 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.
Title: Re: Commit Privileges
Post by: IsmAvatar on November 25, 2012, 09:38:04 pm
If you would like, we can make a branch for your changes so you don't need to fork the whole project. It's up to you.
Title: Re: Commit Privileges
Post by: forthevin on November 26, 2012, 06:37:55 pm
I still have the old fork that I can use, so it is not so bad.