[01:30:42] --> Kirben has joined #pentagram
[01:30:42] --- ChanServ gives channel operator status to Kirben
[05:56:11] --> Colourless has joined #Pentagram
[05:56:11] --- ChanServ gives channel operator status to Colourless
[06:06:28] <-- Colourless has left IRC ("casts invisibility")
[07:17:51] --> Jett has joined #pentagram
[07:43:23] <-- DarkeZzz has left IRC (Read error: 110 (Connection timed out))
[08:14:10] --> servus has joined #pentagram
[10:27:04] --> Cashman has joined #pentagram
[10:27:16] * Cashman slaps Jett around a bit with a large trout
[10:32:05] * Cashman reads the change log
[10:35:37] <-- servus has left IRC (Read error: 60 (Operation timed out))
[10:43:31] <Cashman> hey Jett! another role playing name?!
[10:47:08] <Cashman> hmm cant find the disassembler header file!
[10:47:22] <Cashman> ooh yeah tools disassem - another path add for dev c++
[10:50:53] <Cashman> hmmm waiting for the recompile of pentagram
[10:51:06] <Cashman> trying some best optimization option in dev c++
[10:51:21] * Cashman notes there doesn't appear to be debug/release options for exectables!
[10:51:52] * Cashman will see if the size of the final exe is different for both "best optimization" and "non at all"..
[11:02:56] * Cashman notes that a fully optimized pentagram.exe file in dev c++ is 801 kb instead of 1.1 mb
[11:04:02] <Cashman> had to add disasm dir - everything except process.cpp to paths hmm tools code now being used
[11:06:51] * Cashman goes back to changelog for Darkes xml .cfg example!
[11:53:31] <Cashman> cashman yays! as his optimized ver gives him 25fps max
[11:53:39] <Cashman> sort low of 6ms
[11:53:49] <Cashman> paint of 10 and fill of 4
[11:53:50] <Cashman> nice!!
[11:54:01] * Jett yawns. Looks like he discoed whilst taking a nap. Shouldn't have stayed up large chunks of lastnight hacking code. Tired kitty.
[11:54:26] <Jett> Mmm... not bad. Doing anything else at the same time seems to make paint very erratic though.
[11:54:40] <Jett> mp3 playing especially for some odd reason. Prsumably to do with cpu cache misses.
[11:55:11] <Cashman> now for paint I can susstain like 10ms
[11:55:20] <Cashman> oh ok I see
[11:55:34] * Jett gets everything from 6 to 13 whilst playing mp3s.
[11:56:06] <Cashman> eh I was thinking - not important!! but a con - console engine would be good instead of crap painting over the top of the map
[11:56:19] <Cashman> like quake 3 e.g. tab to bring up fullscreen console
[11:57:23] <Cashman> ?colourless run the execution scene usecode!
[11:57:54] <Jett> wjp: Worked out one way of avoiding Application knowing too much about it's processes. Args doesn't screw around with argc/argv (confirmed by adding appropriate, missing const's *grin*), so one can just overload the Process constructor to take those two as arguments as well. Probably wants to be cleaner still though.
[11:58:26] <Cashman> aye
[11:58:49] <Cashman> hehe I see when you click on e.g. avatar you see usecode with text options!
[11:59:23] <Cashman> imagine if somehow things screwed up and you tried to call the guards from devons place
[12:00:02] <Cashman> how are you gonna handle nps movement! thats not usecode controlled right?!
[12:01:32] <Cashman> hehe /Cashman gets the key from the dungeon or where ever it was! without even moving
[12:01:45] <Jett> Colourless,wjp: Also a proposal. A 'working' directory for the games, along with the normal 'save' directory. Would allow users to 'install' the appropriate games from a +r-w protected source directory of original U8 directory structure. Also allow things like users being able to modify the original game usecode, etc in the future, without creating a 'new' game, and easy recovery of old game files (just by deleting the work directory and 'rei
[12:01:46] <Jett> nstalling').
[12:03:07] <Cashman> but nps etc. not usecode controlled right?!
[12:03:11] <Cashman> npcs
[12:03:26] <Jett> Directory would be by default something like ~/.pentagram/game-name/work along with ~/.pentagram/game-name/save for presumably the savegames. Same thing to happen in windows however it handles the '.pentagram' directory.
[12:03:46] <Cashman> yeah I see
[12:03:47] <Cashman> nice!!
[12:04:06] <Jett> We don't know. IIRC, we postulated the npc AI is actually in the executable, rather then usecode, due to lack of proof otherwise.
[12:04:58] <Cashman> hmm so you probally gonna have to write ur own AI + collision detection
[12:05:07] <Cashman> well yeah you are gonna have to aye!
[12:05:38] <Cashman> how about animation in general! didn't you include that in the /old
[12:06:14] <Jett> Most animations are usecode controlled. Some like npc movement are animated, and they are displayed by the animation display program.
[12:08:48] <Cashman> hehe someone could quickly add an addition to application sometime - scrolling the map so we have somthing a little cooler to plat with
[12:09:04] <Cashman> that would be interesting! to test usecode
[12:09:28] <Cashman> I see on iirc logs that colourless changed camera to the docks for a bit
[12:20:46] <Cashman> you very tird Darke!! keep that monitor off and sleep man!!
[12:25:43] * Jett has unfortunately, already slept for 4 hours tonight, which is going to make it a pain when he really needs to get to sleep in a couple of hours.
[12:26:30] <Cashman> cant you just start sleeping now again! and sleep till you have to get up like normal people can
[12:26:41] <Cashman> what ever normal is - I just know its what lots of us can do
[12:27:02] <Cashman> you been coding tonite or really just half a sleep at the keyboard?!
[12:28:46] * Jett has problems sleeping. Usually takes him about an hour or so to get to sleep, he can only get to sleep when actually tired unfortunately. *grin*
[12:29:08] <Jett> Writing documentation. Requires minimal brain cells and is relatively boring.
[12:32:26] <Cashman> ok!
[12:34:42] <Cashman> good luck
[12:34:43] <Cashman> l8er Darke
[12:34:47] <-- Cashman has left IRC ()
[13:33:48] --> Colourless has joined #Pentagram
[13:33:49] --- ChanServ gives channel operator status to Colourless
[14:00:46] --> wjp has joined #pentagram
[14:00:46] --- ChanServ gives channel operator status to wjp
[14:34:03] <-- wjp has left IRC ("bbl")
[14:51:04] --> wjp has joined #pentagram
[14:51:04] --- ChanServ gives channel operator status to wjp
[14:52:18] <-- Kirben has left IRC ("System Meltdown")
[15:35:20] --- Jett is now known as DarkeZzz
[17:20:55] <wjp> Colourless: do you know what the 'getCX/CY/CZ' intrinsics do?
[17:21:56] <Colourless> no idea
[17:22:06] <Colourless> i was going to check sometime
[17:22:10] <wjp> they seem to be used (among other things) for marbles
[17:23:32] <wjp> in MARBLE::use() the marble's getCX is compared to what appears to be the avatar's getCX
[17:23:45] <wjp> 00C6: 0A push byte 01h
[17:23:45] <wjp> 00C8: 6F push addr [SP-00h]
[17:23:45] <wjp> 00CA: 0F calli 04h 0006h (short Item::getCX())
[17:24:15] <wjp> that would appear to be the avatar, right?
[17:24:18] <wjp> (object 1)
[17:25:08] <wjp> maybe it's a more or less accurate version of getX/Y/Z
[17:26:19] <wjp> hm, return values from getCX/CY/CZ are used to position the camera here
[17:27:06] <wjp> (execution::087D)
[17:27:15] <Colourless> well then, it's probably get camera x, y and z
[17:27:19] <Colourless> if so, that's pretty simple
[17:27:41] <wjp> but they're Item::getCX/CY/CZ
[17:27:55] <wjp> not Camera::getX/Y/Z
[17:28:01] <wjp> (the latter exist too, btw)
[17:29:30] <Colourless> i don't know.
[17:30:02] <wjp> it's kind of weird...
[17:30:10] <Colourless> i think i know
[17:30:18] <Colourless> get 'centre' x y and z
[17:30:33] <wjp> hm, would make sense, yes
[17:30:37] <Colourless> that is centre of the bounding box
[17:30:47] <wjp> both in setting the camera and with 'bouncing' marbles
[17:31:41] <wjp> ShapeInfo::x/y/z are dimensions I guess?
[17:32:05] <Colourless> yes
[17:32:06] <wjp> are they in the same unit as Item::x/y/z?
[17:32:10] <Colourless> no :-)
[17:32:16] <wjp> I was afraid of that :-)
[17:32:28] <Colourless> multiply x and y by 32 to get the world size
[17:32:33] <Colourless> z is by 8... i think...
[17:32:43] <Colourless> yes
[17:32:44] <wjp> yes
[17:32:47] <wjp> ItemSorter.cpp agrees
[17:33:05] <wjp> oh, need to look out for FLG_FLIPPED there
[17:37:57] <wjp> *sigh*.. this intrinsic list is depressingly long :-)
[17:41:53] <wjp> oh great.. the next one on the list is used exactly once in U8 :-)
[17:42:50] <wjp> ah, but it seems to make sense
[17:43:05] <wjp> assuming a semi-broken disassembly :-)
[17:43:20] <wjp> 0204: 4B push addr [BP-0Bh]
[17:43:20] <wjp> 0206: 4B push addr [BP-06h]
[17:43:20] <wjp> 0208: 0F calli 08h 000Ch (Item::getPoint(WorldPoint&))
[17:43:21] <wjp> ...
[17:43:24] <wjp> 0210: 45 push huge F5 05
[17:43:38] <wjp> so getPoint fills a 5 byte struct?
[17:44:01] <Colourless> just is x,y,z packed
[17:44:03] <wjp> (uint16 x, uint16 y, uint8 z) I would guess?
[17:44:05] <Colourless> the & means it's a pointer
[17:44:07] * wjp nods
[17:44:19] <Colourless> references and pointers are internally the same thing
[17:44:34] <wjp> that "push huge F5 05" should probably be "push huge [BP-0Bh] 05" I guess?
[17:46:20] <wjp> UCMachine.cpp agrees, anyway
[17:55:04] <wjp> hm... I seem to missing some terminology here...
[17:55:23] <wjp> what would you call a function that assigns data to where a pointer is pointing to?
[17:55:52] <wjp> (and the same question for reading, come to think of it)
[17:56:12] <Colourless> AssignPointer? ReferencePointer?
[17:57:40] <wjp> dereference?
[17:59:29] <Colourless> yeah
[17:59:37] <Colourless> dereference
[18:08:41] <wjp> well, that cleaned up the main run loop in UCMachine a bit :-)
[18:08:47] <wjp> (getting rid of indirect push/pop)
[18:19:46] * wjp hmmms
[18:20:07] <wjp> getQuality, getUnkEggType, getQuantity, getQ are all the same function?
[18:21:15] <Colourless> no
[18:22:28] <Colourless> the coments beside them say what they require. they will return 0 otherwise
[18:22:36] <wjp> ah, ok
[18:22:45] <wjp> so check family, return Q if matches, return 0 otherwise
[18:22:56] <Colourless> yeah
[18:28:57] <wjp> hm, the return value uwaord of Item::setQuality is a typo I guess/hope?
[18:29:01] <wjp> s/uwaord/uword/
[18:29:04] <wjp> typical :-)
[18:29:29] <wjp> oh, I see the comment says 'Get' too
[18:29:33] <wjp> copy/paste error I guess
[18:49:34] <wjp> Colourless: when moving objects, do I have to do anything with lerping?
[18:49:43] <Colourless> no
[18:50:08] <Colourless> yeah that setQuantity() thing is wrong
[18:50:22] <wjp> ok, so I just need to adjust x,y,z and move it to a different object list if necessary
[19:24:19] <Colourless> eggs might be a little strange to implement\
[19:39:00] <wjp> yes, indeed
[19:39:14] <-- DarkeZzz has left IRC (brunner.freenode.net irc.freenode.net)
[19:39:14] <wjp> as well as other trigger-like events
[19:39:14] <wjp> (placing objects on others, IIRC?)
[19:39:14] <Colourless> the usecode class to execute when hatched 'appears' to be quality + 1151
[19:39:14] <Colourless> also i think that the mapnum value is used to specify what monster to that monster eggs spawn
[19:39:54] --> DarkeZzz has joined #pentagram
[19:42:05] <wjp> 1151? sure, that makes sense :-) *cough*
[19:42:43] <Colourless> has to be
[19:44:30] <wjp> weird number, though
[19:45:00] <wjp> the usecode classes indeed seem to have the hatch() event
[19:45:14] <wjp> (just above 1151, I mean)
[19:45:27] <Colourless> i just looked at some of the eggs to see what their quality value was
[19:45:40] <Colourless> then i look at the disasembly to see what class numbers they were
[19:45:50] <Colourless> and the difference was 1151
[19:48:18] <-- DarkeZzz has left IRC (brunner.freenode.net irc.freenode.net)
[19:48:18] <-- exultbot has left IRC (signing off...)
[19:49:20] --> exultbot has joined #pentagram
[19:49:20] --- Topic for #pentagram is: Pentagram: a game engine for Ultima 8 - http://pentagram.sf.net/
[19:49:20] --- Topic for #pentagram set by wjp at Sat Mar 15 22:48:22 2003
[19:50:06] <wjp> what about trigger conditions?
[19:50:27] <Colourless> eggs have a range
[19:50:41] <wjp> so they're all proximity based?
[19:50:57] <Colourless> X is upper 4 bits of NPC Num
[19:51:05] <Colourless> Y is lower 4 Bits of NPC Num
[19:52:07] <Colourless> other than that, i'm guessing the usecode controls it i think
[19:52:38] <Colourless> monster eggs have a probability
[19:52:50] <Colourless> which is q
[19:53:07] <Colourless> well part of q anyway
[19:53:44] <Colourless> it's the upper 4 bits of q (which is 16 bit remember)
[19:54:42] <Colourless> moster activity is the map num
[19:55:09] <wjp> hm, activity is probably hardcoded?
[19:55:19] <Colourless> i don't know what it means :-)
[19:55:36] <wjp> hehe "We appear to have found a new way to misconfigure a server."
[19:55:41] <Colourless> odd
[19:55:43] <wjp> (global notice)
[19:55:57] <Colourless> i don't know what MonID would be cause it's mapnum
[19:56:11] <Colourless> the ShapeType for the monster is the lower 12 bits of Q
[19:57:55] <Colourless> unless it's used by usecode, MonID is not used
[19:58:07] <Colourless> and it is :-)
[19:58:23] <Colourless> i guess then that doesn't matter
[19:58:36] <Colourless> we don't need to know what it does if the usecode is the only thing to mess with it
[19:58:52] <wjp> usecode is nice :-)
[20:02:23] <Colourless> Egg::getEggId() return mapnum
[20:02:57] <Colourless> monster activity intrinsics are unused by usecode
[20:03:40] <Colourless> but it is used by the monster egg hatch function
[20:09:48] <wjp> anyway, range-checked eggs: I'd say keep a separate list of all eggs (either per map or per (several?) chunk(s), depending on how many there are in an average map
[20:10:09] <wjp> since the range is very limited, doing it per-chunk would cause hardly any slowdown, probably
[20:10:57] <Colourless> the original game created an 'egghatcher' process for every egg
[20:11:19] <wjp> hm, we can do that
[20:11:46] <wjp> but having one process for all eggs in a map would probably be less overhead
[20:11:55] <Colourless> indeed it would
[20:12:22] <wjp> would allow for something like quad-tree-ish optimizations too
[20:12:42] <Colourless> we could just add all the eggs to a list or something and get our egg hatcher to hatch them :-)
[20:12:53] <wjp> yeah
[20:13:26] <Colourless> i don't think it will matter much how optimized they are. the original game didn't use a very optimized method
[20:14:06] <wjp> there probably aren't too many eggs around
[20:14:41] <wjp> and egg checking is done in 'user time' anyway (i.e., the user has to do something for an egg check to be triggered)
[20:18:40] <wjp> so the egg hatcher would keep a list of eggs, and the previous avatar position. It gets the current avatar position, and if it changed see if it entered any of the trigger areas. Hatch eggs if triggered.
[20:18:53] <Colourless> unk eggs (that are used to trigger monster eggs) use bit 7 of the Map num as a hatched indicator
[20:19:08] <Colourless> look at usecode function 1153
[20:19:18] <Colourless> monster eggs + unk eggs are NOT the same thing
[20:20:04] <wjp> hm, monster eggs reset themselves when you leaveFastArea?
[20:20:07] <Colourless> yes
[20:20:28] <wjp> ok, another possible headache that's handled by usecode :-)
[20:22:09] <Colourless> it looks to me that the start of game part where the camera slides in may have been something hard coded in the engine
[20:22:57] <Colourless> usecode function 1187 is what does the scrolling and triggers devons conversation
[20:23:17] <Colourless> problem is, i don't know why the camera would be 'there' and why that egg would get hatches
[20:23:25] <Colourless> s/hatches/hatched/
[20:25:01] <wjp> is there an actual egg with that quality around?
[20:25:10] <Colourless> yes
[20:25:19] <wjp> (conveniently named 'first', I see :-) )
[20:25:42] <Colourless> it's where the camera starts scrolling from
[20:26:10] <wjp> camera position may be in u8save.000 somewhere
[20:26:11] <Colourless> modiying application::setupdisplaylist() to add 1024 to lx and ly makes it visible
[20:26:26] <wjp> we need scrolling :-)
[20:28:19] <wjp> ok, it looks for the campfire, calls its enterFastArea for whatever reason
[20:28:46] <Colourless> that makes it start playing the sound :-)
[20:28:51] <wjp> ah :-)
[20:29:02] <wjp> setCenterOn(0) probably means center on avatar
[20:31:31] <wjp> or maybe not
[20:31:39] <wjp> FREE::1C6D scrolls the camera somewhere
[20:32:05] <wjp> are those hardcoded coords there? *shudder*
[20:32:48] <wjp> it's also calling Camera::scrollTo with this=0, it seems
[20:33:03] <Colourless> camera is probably static
[20:33:28] <wjp> yeah, it's unique anyway
[20:44:33] <Colourless> ah well thats enough for me, i really should have been gone hours ago :-)
[20:44:36] <Colourless> cya
[20:45:18] <-- Colourless has left IRC ("casts invisibility")
[20:45:37] <wjp> 6:15am... eek :-)
[21:12:28] <wjp> there, temp. map scrolling is in :-)
[21:12:32] <wjp> (arrow keys)
[21:12:39] <wjp> escape or q quit now
[21:13:21] <wjp> hm, weird; I just got my cvs commit mails for the map scrolling change
[21:13:35] <wjp> but not those for the bunch of intrinsics I committed 15 minutes or so earlier
[21:42:33] <wjp> ok... there urandom() and rndRange() intrinsics... but they also implemented both in (native) usecode functions...
[21:42:38] <wjp> s/there/there are/
[21:43:58] * wjp browses through some usecode to figure out the returned range of these intrinsics
[22:18:09] <-- wjp has left IRC ("Zzzz...")
[22:43:17] <-- Dark-Star has left IRC ()