ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on March 26, 2010, 05:05:17 PM

Title: Collisions
Post by: Josh @ Dreamland on March 26, 2010, 05:05:17 PM
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?
Title: Re: Collisions
Post by: RetroX on March 26, 2010, 06:05:27 PM
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.
Title: Re: Collisions
Post by: Josh @ Dreamland on March 26, 2010, 06:25:41 PM
Luda was just remarking about how easy that'd be to implement. He doesn't feel like signing on right now, though. *shrug*
Title: Re: Collisions
Post by: Rusky on March 26, 2010, 06:34:28 PM
How about collision_polygon? It'd be just as easy, and you could give sprites polygonal masks rather than just squares.
Title: Re: Collisions
Post by: Josh @ Dreamland on March 26, 2010, 07:02:16 PM
*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.
Title: Re: Collisions
Post by: RetroX on March 26, 2010, 07:25:37 PM
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?
Title: Re: Collisions
Post by: Josh @ Dreamland on March 26, 2010, 07:30:34 PM
min(x,y,z) = min(x,min(y,z))
Title: Re: Collisions
Post by: RetroX on March 26, 2010, 08:16:35 PM
min(x,y,z) = min(x,min(y,z))
for up to 64 arguments?
Title: Re: Collisions
Post by: Josh @ Dreamland on March 26, 2010, 08:17:07 PM
For as many as you like.
Title: Re: Collisions
Post by: RetroX on March 26, 2010, 08:20:46 PM
For as many as you like.
How can you manage this with cstdarg?  Or was it something else
Title: Re: Collisions
Post by: serprex on March 26, 2010, 09:14:22 PM
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
Title: Re: Collisions
Post by: kkg on March 27, 2010, 03:55:24 AM
I thought Box2D only supported convex polygons, and not concave polygons D:

Correct me if I'm wronggggg
Title: Re: Collisions
Post by: score_under on March 27, 2010, 07:36:29 AM
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.
Title: Re: Collisions
Post by: Josh @ Dreamland on March 27, 2010, 07:59:33 AM
I think he's remembering the good ol' days when I was satisfied just to have 4x as many as Mark.
Title: Re: Collisions
Post by: TheExDeus on March 27, 2010, 08:10:52 AM
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.
Title: Re: Collisions
Post by: serprex on March 27, 2010, 08:19:49 AM
It isn't slow. Inlinining+Compiler Optimizations will make it faster than a generic loop. See http://en.wikipedia.org/wiki/Loop_unwinding

C99 states that a function need only be able to accept 127 arguments, this solution removes that limit
Title: Re: Collisions
Post by: Josh @ Dreamland on March 27, 2010, 08:21:53 AM
Not that I think anyone that needs the min() or max() of that many arguments shouldn't be using an array and iterating it him/herself.
It's just nice to shed GM's limits.
Title: Re: Collisions
Post by: RetroX on March 27, 2010, 08:30:32 AM
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
Yes, I asked josh about it earlier and found that out.

Personally, I think that it would be easier to just make a function with cstdarg and take-in a number of arguments and then count the arguments and put it in with the parser.  That would also solve the problem of mean(). (of course, choose() could be parsed like min() and max(), I guess)
Title: Re: Collisions
Post by: Game_boy on March 27, 2010, 08:56:40 AM
Where is the list of implemented functions in SVN? The one on the website isn't up to date (I think) and I remember an earlier testing release had a list of functions in a text file.
Title: Re: Collisions
Post by: The 11th plague of Egypt on March 27, 2010, 08:59:23 AM
Just a little doubt. In GM the lists declared inside an object are accessible form every object.
I don't know why, but they seem to be "global". What will happen now?
Title: Re: Collisions
Post by: Josh @ Dreamland on March 27, 2010, 09:06:24 AM
Game_boy:
Not at present; I could generate one, but I don't think some of the systems I coded are all in there. Like text file manipulation and DLL's.

The 11th plague of Egypt:
Assuming you're talking about ds_lists, they are global. Don't worry, this new system won't break ds_list; it'll supply an alternative to them. Lists are stored somewhat like sprites; a global array of things GM users don't understand, which they can access by an integer from absolutely anywhere. So, a=ds_list_create() will add to that list, "list a;" won't.
Title: Re: Collisions
Post by: Game_boy on March 27, 2010, 10:56:09 AM
a global array of things GM users don't understand

This gave me an awesome and disturbing mental image. So this array encircles the world and contains everything that every GM user doesn't understand? Everything? Including Yoyo's business model, how their computer works, cheesy Wotsits, how to code multplayer that doesn't fail, the Central Limit Theorem, and quantum mechanics?

(Yes, I do understand what you really meant)
Title: Re: Collisions
Post by: Josh @ Dreamland on March 27, 2010, 12:32:18 PM
Bahaha, yes, all of those things.
Title: Re: Collisions
Post by: Noodle on March 27, 2010, 04:52:58 PM
Ah, I remember the variable-number-of-parameters conundrum. The folding technique is good for min and max, but thats all. Mean and choose will both need an alternative method of parsing.
Title: Re: Collisions
Post by: serprex on March 27, 2010, 10:05:53 PM
Mean can be parsed mean(a,b,c) -> add(a,add(b,c))/argc
Choose can be parsed choose(a,b,c) -> *((var*[]){&a,&b,&c})[randint(argc)]
Title: Re: Collisions
Post by: Josh @ Dreamland on March 27, 2010, 10:09:54 PM
Man, that's hackish even by my standards. I'll do it.
Title: Re: Collisions
Post by: serprex on March 28, 2010, 07:30:04 AM
Hassle is that & requires lhs, so it won't work on rhs expressions
Title: Re: Collisions
Post by: Josh @ Dreamland on March 28, 2010, 10:04:10 AM
Actually, are you sure that casting that initializer as var will properly allocate them? (I'd cast as variant anyway, but...)