Collisions

[Josh @ Dreamland]

Luda is back!

He offered to take up collisions again today, which is good news for the project. Luda wrote the original system used in R3, which I implemented rather poorly (no collision event), but it has since been over a year and it is safe to say we're both "on top of shit."

He apparently has hatched a plan for improving collisions to operate in O(n*log n) rather than O(n**2) like most systems. I'm not sure what time GM operates in, but frankly, who gives a crap; Luda's were faster than Mark's last time. (At least, as far as I can tell. I thought Mark was supposed to be an expert on collisions?)

Anyway, I'm personally tickled pink. Luda learned not long after making the original system that he could improve it by using integers instead of bytes (somehow that wasn't common knowledge at the time, now it's so obvious...), and with his new Quad Tree idea, we should be cooking with gas.

Also, I'd like to remind everyone that DLLs are also part of the equation now. These systems are the two things that everyone concurred are all that's left to set ENIGMA and GM apart. Let's hope we don't blow this, eh?

[RetroX]

Would it be possible to implement collision_triangle at some point, once the GM functions are done?  That seems to be pretty much the only one that's missing.

[Josh @ Dreamland]

Luda was just remarking about how easy that'd be to implement. He doesn't feel like signing on right now, though. *shrug*

[Rusky]

How about collision_polygon? It'd be just as easy, and you could give sprites polygonal masks rather than just squares.

[Josh @ Dreamland]

*doesn't see difference between collision_polygon and collision_triangle*
Would take an extra five lines of code.

I was thinking about just writing a wrapper to Box2D, really. Would take care of most such needs. Luda had started working on an engine that allowed for several polygon-based collisions...
I'm more concerned with bitmasks for GM-simulation purposes (Can't really think of a time where a quad wouldn't cut it that Box2D wouldn't be favorable).

Also, 1337th post in Announcements.

[RetroX]

Random question that goes somewhat along with collision_polygon: how did you manage to get max() and min() working (they're marked as done on the list) without a separate variable for the number of arguments?  Was it because of the parser adding them in?

[Josh @ Dreamland]

min(x,y,z) = min(x,min(y,z))

[RetroX]

min(x,y,z) = min(x,min(y,z))

for up to 64 arguments?

[Josh @ Dreamland]

For as many as you like.

[RetroX]

For as many as you like.

How can you manage this with cstdarg?  Or was it something else

[serprex]

It's called parsing. You parse the fold into multiple calls. Get it? Because you parse it. Also inlining makes it nice. But you don't parse for that

[kkg]

I thought Box2D only supported convex polygons, and not concave polygons D:

Correct me if I'm wronggggg

[score_under]

For as many as you like.

How can you manage this with cstdarg?  Or was it something else

Wait, do C compilers not support more than 64 arguments? Nothing about the calling convention is actually preventing them.

[Josh @ Dreamland]

I think he's remembering the good ol' days when I was satisfied just to have 4x as many as Mark.

[TheExDeus]

If you use min(x,y,z) = min(x,min(y,z)) then there is no limit to the number of arguments (as it uses only 2). It just makes more calls with every argument.

edit: It would seem to be slow, but I think you can make everything as via-ass as possible and still get 500% speed increase over GM.