code logs -> 2009 -> Fri, 03 Apr 2009< code.20090402.log - code.20090404.log >
--- Log opened Fri Apr 03 00:00:25 2009
00:19
<@Derakon>
Okay, given a 45-45-90 triangle and a rectangle in a situation like this one: http://derakon.dyndns.org/~chriswei/games/jbrl/collision/player6.png
00:19
<@Derakon>
It should always be less distance to back out the rectangle along the perpendicular to the hypotenuse than it should be to back it out straight horizontally or vertically, right?
00:20
<@Derakon>
...oh, wait, I see what's happening. The rectangle is actually further left than the triangle is. :\
00:20
<@Derakon>
...I think.
00:26
<@Derakon>
Yeah, that's what's happening. How annoying.
00:35
<@Derakon>
Oh, wait, no, it's the interior block after all.
00:35
<@Derakon>
Whee debugging~
00:54
<@Derakon>
What I really need is some way to recognize the interior edges of blocks and exempt those from collision detection.
00:55
<@Derakon>
Because otherwise I'm going to get situations in which it's faster to head out along a vector that doesn't make any sense because it's from an edge interior to the terrain.
01:42 Vornicus [Vornicus@Admin.Nightstar.Net] has joined #code
01:42 mode/#code [+o Vornicus] by ChanServ
01:53
<@Derakon>
Oh, hey, Vorn.
01:53
<@Derakon>
Care to bend your intellect to my current issue? http://www.gamedev.net/community/forums/topic.asp?topic_id=530024
01:55 * Vornicus applies shear.
01:56
<@Vornicus>
Aha
01:56
<@Vornicus>
One moment!
01:58
<@Vornicus>
Best way to do this is to apply Calculus.
01:58
<@Derakon>
CALCULUS
01:58
<@Vornicus>
Well, okay, not quite Calculus, but linear interpolation among motion frames.
01:59
<@Vornicus>
For simple polygons you can then determine exactly when and where the collision will occur.
01:59
<@Derakon>
You're suggesting doing multiple passes per frame so I don't teleport through the rightmost triangular block?
01:59
<@Vornicus>
Not multiple passes; infinite passes.
01:59
<@Derakon>
Sweeping, then.
01:59
<@Vornicus>
Use interpolation and solve the equations it gives you.
01:59
<@Vornicus>
Yes.
02:00
<@Derakon>
Yeah, that'd work...makes things more complicated, but it'd work.
02:00
<@Vornicus>
Physics is cheap.
02:01
<@Vornicus>
So long as you're not doing crazy stuff like springs.
02:03
<@Derakon>
Heh.
02:03
<@Derakon>
I suppose I'm fortunate that swept convex polygons are convex.
02:03
<@Vornicus>
yeah, that helps
02:10
<@Derakon>
The issue, then, is finding that swept polygon...
02:11
<@Vornicus>
It'll be a polyhedron instead of a polygon, but.
02:12
<@Derakon>
How do you get a two-dimensional polyhedron? O_o
02:13
< Alek>
¬_¬
02:16
<@Vornicus>
x y t
02:16
<@Derakon>
...oh, you're suggesting doing things that way.
02:17
<@Vornicus>
Tells you exactly where and when your two objects interact.
02:18
<@Derakon>
Me and three dimensions really don't mix well. ¬.¬
02:21
<@Derakon>
Alternative approach: I can use SAT (as I've already implemented) to detect if a collision occurs (and the appropriate ejection vector if so), but to decide which ejection vector to use, I project the player's polygon's verts along the player's velocity and do plain old line-line intersection tests.
02:24
<@Derakon>
Of course, if no verts pass through lines in the terrain polys, then that doesn't work...
02:25
<@Vornicus>
Right
02:29
<@Derakon>
This sucks. :(
02:29
<@Vornicus>
Collision detection generally does!
02:33 ToxicFrog [~ToxicFrog@67.204.58.ns-13619] has quit [Ping Timeout]
02:37
<@Derakon>
...I think I fixed it, by flipping two signs.
02:37
<@Derakon>
Well, a sign, and a comparison operator.
02:38
<@Derakon>
Now, the thing about SAT is, you generally want the shortest ejection vector for the polygon. Otherwise you'd have a partial intersection causing the moving polygon to teleport to the other side of the stationary one.
02:38
<@Derakon>
I was taking that logic of "find the shortest ejection" and using it again when returning the terrain block the player should react to.
02:38
<@Derakon>
But that's wrong.
02:38
<@Derakon>
I want the longest ejection vector in that case.
02:39
<@Vornicus>
Longest shortest vector.
02:39
<@Vornicus>
:)
02:39
<@Derakon>
Yes.
02:45
<@Derakon>
Okay, now I get to figure out how to keep the player from sliding down slopes without having to turn off gravity.
02:46
< Alek>
friction.
02:46 * Derakon facepalms.
02:46
< Alek>
it can be done.
02:46
< Alek>
¬_¬
02:48
< Alek>
I dunno, maybe something like any slope provides X subtraction to downward vector. and if your vector is larger than X, you slide down until it's less than X. like if you fell from a height.
02:48
< Alek>
a quick-and-dirty approximation of friction, imo.
02:48
<@Vornicus>
FIrst things first: make sure you don't bounce.
02:48
< Alek>
but of course. >_>
02:48
< Alek>
although bouncy surfaces would also be nice. :P
02:49 ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has joined #code
02:49 mode/#code [+o ToxicFrog] by ChanServ
02:50
<@Derakon>
Hrm. Back up a bit, actually. Depending on your subpixel position, you can't run up slopes. >.<
02:53
<@Derakon>
Like so: http://derakon.dyndns.org/~chriswei/games/jbrl/collision/player7.png
02:53
<@Derakon>
Problem being that you hit the bottom edge of the triangle instead of the sloped edge.
02:53
<@Derakon>
I could fix this by making the polygon non-triangular, at the cost of it being physically bigger than it looks...but most of the time you wouldn't notice, since the relevant edges should be interior on most maps.
03:12
<@Vornicus>
If you're pushed into the floor then there's no point.
03:12
<@Derakon>
Sorry?
03:13
<@Vornicus>
From what I can tell that should only happen if you're pushed into the floor.
03:13
<@Vornicus>
It's 70% as far to the diagonal than it is to the corner.
03:14
<@Derakon>
Good point. I know what's happening here, now.
03:14
<@Derakon>
It's the block below the triangular block that you're hitting.
03:15
<@Derakon>
It's that whole "longest ejection vector" thing biting me in the ass, is what it is. >.<
03:17
<@Derakon>
I can easily trigger this by getting stopped in midair by a platform, so I drop exactly on top of a tile in the floor. At that point I can't run sideways.
03:18
<@Vornicus>
THe ejection vector from an object your standing on should be 0.
03:19
<@Derakon>
You're continually getting pulled down by gravity.
03:19
<@Derakon>
Fixed, by making your running acceleration faster than gravity. ¬.¬
03:27
<@McMartin>
Yay, feature working.
03:27
<@McMartin>
Now to make it work over encrypted streams.
03:28
<@McMartin>
(In other news, I showed up at about 12:15 today and was maybe the third engineer to show up~)
03:28 * Vornicus determines that McM works in Scary Shit.
03:32 * Derakon runs around his test level a bit.
03:33
<@Derakon>
There's all kinds of things that still need work, like the fact that the player can only face to the left, the looping jump/fall animations, the player's speed, gravity, etc. making it hard to control...but I didn't get hung up on weird geometry!
03:33
<@Derakon>
VICTOLY
03:42 Vornicus [Vornicus@Admin.Nightstar.Net] has quit [Quit: ]
04:01 * McMartin finishes another bugfix/feature addition, depending on how you cast it.
04:01 * McMartin celebrates by making a printer far away produce gratuitous kitten pictures.
04:01
<@McMartin>
UniPrint has an excellent product.
04:02 * Derakon snickers.
04:03
<@McMartin>
It doesn't actually work well with our own products, but it is no less excellent for this.
04:26 * Derakon ponders how to select animation frames to display.
04:27
<@Derakon>
For jumping and falling, the progression should look something like [1, 1, 2, 2, 3, 3, ..., 9, 9, 9, 9, 9...] because you hold the last frame until your state changes.
04:27
<@ToxicFrog>
Whooops
04:27
<@ToxicFrog>
ME: return;
04:27
<@Derakon>
For running, though, the frame displayed depends not just on time, but on your speed.
04:28
<@ToxicFrog>
COMPILER: ok, let's check the type of the return expression against this function's declared return type OH JESUS THERE'S NO RETURN EXPRESSION *blargh*
04:28 * Derakon snickers.
04:30 * Derakon ponders...
04:30
<@Derakon>
For now, assume all frame choices are functions of time and velocity, with most being functions of just time.
04:31
<@Derakon>
Map velocity ranges to sequences of frame numbers.
04:32
<@Derakon>
E.g. ((-16, None), (-12, None)) : [1, 2, 3, 4, 5, 6, 7, 8], ((-12, None), (-8, None)) : [1, 1, 2, 3, 3, 4, 5, 5, 6], etc.
04:32
<@ToxicFrog>
Man. Printf debugging is a pain when your only IO instructions have types () -> int and int -> ()
04:32
<@McMartin>
Success!
04:32 * McMartin heads home
04:32
<@Derakon>
The game uses your current velocity as a key into that mapping, to look up your frame counter against the list.
04:32
<@Derakon>
Drive safely, McM.
04:33
<@Derakon>
Or, take BART safely or whatever.
04:33
<@McMartin>
Yeah, there will be cars on the road, wtf.
04:33
<@Derakon>
Does the approach I described sound reasonable?
04:34 * McMartin will probably have a little "work" to do later tonight, but he can do it while playing video games
04:34
<@McMartin>
Will check when I get home.
04:34
<@Derakon>
My only concern is that, at the moment, the run animation is the only one I can think of where velocity matters.
04:35
<@Derakon>
(But other things might depend on other states, for example, whether or not you're boosted could completely change frame selections for attacking)
04:35
<@ToxicFrog>
...that's interesting. locals t and k are getting assigned the same stack slot.
04:35
<@ToxicFrog>
Not cool.
04:36
<@ToxicFrog>
This explains a lot about the behaviour of my selection sort code~
04:37 * ToxicFrog tries to figure out if it's possible for there to be temporaries on stack when it enters a block
04:39
<@Derakon>
Maybe I should map the player's current action (e.g. run, jump, fall, attack) to a function that operates on the player's state. That'd mean hardcoding all this stuff...but implementing a non-hardcoded approach sounds a bit too much like overgeneralization.
04:47
<@ToxicFrog>
HAH!
04:47
<@ToxicFrog>
It's aliiiiiive!
04:48
<@ToxicFrog>
My compiler now correctly compiles the gcd, fib, and ssort files.
04:48
<@ToxicFrog>
And the tests like "binary expression tree ten levels deep"
04:48
<@Derakon>
Woot!
04:48
<@ToxicFrog>
I think everything is working now
04:48
<@ToxicFrog>
Although I might adjust the calling convention to suck less.
05:04
<@McMartin>
Derakon: I don't see anything immediately wrong with it, but I don't quite follow it either.
05:05
<@Derakon>
Mm, don't worry about it.
05:09
<@ToxicFrog>
Revised expression stress test successful, after a little problem where call was pushing r3+3 rather than IP+3 was resolved ??
05:10
<@Derakon>
Okay, this is weird...
05:10
<@Derakon>
http://paste.ubuntu.com/143265/
05:10
<@Derakon>
When I try to modify line 14 there, vim changes its indentation (pulling it out one tabstop). In the past when vim does this, it's because I've screwed up my syntax somewhere, but I don't see anything wrong here...
05:11
<@ToxicFrog>
...hmm. I have this nagging feeling that there are parts of my code that rely on r0 being 0 except when returning.
05:11
<@Derakon>
(Okay, I see a typo in a comment~)
05:11
<@ToxicFrog>
But I can't find any.
05:12
<@Derakon>
Oh, wait, bug was elsewhere. Still weird that vim's changing the indentations on me.
05:29
<@ToxicFrog>
Well, shit.
05:30
<@ToxicFrog>
I can't improve the callconv, as it requires putting the return value on the stack.
05:30
<@ToxicFrog>
This means the caller has to pop it into a register, which is fine, unless it's already using all of the GP registers.
05:30
<@ToxicFrog>
In which case it first has to push one onto the stack to free it.
05:30
<@ToxicFrog>
Oops.
05:54
<@Derakon>
If you're in the mood for extravagantly long animated GIFs, check this out: http://derakon.dyndns.org/~chriswei/games/jbrl/collision/player8.gif
06:02 Syloqs-AFH [Syloq@Admin.Nightstar.Net] has quit [Connection reset by peer]
06:04 Orthia [~Orthianz@Nightstar-9429.xdsl.xnet.co.nz] has joined #Code
06:05
<@McMartin>
Well played.
06:12
< Orthia>
?
06:12
<@Derakon>
18 minutes ago, I said "If you're in the mood for extravagantly long animated GIFs, check this out: http://derakon.dyndns.org/~chriswei/games/jbrl/collision/player8.gif"
06:12
<@Derakon>
Either that, or he was responding to TF's comments on his compiler, even earlier.
06:17 * Derakon takes a moment to reflect on the fact that he has, today, implemented in 175 lines of Python what took him a couple of months and 500 lines of C++ to implement four years ago.
06:20
< Orthia>
yay boilerplate?
06:21
<@Derakon>
Yay having a goddamn clue what you're doing.
06:21
<@Derakon>
Also yay working in a modern language.
06:54 * Derakon adds map save/load.
06:54
<@Derakon>
My, that's faster.
07:02 * Derakon makes a nice big map, spends some time exploring it.
07:03
<@Derakon>
I may need to zoom out a bit...it's a bit hard to navigate as-is.
07:09 Derakon is now known as Derakon[AFK]
07:10 AnnoDomini [~farkoff@Nightstar-29147.neoplus.adsl.tpnet.pl] has joined #Code
07:10 mode/#code [+o AnnoDomini] by ChanServ
07:46 Orthia [~Orthianz@Nightstar-9429.xdsl.xnet.co.nz] has quit [Connection reset by peer]
09:39 Rhamphoryncus [~rhamph@Nightstar-7184.ed.shawcable.net] has quit [Quit: Rhamphoryncus]
09:41 Orthia [~Orthianz@Nightstar-13256.xdsl.xnet.co.nz] has joined #Code
09:42 Orthia is now known as OrthDeadto
10:14 OrthDeadto [~Orthianz@Nightstar-13256.xdsl.xnet.co.nz] has quit [Quit: ]
11:43 gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has joined #Code
11:43 mode/#code [+o gnolam] by ChanServ
11:59 Tarinaky [~Tarinaky@Nightstar-16638.plus.com] has joined #code
13:35 Vornicus [Vornicus@Admin.Nightstar.Net] has joined #code
13:35 mode/#code [+o Vornicus] by ChanServ
13:37 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has joined #code
13:37 mode/#code [+o Attilla] by ChanServ
16:04 Syloqs_AFH [Syloq@Admin.Nightstar.Net] has joined #code
16:05 Syloqs_AFH is now known as Syloqs-AFH
16:16 KBot [AnnoDomini@Nightstar-28438.neoplus.adsl.tpnet.pl] has joined #Code
16:17 KarmaBot [~karma.bot@Nightstar-29147.neoplus.adsl.tpnet.pl] has quit [Ping Timeout]
16:18 AnnoDomini [~farkoff@Nightstar-29147.neoplus.adsl.tpnet.pl] has quit [Ping Timeout]
16:19 KBot is now known as KarmaBot
16:20 AnnoDomini [~farkoff@Nightstar-28438.neoplus.adsl.tpnet.pl] has joined #Code
16:20 mode/#code [+o AnnoDomini] by ChanServ
16:27 Derakon[AFK] is now known as Derakon
17:45 Vornicus [Vornicus@Admin.Nightstar.Net] has quit [Ping Timeout]
17:51 Vornicus [Vornicus@Admin.Nightstar.Net] has joined #code
17:51 mode/#code [+o Vornicus] by ChanServ
17:56 * Derakon mutters at the toestubbing problem.
18:00
<@Derakon>
I have a triangle with coordinates ( 2714 , 2964 ) ( 2764 , 2964 ) ( 2764 , 2914 ), and my player with coordinates ( 2665.2 , 2815.0 ) ( 2715.2 , 2815.0 ) ( 2715.2 , 2965.0 ) ( 2665.2 , 2965
18:00
<@Derakon>
.0 )
18:00
<@Derakon>
Whoops.
18:01
<@Derakon>
Anyway, basically the triangle's hypotenuse is at pi/4 and the player is approaching from the left, having headed 1.2 units into the triangle's space.
18:02
<@Derakon>
So clearly, their projections onto the vector <1, 0> are going to overlap by 1.2.
18:02
<@Derakon>
It's their projections onto the normal of the hypotenuse that are confusing me, because they overlap by 1.5556. That can't be right.
18:12
<@Derakon>
Here's the projection logic I'm using: http://paste.ubuntu.com/143595/
18:13
<@Derakon>
Well, and here it is with projectPointOntoVector: http://paste.ubuntu.com/143596/
18:13
<@Derakon>
Though I've tested that function and am fairly confident that it's correct.
18:21 Rhamphoryncus [~rhamph@Nightstar-7184.ed.shawcable.net] has joined #code
18:29
<@Derakon>
Ah hah!
18:30
<@Derakon>
My logic doesn't allow for negative distances from the origin. Silly error.
18:36
<@Derakon>
Hrm...he's still stubbing his toe. >.<
18:48
<@gnolam>
Well, "distance" is usually defined as the Euclidean norm, so...
18:55
<@Derakon>
I'm projecting a point onto a vector and expressing the result as a scalar, which when multiplied by the vector, gives the projected point.
18:56
<@Derakon>
If I limit myself to positive values, I've just lost half the universe.
19:37 TarinakyKai [~Tarinaky@Nightstar-16638.plus.com] has joined #code
19:39 Tarinaky [~Tarinaky@Nightstar-16638.plus.com] has quit [Ping Timeout]
19:53
<@gnolam>
Argh. Give me just one more bit!
19:53
<@Derakon>
Mmmm, 7-bit ASCII.
19:53
<@gnolam>
I just realized that an unsigned 32 bit integer won't do for my purposes... but a 33 bit one would have.
19:54
<@Derakon>
hee.
19:54
<@Derakon>
Just slightly out of range, huh?
19:55
<@gnolam>
I need ~50% more range.
20:01 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has quit [Ping Timeout]
20:04
<@Derakon>
Are tuples of tuples invalid keys for dicts in Python?
20:04
<@Derakon>
I'm getting an error "list objects are unhashable" when I try to do "if (prevPoint, point) in self.internalEdgeSet"
20:06 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has joined #code
20:06 mode/#code [+o Attilla] by ChanServ
20:15
<@MyCatVerbs>
Derakon: tried it by hand in the REPL? Trying it now, it seems that tuples of anything hashable are themselves hashable too.
20:18
<@Derakon>
Oh, I see the problem.
20:19
<@Derakon>
My tuples were getting converted into lists in the process of adjusting their locations.
20:20 Alek [~omegaboot@Nightstar-317.dsl.emhril.sbcglobal.net] has quit [Quit: ]
20:23 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has quit [Ping Timeout]
20:26 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has joined #code
20:26 mode/#code [+o Attilla] by ChanServ
20:29 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has quit [Ping Timeout]
20:32 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has joined #code
20:32 mode/#code [+o Attilla] by ChanServ
21:02 * gnolam ponders client/server separation.
21:02 Attilla_ [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has joined #code
21:04 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has quit [Ping Timeout]
21:13
<@gnolam>
Blargh.
21:14
<@gnolam>
I'll put in some // HACKHACK disclaimers and make some dirty hacks around this until I figure out how to properly solve it. :P
21:23 * gnolam once again laments the lack of good free (bitmap) graphics editors.
21:27
<@gnolam>
Also: no font editors.
21:27 Attilla_ is now known as Attilla
21:27
<@gnolam>
I'd be happy with something that could simply convert SVG:s into TTF glyphs. But nooo...
21:30
<@gnolam>
But on the topic of SVGs, Inkscape has dangerously long without a new release.
21:30
<@gnolam>
Especially since it has some rather nasty bugs in 0.46.
21:50 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has quit [Ping Timeout]
21:54 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has joined #code
21:54 mode/#code [+o Attilla] by ChanServ
21:54
<@Derakon>
I may have to switch to something other than SAT. :\
21:55
<@Derakon>
Mainly because of this damned internal edge problem.
22:02
<@Vornicus>
The other way of course is the usual one - keep track of "touching the ground" state
22:03
<@Derakon>
I don't see how that helps me avoid stubbed toes.
22:03
<@Vornicus>
You dont do gravity when you're on the ground?
22:03
<@Derakon>
Ah, right.
22:05
<@Vornicus>
I mean you obviously need to care /anyway/, your sprite is different when you're on the ground.
22:05
<@Derakon>
Right, but at the moment I'm detecting that by looking for gravity-caused collisions with upward-facing normals.
22:10
<@Derakon>
Ugh, no, that still doesn't fix the stubbed-toe problem when running up a slope.
22:10
<@Derakon>
The problem here is basically that you intrude into a triangular polygon while your bottom edge is below the bottom edge of the polygon.
22:11
<@Derakon>
Since in that situation it's shorter to eject you horizontally than diagonally.
22:16
<@Derakon>
So, new plan: use SAT for dynamic game objects. Use a more brute-force line-line comparison algorithm for terrain (combined with taking advantage of the grid for pruning).
22:20
<@ToxicFrog>
This is a guess, but most platformers I've played seem to just use "eject straight upwards if that's less than a given distance, otherwise horizontally/downwards whichever is shorter"
22:20
<@ToxicFrog>
Although this leads to being able to run up a slope at top speed, which you may not want.
22:20
<@ToxicFrog>
Also, after using it for the 3760 project, I no longer dislike python.
22:21
<@ToxicFrog>
I do, however, now specifically dislike the way it handles dictionaries, and the key/attribute disconect.
22:21
<@Derakon>
That doesn't bother me so much. The character's in powered armor, after all.
22:21
<@Derakon>
I wasn't aware that you disliked Python.
22:21
<@ToxicFrog>
I've had some bad experiences, and seriously, whitespace sensitivity? Really?
22:21
<@Derakon>
The problem with ejecting vertically is determining the amount of ejection required when SAT is saying "The fastest way out is 1.2 along <-1, 0>"
22:23
<@Vornicus>
Arg. Creating a keyed sort system from unkeyed code.
22:23 * Derakon mutters at this situation: http://derakon.dyndns.org/~chriswei/games/jbrl/collision/player9.png
22:24
<@Vornicus>
...wait, duh. Put the key in as the first item in a pair, and let the tuple comparison method handle it.
22:24 * Derakon just mutters at collision detection in general.
22:54
<@Derakon>
Right, then. Hacked the collision response for the player to specifically look for upwards-diagonal blocks at foot level that what him to eject horizontally and reverse gravity instead.
22:58
<@gnolam>
HORSECOCK
22:58
<@gnolam>
I have to redo the entire player interaction design.
22:58 * gnolam headdesks.
23:11 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has quit [Connection reset by peer]
23:11 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has joined #code
23:12 mode/#code [+o Attilla] by ChanServ
23:55 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has quit [Connection reset by peer]
23:56 Attilla [~The.Attil@Nightstar-9147.cdif.cable.ntl.com] has joined #code
23:56 mode/#code [+o Attilla] by ChanServ
--- Log closed Sat Apr 04 00:00:37 2009
code logs -> 2009 -> Fri, 03 Apr 2009< code.20090402.log - code.20090404.log >