Commit Privileges

[Josh @ Dreamland]

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.

[forthevin]

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.

[TheExDeus]

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.

[IsmAvatar]

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)

[Josh @ Dreamland]

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.

[IsmAvatar]

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

[Josh @ Dreamland]

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

[forthevin]

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.

[polygone]

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

[polygone]

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

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

[polygone]

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

[forthevin]

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 .

[polygone]

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.

[forthevin]

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.

[polygone]

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