#uwadv@irc.freenode.net logs for 21 Oct 2002 (GMT)

Archive Today Yesterday Tomorrow
Underworld Adventures homepage

[06:04:30] --> QQtis has joined #uwadv
[10:59:50] --> vividos has joined #uwadv
[10:59:50] --- ChanServ gives channel operator status to vividos
[10:59:54] <vividos> hi
[15:06:26] <-- vividos has left IRC ("Leaving")
[16:13:15] --> wjp has joined #uwadv
[16:13:15] --- ChanServ gives channel operator status to wjp
[16:19:56] --> vividos has joined #uwadv
[16:19:56] --- ChanServ gives channel operator status to vividos
[16:20:01] <vividos> hi there
[16:20:04] <wjp> ...again... :-)
[16:20:08] <wjp> hi :-)
[16:20:22] <wjp> (by 'again', I mean that I was only here a couple of minutes :-) )
[16:20:23] <vividos> this time I looked at the logs and saw that you just arrived :)
[16:20:29] <wjp> cheater :-)
[16:20:38] <vividos> yeah
[16:20:57] <vividos> do you know a bit how exult plays the different midi songs (or the ogg vorbis ones)?
[16:21:10] <wjp> hm, not much
[16:22:29] <vividos> well, some songs are obvious, combat, dark path, etc.
[16:23:37] <vividos> btw, using a std::list<ua_image> instead of a vector increases debug speed to about 20 seconds
[16:27:03] * vividos is away a bit, shopping
[16:27:08] --- vividos is now known as vividos|away
[16:28:26] <wjp> most of the music is triggered by 'music eggs' (I think the equivalent in UW would be a 'music trap'(?))
[16:29:58] * vividos|away is not away yet and doesn't think there's a music trap in uw
[16:49:56] --- vividos|away is now known as vividos
[16:52:54] --> QQtis_ has joined #uwadv
[16:53:00] <-- QQtis has left IRC (Read error: 104 (Connection reset by peer))
[16:53:02] <vividos> hi QQtis
[16:56:59] <vividos> it seems QQtis is not physically available
[17:13:45] --> hairyjim has joined #uwadv
[17:14:00] <vividos> hi jim!
[17:14:17] <hairyjim> Afternoon.
[17:16:06] <hairyjim> How are models coming along, then?
[17:17:00] <vividos> well, I don't understand what face planes are
[17:17:10] <vividos> the vertex (lists) are ok for me
[17:18:09] <hairyjim> The "face plane" opcode is really a backface check with a conditional branch
[17:19:40] * vividos looks in his hacking project
[17:20:42] <vividos> didn't get that yet. a face plane has a normal vector (but where is the origin?)
[17:21:39] <hairyjim> There's a normal vector and a position vector, stored interleaved
[17:21:49] <hairyjim> The origin is just the model origin
[17:22:20] <hairyjim> I don't use an interpreter as such, so I convert the backface cull opcode to a face normal for my model struct
[17:23:33] <vividos> sorry, looked at the wrong face plane :)
[17:24:46] <hairyjim> Incidentally, I have Y and Z components transposed in my specs document. Not that it makes much difference, you just need a different mod2world transform
[17:27:25] <vividos> still didn't get it. the face plane specifies a plane for culling faces?
[17:28:41] <hairyjim> 'Sright, and a point on the plane too, of course.
[17:29:50] <vividos> then faces follow, consisting of 3 or more vertices (that are stored in the vertex list), right?
[17:30:55] <hairyjim> Well, kind of. In fact, any information at all can follow the face plane, it's just a conditional branch
[17:31:25] <hairyjim> In practice, there'll usually be a colour definition and one or more polys
[17:32:47] <hairyjim> Though for a model representing a single decal the backface check comes first, and skips the ENTIRE model if it fails
[17:32:54] <vividos> the M3_UW_VERTEX_DARK, M3_UW_FACE_GOURAUD or M3_UW_FACE_SHADE types, I guess
[17:32:55] <hairyjim> (a slight optimisation)
[17:33:41] <hairyjim> M3_UW_VERTEX_DARK isn't a poly, it defines vertex shade values for Gouraud shading
[17:33:45] <vividos> where does I know how much to skip? until the next face plane opcode?
[17:34:46] <hairyjim> The first parameter to any plane opcode is the number of bytes to skip
[17:34:51] <hairyjim> Relative to the end of the plane definition, I think
[17:36:21] <vividos> ah ok
[17:43:25] <vividos> what about the sort planes? how do they work?
[17:43:44] <hairyjim> It's basically a BSP tree type thing, I think
[17:44:21] <hairyjim> The two sub-nodes are called in order depending on whether the viewpoint is in front or behind the sort plane
[17:48:01] <vividos> I don't think I'll do any bsp tree rendering; I just throw the faces at OpenGL and let it decide :) and after all, the polygons will be needed for collision detection, too
[17:48:30] <vividos> for the rest of the stuff I think I have to go through uwmodel.c again
[17:48:54] <hairyjim> Heh. I ignore sort planes also, and throw everything at the Z-buffer. Easier
[17:49:06] <hairyjim> Even Quake zbuffered its models, after all ;)
[17:49:25] <hairyjim> Though I have got a TODO to add an option not to Z-buffer models
[17:49:39] <vividos> :) seemed to bring more performance back in 1992
[17:50:01] <vividos> why that? blending?
[17:50:35] <hairyjim> Mainly to see if it speeds up any, I think
[17:50:42] <hairyjim> Probably won't make much difference
[17:51:03] <vividos> hmm, don't know
[17:51:30] <vividos> aah, I probably got it! when the viewpoint is behind the face plane, the face is not rendered! (did I get it right?)
[17:51:44] <hairyjim> Bingo!
[17:55:21] <vividos> good, so I probably can ignore that opcode, too
[17:55:47] <vividos> what's with that color address pointers?
[17:55:51] <hairyjim> So long as you get the vertex order right
[17:56:33] <hairyjim> Immediately preceding the model definitions comes 24 or 36 (for Underworld II) bytes of variables
[17:57:29] <hairyjim> The first 3 or 4 of these (16bit words of course) are the basic model colours
[17:57:57] <hairyjim> These start at 0x2920 or 0x2680
[17:58:16] <hairyjim> They're set up at the start of model processing, and differ from model to model
[17:59:32] <hairyjim> Some models also have variable colours which are specified with the object itself
[17:59:32] <hairyjim> I've not figured out the mechanism for that.
[17:59:51] <vividos> is it the table that starts with "b6 4a 06 40" ?
[18:03:55] <hairyjim> No, that's for finding the model definitions in the exe
[18:04:31] <hairyjim> It's possible to dispense with that table by parsing bits of the executable (see the attachment to my email) but that adds so much extra complexity it's probably not worth it
[18:06:08] <vividos> ok, my table starts at 0x0004cd5e, so the colour stuff probably starts at 0x0004cd46 (-24)
[18:07:29] * hairyjim looks up your build in the list
[18:07:47] <vividos> the second one
[18:08:01] * vividos just notices he got mail
[18:08:47] <hairyjim> No, the layout goes: table of offsets, variables, model base address
[18:09:13] <hairyjim> Hang on ... yes, you're nearly right, except a) the base offset is actually 10 bytes too low
[18:09:32] <hairyjim> (the 10 bytes of header information aren't treated as part of the model definition)
[18:09:56] <hairyjim> and b) that's where the colours are stored while rendering the models, not where they originally come from
[18:10:10] <hairyjim> THAT table is somewhere else entirely, in a different segment
[18:10:25] <vividos> ah, you debugged the executable?
[18:11:03] <hairyjim> Partly.
[18:11:39] <vividos> what tool did you use? IDA?
[18:12:11] <hairyjim> Hex dump ;)
[18:14:45] <vividos> aargh :)
[18:15:09] <vividos> well, the ident string of my uw.exe isn't found
[18:16:19] <hairyjim> Balls.
[18:17:06] <hairyjim> What does it say the data segment is?
[18:17:28] <vividos> 5dcc0
[18:17:52] <vividos> don't know if the uw.exe is the patched one or the original
[18:18:35] <hairyjim> I meant data segment, not data offset. It should say "mov dx, something"
[18:21:19] <vividos> sorry, $5aac
[18:24:00] <hairyjim> Hmmm. I was assuming that, though the sector values may vary, the layouts of the sectors would be identical.
[18:24:10] <hairyjim> If that's not the case, it pretty much puts paid to that idea
[18:25:51] <vividos> should I send the file to you?
[18:26:18] <hairyjim> Good idea.
[18:26:32] <vividos> tried another one and it works there
[18:27:21] <hairyjim> There are several builds floating about, tis true
[18:27:57] <hairyjim> Eep. me not familiar with IRC file transfer. Walk me through this, would you? ;)
[18:29:00] <vividos> I'm not familiar with it, too :)
[18:31:42] <vividos> I better mail it :)
[18:31:48] <hairyjim> Hang on a mo
[18:35:07] <hairyjim> I try "/dcc get vividos" but I get connection refused
[18:35:17] <hairyjim> Perhaps you better mail it ;)
[18:36:41] <vividos> could be the firewall here
[18:37:33] <hairyjim> Possible.
[18:37:41] <hairyjim> Or I could be doing it wrong
[18:44:17] <vividos> mail is halfway out :)
[18:45:39] <vividos> the other file I decoded successfully has data segment at $5c70
[18:46:00] <hairyjim> That'll be the same build as I have, so it's not surprising it works ;)
[18:47:12] <vividos> did you check the one in the uw1patch?
[18:47:40] <hairyjim> I didn't, as it happens.
[18:49:27] <vividos> it might be the one I just sent to you (mail is out)
[18:49:56] <vividos> I'm a little away now - keep me informed on your model decoding progress
[18:50:06] <hairyjim> Ought to check that, but not tonight
[18:50:20] --- vividos is now known as vividos|away
[18:50:27] <hairyjim> Just burned a CD with the latest draft of my thesis
[18:50:49] <hairyjim> Plus, entirely coincidentally, the free Blender, nasm and a bunch of Thief FMS
[18:50:56] <hairyjim> Ah well. Anyway, I'm off too now.
[18:50:58] <hairyjim> Luck!
[18:51:00] <vividos|away> heh :) bye!
[18:51:01] <hairyjim> \exit
[18:51:50] <-- hairyjim has left IRC ("Killed by BillGates (Windows Linux 98 -- jizz your pants!)")
[19:23:40] --- QQtis_ is now known as QQtis
[19:23:50] <QQtis> I am physically available once again :)
[19:24:05] <QQtis> had to sleep and go to lectures and stuff like that....
[19:24:06] <wjp> :-)
[19:24:06] <wjp> hi
[19:30:42] --- vividos|away is now known as vividos
[19:33:08] <vividos> a bit off-topic: http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
[19:34:13] --> QQtis_ has joined #uwadv
[19:34:57] <QQtis_> looks like I'm haing problems with my connection
[19:35:52] <-- QQtis has left IRC (Read error: 104 (Connection reset by peer))
[19:36:05] <vividos> hmm
[19:43:52] --- QQtis_ is now known as QQtis
[19:44:19] <QQtis> alrighty then
[19:44:25] <QQtis> how are things comming along?
[19:49:18] <vividos> well, didn't code today
[19:49:28] <vividos> the code should compile again
[19:54:13] <QQtis> it does
[19:54:24] <QQtis> but I see no difference in gameplay
[19:54:42] <QQtis> maybe its just the tools you updated?
[19:58:26] <vividos> no
[19:58:52] <vividos> the critter animations are loaded now and I'll use them to render the critters (not done yet)
[19:59:01] <QQtis> aaah
[19:59:14] <QQtis> can't wait....
[19:59:20] <vividos> btw, did you manage to play the ogg ingame yet? using a modified music.m3u?
[19:59:27] <QQtis> but aren't they gonna be just static for now?
[19:59:44] <QQtis> I mean - unless you have some AI done
[20:00:19] <QQtis> yes
[20:00:22] <QQtis> it works
[20:00:59] <QQtis> by the way - another thing I remembered
[20:01:15] <QQtis> maybe it was just the slowness of my 486 back in the day...
[20:01:29] <QQtis> but I remember the splash screens being timed a little differently
[20:01:50] <QQtis> the "Underworld" title splash came up simultaneously with the blasting trumpets
[20:03:20] * vividos tries
[20:04:34] <vividos> hmm ... the first two screens are shown less than 1 seconds each
[20:04:52] <vividos> (for the original uw1)
[20:05:20] <QQtis> really?
[20:05:39] <QQtis> maybe my machine was just slower back in the day
[20:08:23] <vividos> could be
[20:08:37] <vividos> what track do you tackle next?
[20:08:49] <QQtis> hm.. I was working on maps and legends
[20:08:56] <vividos> not bad either
[20:09:08] <QQtis> my favorite is actually the wanderer
[20:09:25] --> Dark-Star has joined #uwadv
[20:09:34] <vividos> hi Dark-Star
[20:12:17] <vividos> my favourite is probably "dark abyss"
[20:12:45] <vividos> it somehow gives the proper creepy "abyss feeling"
[20:14:49] <QQtis> I brought my Yamaha YXG50 with me this time
[20:14:59] <QQtis> I'll install it and see if it works decently on my laptop
[20:15:09] <vividos> is it a soundcard?
[20:15:09] <QQtis> it's a 1.1 or 1.3 ghz
[20:15:13] <QQtis> mabe it will handle it
[20:15:14] <QQtis> no
[20:15:20] <vividos> synthesizer?
[20:15:21] <QQtis> software MIDI emulator
[20:15:25] <vividos> ah cool
[20:15:57] <QQtis> yeah - so it drains processor power
[20:16:00] <QQtis> heheh
[20:16:11] <QQtis> that's the bad part about it
[20:16:27] <QQtis> but if that's all you are running I guess its ok
[20:16:30] <vividos> for the laptop battery :)
[20:17:00] <Dark-Star> hi all
[20:20:45] <QQtis> hi Dark-Star
[20:32:30] <QQtis> http://www.yamaha.co.uk/xg/html/midplug/m_mid8.htm
[20:32:42] <QQtis> that's what I'm using
[20:35:53] <vividos> does it eat up cpu time when it converts to wave, or all the time, e.g. when playing back?
[21:14:27] <vividos> hmm, anyone still awake? :)
[21:20:48] <vividos> QQtis, I hope the description on the "about us" page is appropriate
[21:26:19] <vividos> cool, activity in #exult :)
[21:30:02] <-- vividos has left IRC ("restart")
[21:31:35] <-- wjp has left IRC ("Zzzz...")
[21:33:01] <-- QQtis has left IRC (Read error: 110 (Connection timed out))
[21:40:24] --> vividos has joined #uwadv
[21:40:24] --- ChanServ gives channel operator status to vividos
[21:54:02] <vividos> gtg. night!
[21:54:22] <-- vividos has left IRC ("Leaving")
[22:07:21] --> QQtis has joined #uwadv
[22:11:11] <-- QQtis has left IRC (Read error: 104 (Connection reset by peer))
[22:33:18] <-- Dark-Star has left IRC ()