#pentagram@irc.freenode.net logs for 8 Aug 2004 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[01:16:10] <-- Sheng_Gradilla has left IRC ("Terminando cliente")
[03:44:25] --- sbx is now known as sbx|afk
[04:36:28] --> Sheng_Gradilla has joined #pentagram
[04:36:31] <Sheng_Gradilla> :)
[05:55:18] * Sheng_Gradilla is away: No estoy
[09:19:43] --> Fl00der has joined #pentagram
[14:03:48] * Sheng_Gradilla is back (gone 08:08:27)
[14:21:32] <-- Kirben has left IRC ("System Meltdown")
[15:12:04] <-- Sectus has left IRC ("Leaving")
[15:18:20] --> Fingolfin has joined #pentagram
[15:18:20] --- ChanServ gives channel operator status to Fingolfin
[15:39:14] <wjp> hi Fingolfin
[15:40:03] <Fingolfin> hi wjp
[15:48:01] --> Handshakes has joined #pentagram
[16:08:11] <-- Handshakes has left IRC ()
[16:11:25] <-- Fingolfin has left IRC ("42")
[17:02:58] <Sheng_Gradilla> Yay!!
[17:03:08] <Sheng_Gradilla> Crusader: No Remorse at $12.95
[17:03:21] <Sheng_Gradilla> 19 boxes in stock
[17:03:25] <Sheng_Gradilla> http://www.cdaccess.com/html/quick/crusaderpr.htm
[17:06:46] --- sbx|afk is now known as sbx
[17:18:22] <-- sbx has left IRC ()
[18:01:03] <watt> Sheng_Gradilla: yup, I noticed that one when checking. I'm hoping to get both or No Regret first for PC, since I already picked up and currently playing through No Remorse for playstation.
[18:01:30] <Fl00der> oh, I didn't know that it's for ps too
[18:01:48] <watt> seems a lot harder to find No Regret, except on ebay, but I still like to avoid ebay.
[18:04:26] * wjp hasn't had any bad experiences with ebay yet. (Only bought things there 4 times, but still :-) )
[18:04:33] <watt> yeah, Dominus has a bunch of cool screenshots for it
[18:05:45] <watt> I just don't want to bid against a bunch of other people. I'd be willing to do "buy it now"s
[18:05:45] <Fl00der> I had crusader no remorse but gave it to my friend...
[18:05:56] <watt> whoops.
[18:07:27] <Sheng_Gradilla> heh, there is Wing Commander Prophecy for GBA
[18:08:04] <watt> wing commander manager to make it on practically every system
[18:08:32] <watt> I've seen Sega Saturn, 3d0, and playstation versions
[18:08:59] <wjp> well, the AnimationTracker-based ActorAnimProcess seems to be mostly working
[18:09:13] <wjp> I should probably check if saving works
[18:10:24] <watt> hmm.. that might be nice, but I'd still not worry too much about it... saving seems like more of a testing convience right now.
[18:10:39] <wjp> yes, seems to be working
[18:10:48] <watt> hint: I wanna play with it.
[18:10:58] <watt> hehe
[18:11:16] <wjp> I'd rather check if now than get a major headache later on from trying to figure out why saving/loading isn't working only to realize it was because I didn't test it now :-)
[18:11:21] <watt> yeah, I think I'll actually do some pentagram work today
[18:11:39] <watt> yeah, you're right.
[18:11:47] <wjp> I guess this stuff is commitable
[18:11:53] <watt> YAY
[18:11:55] <wjp> pathfinder isn't using it yet, but I'll get around to that
[18:13:03] <watt> I've also been itching to make multiple movers.... I want the crusader style movement in u8
[18:13:04] <wjp> it only doesn't try to adjust the location sideways if it is blocked or unsupported yet
[18:13:46] <wjp> SilencerMoverProcess? :-)
[18:13:57] <watt> later on yes.
[18:14:29] <watt> this idea would just be a set of Movers that avatarMoverProcess would choose as it's mover
[18:15:29] <Sheng_Gradilla> silencer-style movement? Hmm... that will require a bit of custom artwork
[18:15:49] <watt> Mouse, Relative (normal Silencer style), Absolute (move in direction pressed), and PathFindingMover (diablo style movement
[18:17:03] <watt> Sheng: Why?
[18:17:21] <wjp> argh... I have _way_ too many changes in my local tree
[18:17:37] <watt> It wouldn't have rolling.
[18:19:10] <watt> hehe.. yeah. I have about 4 different things I built that ultimately weren't useful, but I don't want to simply delete them
[18:19:40] <Sheng_Gradilla> the avatar does not roll nor crouch
[18:19:57] <watt> nor will he.
[18:20:57] <watt> rolling might be useful in u8, but I think that would be like a FrickinNinjaMoverProcess concept
[18:21:14] <Sheng_Gradilla> the silencer rolls and crouches
[18:21:54] <watt> right, but I only want his style of movement, not his actual moves.
[18:22:26] <watt> hehe, "Don't mess with the Avatar, man. He's a frickin ninja."
[18:23:54] <Sheng_Gradilla> "and he learned from Sheng of Bujinkan"
[18:24:00] <Sheng_Gradilla> I am a pixel artist :P
[18:24:21] <Sheng_Gradilla> and I train in Bujinkan
[18:24:47] <watt> what precisely is a pixel artist
[18:25:02] <wjp> ok, committed
[18:26:18] <wjp> oh, savegames are broken again
[18:26:19] <Sheng_Gradilla> a graphical artist that can do work at pixel level
[18:27:57] <wjp> I hope things still compile :-)
[18:30:19] <Sheng_Gradilla> :P
[18:47:41] <watt> read the diffs... looks promising
[18:49:27] <watt> and compiling now.
[18:55:00] <watt> works nicely here. haven't tried savegames
[18:55:37] <watt> they seem ok too
[19:56:41] <watt> wjp: I'm adding a getInterpolatedDelta to the AnimationTracker for the targeted jumping
[19:56:42] <watt> ok?
[19:57:33] <wjp> what is the difference between that and getInterpolatedPos?
[19:58:23] <wjp> or do you mean to use that for the (dx,dy,dz) calculation?
[19:58:40] <watt> the pos is the actual point that the Animation is at. The delta is the the difference between last point and this one
[19:59:02] <wjp> hm, why do you need it?
[19:59:31] <wjp> wouldn't you just use different (dx,dy,dz) for targeted jumping?
[19:59:51] <wjp> instead of those from the animation structure you'd calculate them manually
[19:59:51] <watt> I was using the getInterpolatedPosition for the targeted jumping and keep going back to the end point of the original animation.
[20:00:44] <wjp> hm, oh, you're implementing it outside AnimationTracker?
[20:01:03] <watt> hmm... well, I could also keep track of the total delta inside the targetedanim and add it to the position
[20:01:08] <watt> yes
[20:01:43] <wjp> I think you'd seriously confuse the AnimationTracker then :-)
[20:02:14] <watt> hmm...
[20:02:15] <wjp> it doesn't update the (x,y,z) it keeps internally from the Actor
[20:02:52] <wjp> which incidentally is because the Actor might not actually be performing the animation at that point (for pathfinding or tryAnim)
[20:02:59] <watt> right.
[20:03:56] <watt> oh.. yeah... blocked is a problem then right?
[20:04:20] <wjp> yes
[20:09:16] * watt hmms. Crap.
[20:09:45] <watt> umm, ok.. so, do I hack the targeting into the Tracker?
[20:10:02] <watt> or try to make a TargetTracker?
[20:13:18] <watt> well, yup. Confuses the Tracker if blocked... works ok otherwise
[20:14:57] <watt> sorta entertaining.. jumps... does most of the move.. transports instantly back to starting place
[20:17:51] --- ChanServ gives channel operator status to watt
[20:22:35] <wjp> hm
[20:23:33] <wjp> it might fit nicely into a subclass if we move the (dx,dy,dz,frame) calculation to a virtual function
[20:23:54] <wjp> but it might be overkill
[20:24:14] <wjp> I also wouldn't mind a setTargetedMode(x,y,z) function
[20:24:58] <wjp> which would probably only be valid when action==jump
[20:25:28] <watt> That's what I'm thinking... but I also did put a dependency of the AnimFrame being off ground....
[20:26:10] <wjp> what do you mean?
[20:26:42] <watt> The delta movement would only be applied if the frame was offground.
[20:26:53] <wjp> sounds reasonable
[20:27:09] <wjp> does the original anim have (dx,dy) == (0,0) when on the ground?
[20:27:45] <wjp> if so, you could also scale the moved distance by the original anim's (dx,dy) each frame
[20:28:11] <wjp> (you would have to run through the entire anim at the start to calculate the total distance)
[20:28:20] <watt> Normal animation delta when on ground and targeted delta off ground... perhaps it should just be 0,0
[20:28:26] <watt> yup.
[20:28:39] <watt> that's what I was trying to do
[20:29:19] <wjp> if it's (0,0) on the ground you can scale it everywhere, of course
[20:29:48] <watt> hm?
[20:30:47] <wjp> targetdx = (source_to_target_dx * orig_anim_dx) / total_orig_anim_dx;
[20:31:25] <wjp> (although that would have to be adjusted to prevent rounding errors)
[20:31:59] <wjp> but it doesn't really matter
[20:33:08] <watt> hmmm... ok, I think I see how to get this done...
[20:53:10] <wjp> looking forward to it :-)
[20:53:33] <watt> of course, I could be horribly wrong :->
[20:54:09] <wjp> well, even if you are, being wrong at first doesn't prevent you from being right later on ;-)
[21:20:35] <watt> hmm.. this code is slightly evil.... well, I'll see how it tests.
[21:21:49] <wjp> my code or your code? :-)
[21:21:53] <watt> mine
[21:23:06] <watt> I needed to get the final position of the animation, so I used a copy of the tracker and ran through it... ehem.. yeah.
[21:23:39] <wjp> not the most efficient way :-)
[21:24:12] <watt> well, I need proof of concept first
[21:31:02] <wjp> want me to quickly add a 'nextFrame' function to make looping over all frames easier?
[21:31:14] <watt> perhaps.
[21:31:17] <wjp> (it would take an int and return an int)
[21:34:20] <watt> do frame repeat? or just increment?
[21:34:47] <watt> err that should be "do frames ever repeat?"
[21:35:03] <wjp> no
[21:35:52] <wjp> it's basically 'start at startframe and increment until you reach endframe'
[21:36:06] <wjp> (looping back to frame 0 or frame 1 after reaching the end of the animation)
[21:36:49] <watt> oh, I thought I saw some frame repeat code in the old ActorAnimProcess (maybe it was for Darion... can't remember)
[21:37:19] <wjp> AnimationTracker mostly ignores framerepeat
[21:37:28] <wjp> ActorAnimProcess handles that
[21:37:54] <wjp> framerepeat is probably the wrong term, actually
[21:37:59] <wjp> it's more like framedelay
[21:38:15] <wjp> it's the number of ticks that each animation frame takes
[21:38:23] <watt> oh.. ok
[21:38:45] <wjp> the only thing AnimationTracker does with it is the getInterpolatedPosition
[21:41:17] <wjp> committed getNextFrame()
[21:41:35] <wjp> it actually cleaned up the step() function a bit as well
[21:51:19] <wjp> int totaldir = 0; for (unsigned int f = startframe; f != endframe; f = getNextFrame(f)) totaldir += animation->frames[dir][f].deltadir;
[21:51:22] <wjp> I think...
[21:58:44] <watt> yeah.
[21:59:19] <watt> except animaction instead of animation
[22:00:55] <wjp> um, yes :-)
[22:01:03] <wjp> I make that typo a lot :-)
[22:01:12] <watt> so do it
[22:01:14] <watt> I
[22:01:16] <watt> see
[22:03:06] --> Fingolfin has joined #pentagram
[22:03:06] --- ChanServ gives channel operator status to Fingolfin
[22:03:13] <watt> only problem with the scaling is if the animation deltas are zero... like with jumpup
[22:03:27] <watt> hi
[22:06:53] <watt> hehe.. and I think z shouldn't scale... hehe
[22:11:47] <watt> or at least not as badly as I did it
[22:12:24] <wjp> a little z scaling probably wouldn't hurt, although I seem to remember the original always used the same z
[22:12:45] <wjp> (but the new dz should probably never exceed the original dz)
[22:29:02] <wjp> time to go; g'night
[23:13:12] <-- Fl00der has left IRC ()
[23:29:59] <-- Fingolfin has left IRC ("Oops. This machine just fell asleep")
[23:48:58] <watt> hmmm.... well, it's getting better.. not perfect though
[23:54:14] --> Sectus has joined #pentagram