#pentagram@irc.freenode.net logs for 29 Apr 2004 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[04:19:53] <-- Kirben has left IRC ("System Meltdown")
[04:24:21] --> Kirben has joined #pentagram
[04:24:21] --- ChanServ gives channel operator status to Kirben
[07:39:18] --- sbx is now known as sbx|afk
[07:39:18] <-- Jett has left IRC (Read error: 104 (Connection reset by peer))
[07:39:21] --> Jett has joined #pentagram
[07:54:02] <-- Kirben has left IRC (saberhagen.freenode.net irc.freenode.net)
[07:54:02] <-- Jett has left IRC (saberhagen.freenode.net irc.freenode.net)
[07:54:02] <-- khalek has left IRC (saberhagen.freenode.net irc.freenode.net)
[07:54:02] <-- sbx|afk has left IRC (saberhagen.freenode.net irc.freenode.net)
[07:54:02] <-- wjp has left IRC (saberhagen.freenode.net irc.freenode.net)
[07:56:19] --> Kirben has joined #pentagram
[07:56:19] --> Jett has joined #pentagram
[07:56:19] --> sbx|afk has joined #pentagram
[07:56:19] --> wjp has joined #pentagram
[07:56:19] --> khalek has joined #pentagram
[07:57:44] --- Jett is now known as Darke
[07:57:46] --- ChanServ gives channel operator status to Darke
[12:23:06] <-- Kirben has left IRC (saberhagen.freenode.net irc.freenode.net)
[12:23:07] <-- Darke has left IRC (saberhagen.freenode.net irc.freenode.net)
[12:23:07] <-- khalek has left IRC (saberhagen.freenode.net irc.freenode.net)
[12:23:07] <-- sbx|afk has left IRC (saberhagen.freenode.net irc.freenode.net)
[12:23:07] <-- wjp has left IRC (saberhagen.freenode.net irc.freenode.net)
[12:23:55] --> Darke has joined #pentagram
[12:23:55] --> Kirben has joined #pentagram
[12:23:55] --> sbx|afk has joined #pentagram
[12:23:55] --> wjp has joined #pentagram
[12:23:55] --> khalek has joined #pentagram
[12:54:01] * Darke scratches his head. Looks like gcc3.4 crashes&burns on some of the template code in pentagram.
[12:57:25] <Darke> It looks more like their template code kicks the bucket, rather then the code itself being actually *wrong*, but... err... I'm not sure.
[12:59:27] <Darke> And most of the errors seem to be simply related to Args though, rather then then equally complex stuff in Console. I wonder if it is simply slightly odd code in Args...
[13:01:45] <Darke> Errr... 'istring' that is, not Args.
[13:03:36] --> Colourless has joined #Pentagram
[13:03:36] --- ChanServ gives channel operator status to Colourless
[13:03:45] <Darke> Greetings.
[13:04:02] <Colourless> hi
[13:25:43] <Colourless> i thought you weren't going to be around for a year?
[13:27:45] <Darke> I... err... got distracted?
[13:28:34] <Colourless> :-)
[13:36:40] <wjp> hi
[13:37:01] <wjp> you got distracted from not being around? impressive :-)
[13:45:50] <Darke> Err... yeah. I got distracted from being distracted.
[13:58:18] --- Colourless is now known as Cless|Away
[14:03:27] <-- Kirben has left IRC ("System Meltdown")
[14:03:33] --- khalek is now known as kh_zZz
[15:08:38] <-- Darke has left IRC (saberhagen.freenode.net irc.freenode.net)
[15:08:38] <-- kh_zZz has left IRC (saberhagen.freenode.net irc.freenode.net)
[15:08:38] <-- sbx|afk has left IRC (saberhagen.freenode.net irc.freenode.net)
[15:08:38] <-- wjp has left IRC (saberhagen.freenode.net irc.freenode.net)
[15:09:13] --> Darke has joined #pentagram
[15:09:13] --> sbx|afk has joined #pentagram
[15:09:13] --> wjp has joined #pentagram
[15:09:13] --> kh_zZz has joined #pentagram
[15:09:20] --- ChanServ removes channel operator status from Cless|Away
[16:03:57] <Cless|Away> damn that evil chanserv... it stole me ops!
[16:13:13] --> Nadir has joined #pentagram
[16:27:46] <-- Nadir has left IRC ("Client exiting")
[16:29:09] <wjp> re. gcc3.4: the release notes mentioned it being a _lot_ stricter with respect to templates
[16:30:28] <wjp> http://gcc.gnu.org/gcc-3.4/changes.html
[16:30:48] <wjp> the "C++" block about 25% from the top is rather extensive :-)
[16:41:55] <Cless|Away> well, what are the errors being caused by that istring code
[16:43:34] <wjp> without actually having gcc 3.4 installed that's a bit hard to answer for me :-)
[16:44:09] <Cless|Away> yeah well, Mr Bunny is the one who mentioned them
[18:15:50] --- Cless|Away is now known as Colourless
[18:15:55] --- ChanServ gives channel operator status to Colourless
[19:17:22] --> ElleVeeDee has joined #pentagram
[19:17:46] <ElleVeeDee> neat topic. ;-)
[19:26:18] --> ElVeDe has joined #pentagram
[19:30:15] <wjp> heh, well, if you say so ;-)
[19:30:23] <wjp> so, found pentagram I see :-)
[19:30:35] <ElVeDe> yup, heh.
[19:31:16] <wjp> I wasn't around when you asked about U8 in #exult a while ago
[19:31:47] <ElVeDe> ah. do you know lots bout U8?
[19:32:01] <wjp> well, we're somewhat familiar with it, yes ;-)
[19:32:07] <Colourless> we know more than anyone else :-)
[19:32:20] <ElVeDe> good answer.
[19:32:20] <Colourless> except maybe the original devs, but even they might have forgotten :-)
[19:32:52] <ElVeDe> I guess I have the same problem with U8 as I have with U7... the order in which to draw things.
[19:33:09] <wjp> and as with U7, that's easily the hardest part of the renderer
[19:33:12] <Colourless> it's... comlpex :-)
[19:33:22] <Colourless> s/comlpex/complex/
[19:33:50] <Colourless> the trick in both is to sort everything using a tree.
[19:34:08] <wjp> or DAG
[19:34:16] <ElVeDe> uhm? please keep talking.
[19:35:25] <ElVeDe> in what order should I sort things... and... whats a DAG?
[19:35:34] <Colourless> i'm pretty sure somewhere i wrote a document explaining this
[19:35:53] <ElVeDe> if I say pretty please, could you find it?
[19:38:14] <Colourless> The object sorting is a fairly simple process. To do it, a dependency tree is
[19:38:22] <Colourless> used. Each object is checked to see if it directly infront or behind the other
[19:38:22] <Colourless> objects.
[19:38:22] <Colourless> Basic tree construction works like this:
[19:38:56] <Colourless> // Attempt to find which is infront
[19:39:02] <Colourless> if (*si < *si2)
[19:39:02] <Colourless> {
[19:39:02] <Colourless> // si1 is behind si2, so add it to si2's dependency list
[19:39:02] <Colourless> si2->depends.push_back(si);
[19:39:08] <Colourless> else
[19:39:08] <Colourless> {
[19:39:08] <Colourless> // si2 is behind si1, so add it to si1's dependency list
[19:39:08] <Colourless> else si->depends.push_back(si2);
[19:39:09] <Colourless> }
[19:40:08] <Colourless> where si and si2 are 2 different objects. One of them is an object that is being added to the display list and the other is an object already in the display list
[19:40:22] <Colourless> when adding objects you need to do the check against every object in the display list
[19:40:44] <Colourless> Rendering then is done like this:
[19:40:51] <Colourless> void Node::Draw()
[19:40:51] <Colourless> {
[19:40:51] <Colourless> // Only if not already drawn
[19:40:51] <Colourless> if (drawn) return;
[19:40:51] <Colourless> // Draw all dependencies first
[19:40:52] <Colourless> for (Node *node = dependencies.start(); node != dependencies.end(); node++)
[19:40:54] <Colourless> node->Draw();
[19:40:56] <Colourless> // Now paint us
[19:40:58] <Colourless> shape_man->paint(this);
[19:41:00] <Colourless> drawn = true;
[19:41:02] <Colourless> }
[19:41:35] <Colourless> the tricky part of course involved working out exactly how to work out if an object is actually behind another one.
[19:41:45] <ElVeDe> but, what decides if its directly in front? its upperleft X.Y, or bottomright X.Y.. or...what?
[19:41:49] <ElVeDe> ah, yes. ;-)
[19:42:14] <Colourless> explaing it all is far too complex. You should probably look at pentagram's ItemSorter.cpp/h
[19:42:32] <ElVeDe> ok, will do.
[19:42:40] <Colourless> In ultima 8 what you need to do is sort the objects in 3d space
[19:43:13] <Colourless> you also need to take into account occlusions (which aren't properly supported in pentagrm yet)
[19:44:03] <Colourless> lastly, various typeflags also matter in regards to sort order.
[19:44:19] <Colourless> functions you would particularly want to look at would be
[19:44:29] <ElVeDe> yeah, there is a typeflag.dat - which I dont understand yet.
[19:44:30] <Colourless> inline bool SortItem::operator<(const SortItem& si2) const
[19:44:40] <Colourless> void ItemSorter::AddItem(Item *add)
[19:44:46] --> Fingolfin has joined #pentagram
[19:44:46] --- ChanServ gives channel operator status to Fingolfin
[19:44:47] <Colourless> void ItemSorter::PaintDisplayList()
[19:44:52] <Colourless> bool ItemSorter::PaintSortItem(SortItem *si)
[19:45:27] <Colourless> again, Pentagram can help you there too :-)
[19:45:44] <Colourless> TypeFlags.cpp/h and ShapeInfo.cpp/h
[19:45:50] <ElVeDe> Hope it will, unzippin the source now... ;-)
[19:46:07] <-- ElleVeeDee has left IRC (Read error: 110 (Connection timed out))
[19:46:18] --- ElVeDe is now known as ElleVeeDee
[19:46:57] <ElleVeeDee> That'll be a good start for me. I'll be back tho. Thanks a bunch.
[19:48:06] <wjp> we have zipped sources?
[19:48:45] <wjp> oh, so we do :-)
[19:48:52] <ElleVeeDee> uuhm, well there was a pentagram.zip file there somewhere...
[19:49:00] <Colourless> :-)
[19:49:02] <ElleVeeDee> heh.
[19:49:38] <Colourless> http://pentagram.sourceforge.net/snapshots/Pentagram.zip
[19:49:48] <wjp> DAG = directed acyclic graph, btw
[19:50:14] <ElleVeeDee> da heck...? english is not my first language.... acyclic?
[19:50:25] <Colourless> Can't say i've ever heard of it.... is such at thing reasonable for real time generation?
[19:50:47] <wjp> it's what we have now, as far as I know :-)
[19:51:17] <Colourless> hmm... ok :-)
[19:52:04] <wjp> multiple objects can depend on each object, and each object can depend on multiple objects, but no object should depend on itself (not even via several others)
[19:52:34] <Colourless> well, that sounds like what is used
[19:52:36] <ElleVeeDee> why, of course.
[19:52:40] * ElleVeeDee chuckles.
[19:53:45] <wjp> Colourless: I was planning to split up Configuration into a ConfigFileManager and a SettingsManager
[19:53:49] <Colourless> it is still a tree though since you traverse down the branches and begin rendering the leafs, working your way back
[19:53:59] <Colourless> wjp i saw
[19:54:24] <wjp> it's not a tree because each node can have multiple parents
[19:54:58] <Colourless> hmm. true
[19:55:33] <ElleVeeDee> correct. I have two, and Im no tree.
[19:55:35] <Colourless> i guess it is a graph then
[19:56:43] <wjp> ElleVeeDee: :-)
[19:56:47] --- sbx|afk is now known as sbx
[19:57:02] <wjp> in dutch you could take that joke a step further...
[19:57:19] <wjp> the dutch word for graph (graaf) means 'count' (as in the noble) as well
[19:57:45] <sbx> hey!
[19:57:47] * sbx is back.
[19:57:51] <wjp> wb :-)
[19:58:01] <sbx> ty!
[20:00:33] <ElleVeeDee> if typeflag.dat is 16k in size, and it supposedly consists of 8byte chunks... that means 2048 objects/shapes/whatever...
[20:00:59] <ElleVeeDee> ...but U8 doesnt have that many.
[20:01:03] <ElleVeeDee> oh, wait.
[20:01:50] <ElleVeeDee> its correct. the flexcrap header says 2048 even tho its way less. what's the deal with that? or am I clueless again? acyclic?
[20:02:48] <wjp> just be glad it has more entries than strictly necessary instead of less ;-)
[20:03:14] <ElleVeeDee> hehee, i guess. you're an optimistic fella! ;-)
[20:03:28] <wjp> you'll find most entries are empty
[20:03:52] <ElleVeeDee> yeah... which now explains why the bottom half of typeflag.dat repeats the same thing over and over.
[20:04:16] <ElleVeeDee> This is the first thing that's made sense in days.
[20:04:32] --> Cless has joined #Pentagram
[20:05:00] <-- Colourless has left IRC (Nick collision from services.)
[20:05:02] --- Cless is now known as Colourless
[20:05:04] --- ChanServ gives channel operator status to Colourless
[20:05:22] <ElleVeeDee> hey, now that you guys are awake... XMI files. You know of any software for pc that play those?
[20:05:32] <ElleVeeDee> if not, know of any that convert from XMI to MID?
[20:05:52] <wjp> hm, exult? :-)
[20:06:08] <Colourless> hmm, pentagram? :-)
[20:06:17] <ElleVeeDee> hehehe... meant more of a "stand-alone" application.... like WinAmp or sumthin like that.
[20:06:26] * ElleVeeDee waves his finger - funny guys!!
[20:06:37] <Colourless> hmm. winamp! :-)
[20:06:45] <Colourless> (seriously it does)
[20:06:55] <ElleVeeDee> uh? are you sure??
[20:07:19] <Colourless> yep
[20:07:28] <ElleVeeDee> how... did you get it to do that?
[20:07:44] <Colourless> does by default
[20:07:54] <Colourless> assuming you have a version that has the 'new' midi plugin
[20:08:08] <Colourless> been doing it since 2.8 or something
[20:08:09] <ElleVeeDee> do you know what version that would be?
[20:08:21] <ElleVeeDee> got 5.02
[20:08:45] * ElleVeeDee goes to try to play an XMI file... brb.
[20:08:57] <Colourless> should be ok
[20:09:24] <sbx> my Fallout came today
[20:09:37] <ElleVeeDee> mine doesn't... or, are all the .XMI files I have crap?
[20:10:02] <wjp> sbx: yay; Fallout good :-)
[20:10:06] <ElleVeeDee> ooh, heh, it does.
[20:10:09] <Colourless> check your input plugins. do you have the midi plugin?
[20:10:17] * ElleVeeDee punches his own nose!
[20:10:25] <sbx> DUAL JUAL: Flip Me Over
[20:10:31] <sbx> JEWEL
[20:10:48] <Colourless> both games?
[20:10:54] <sbx> yeah
[20:11:02] <ElleVeeDee> You'll be interested to know that if your XMI or MID files are named *.MDI, they wont play in WinAmp.
[20:11:19] * ElleVeeDee sticks a pencil into his ear.
[20:11:32] <Colourless> winamp recognizes filetypes based on extension
[20:11:41] <Colourless> wrong extension, it wont know what to do
[20:11:49] <sbx> xmms does that but there's a switch you can hit to change the behavior
[20:12:36] <ElleVeeDee> yeah. next time I write software to extract midi data, I'll be sure to name the files right. No typos, thats my resolution.
[20:12:55] <Colourless> the XMidi code in Exult and Pentagram auto detects the input format (but it only supports MID, RMI and XMI)
[20:13:09] <wjp> typical how there are always typos in lines about typos :-)
[20:13:47] <ElleVeeDee> heh.
[20:13:53] <ElleVeeDee> the speech and stuff in U71&2 are VOCs, what kind is used in U8?
[20:14:15] <wjp> what was it called... miles' something?
[20:14:19] <Colourless> SONARC!
[20:14:24] <wjp> oh, right
[20:14:31] <Colourless> miles sound system
[20:14:41] <ElleVeeDee> miles? the old DOS thingie?
[20:14:49] <wjp> wow, you know it?
[20:14:51] <ElleVeeDee> oh, right. U8 is old. Duuh.
[20:14:58] <wjp> ;-)
[20:15:09] <Colourless> U8's sounds are compressed in a totally undocumented format... but that hasn't stopped us :-)
[20:15:25] <wjp> you really don't want to know how we decoded it :-)
[20:15:26] <ElleVeeDee> but... I thought Miles wasnt a format... i thougth it was more a DirectSound for DOS, if you will.
[20:15:31] <wjp> (but we'll probably tell you anyway ;-P )
[20:15:46] <ElleVeeDee> pray tell.
[20:15:54] <wjp> ElleVeeDee: yeah, I was confused; the format was sonarc, as Colourless said
[20:16:12] <ElleVeeDee> oh, ok. tricky, this computer stuff.
[20:16:14] <Colourless> XMI is the MSS Midi format. The sound format that MSS used was just VOC files
[20:16:33] <sbx> k
[20:16:33] <sbx> bbl
[20:16:43] <-- sbx has left IRC ()
[20:16:54] <Colourless> the decompress the SONARC compressed sounds in u8 we read u8.exe and then emulate all the required x86 instructions to run the decode function
[20:17:37] <ElleVeeDee> eh. really?
[20:17:57] <Colourless> yep :-)
[20:18:18] <ElleVeeDee> so wjp was right, I didnt really want to know how you decoded it. ;-)
[20:19:29] <ElleVeeDee> Slight change of subject... anyone sitting on some info on U3?
[20:19:46] <wjp> hm, there's been some u3 talk on the xu4 forums recently
[20:19:49] <ElleVeeDee> specifically, dungeon.dat and exodus.bin.
[20:20:38] <wjp> the funny thing is, I have some generated U3 maps on my ultima maps page
[20:20:44] <ElleVeeDee> xu4? another remake thingie?
[20:20:45] <wjp> but I have no idea at all of how I generated those
[20:21:06] <ElleVeeDee> I think Ive done pretty much "all" of my U3 extraction, but I dont know what those 2 files are for...
[20:21:31] <wjp> hm, but I doubt I used those two files at the time
[20:22:07] <Colourless> the .bin file probably contains 'game code' and the dungeon file would contain data for the dungeon rendering mode
[20:22:08] <wjp> exodus.bin looks like code
[20:23:32] <ElleVeeDee> k
[20:24:53] <ElleVeeDee> I dont suppose you could tell me anything about the SKF files of U8 before I leave?
[20:25:48] <Colourless> sure but what i could tell you wont be much use
[20:26:39] <ElleVeeDee> there's a bunch of address offsets in the beginning, but to what?
[20:26:40] <Colourless> the are flexes, they contain modified format shapes, they contain sounds, they contain palettes, they contain a 'script' of some sort that says how to render it but i haven't decoded that yet
[20:26:51] <ElleVeeDee> first entry is 768 bytes long, so a guess would be a palette. but the rest?
[20:27:06] <ElleVeeDee> ah. ok. in other words, no easy answer. ;-)
[20:27:53] <Colourless> you know, you could have looked in pentagram's docs dir to get information about various parts of u8
[20:28:21] <ElleVeeDee> i will go do exactly that now. thanks again. later.
[20:28:39] <-- ElleVeeDee has left IRC ()
[20:30:56] <wjp> right, gcc 3.4 got past istring.h now
[20:31:11] <wjp> it was indeed what I expected
[20:31:21] <Colourless> yes?
[20:31:23] <wjp> "In a template definition, unqualified names will no longer find members of a dependent base."
[20:31:45] <Colourless> let me guess... it wan't typename somewhere
[20:31:59] <Colourless> s/wan't/wants/
[20:32:09] <wjp> no, it wants me to replace all size() calls with this->size()
[20:32:16] <wjp> and npos with _Mybase::npos
[20:32:19] <wjp> and data() with this->data()
[20:32:31] <wjp> (since those are members of a dependant base)
[20:32:51] <Colourless> most strange
[20:33:46] <Colourless> which is compliant though?
[20:33:58] <wjp> not exactly sure
[20:34:04] <Colourless> does the spec require this-> ?
[20:34:12] <wjp> name resolution and templates are complex
[20:34:17] <Colourless> i wouldn't have thought so
[20:34:53] <wjp> as you may have guessed I just installed gcc 3.4 :-)
[20:35:14] <Colourless> i'm guessing you want PCH
[20:35:17] <Colourless> :-)
[20:35:28] <Colourless> of course you make file probably isn't going to work for PCH as is :-)
[20:35:31] <wjp> actually I wanted to get rid of those compile errors :-)
[20:35:38] <Colourless> s/you make file/your makefile/
[20:36:49] <wjp> hm, even without PCH it might be faster
[20:36:51] <wjp> it's already done
[20:37:17] <wjp> now let's try PCH
[20:40:11] <wjp> and of course it refuses to build now :-)
[20:41:04] <wjp> ah, but that would be because IDataSource.h is including pent_include.h
[20:41:35] <wjp> the error it gave: filesys/IDataSource.h:24:26: calling fdopen: Bad file descriptor
[20:41:43] <wjp> pretty descriptive, no? :-)
[20:42:02] <Colourless> totally useless more like it :-)
[20:42:12] <wjp> good thing it at least gave the right line :-)
[20:44:10] <wjp> 2:45
[20:44:38] <wjp> the usecode compiler gives an ICE, though
[20:46:10] <wjp> the PCH file is 12Mb
[20:46:16] <wjp> (pent_include.h, obviously)
[20:55:45] <wjp> compared to 7:45 with gcc 3.2.3
[21:18:36] <Colourless> the usecode compiler is 'screwy' for me too as far as PCH goes
[21:19:06] <Colourless> #include "pent_include.h" is not the first 'line' in the file
[21:20:25] <wjp> gcc is _supposed_ to ignore a PCH if it can't use it
[21:20:43] <Colourless> i'm guessing you are probably defining USE_PRECOMPILED_HEADER which includes a number of common headers
[21:20:53] <wjp> hm, no, I wasn't
[21:21:04] <wjp> so that would speed it up even more? :-)
[21:21:40] <Colourless> yeah
[21:21:49] <Colourless> probably not too much though
[21:22:10] <wjp> one minor detail is that I currently can't actually _run_ pentagram when compiled with gcc 3.4 :-)
[21:22:21] <Colourless> :-)
[21:22:24] <Colourless> why not?
[21:22:51] <wjp> hm, libstdc++ version conflict
[21:26:04] <Colourless> that is.... kind of stupid
[21:29:10] <Colourless> anyway, i'm going
[21:29:12] <Colourless> cya
[21:29:14] <-- Colourless has left IRC ("casts invisibility")
[21:29:14] <wjp> night
[22:18:46] <-- Fingolfin has left IRC ("42")
[22:51:28] --- kh_zZz is now known as kh_out
[22:58:11] <wjp> Darke: pentagram should compile now with gcc 3.4
[22:58:28] <wjp> except that it's ICE-ing in the llc compiler :/
[22:58:46] <wjp> (with PCH enabled, that is)
[23:01:31] <Darke> Cool. I was just reading the conversation. *grin*
[23:07:24] --> Kirben has joined #pentagram
[23:07:25] --- ChanServ gives channel operator status to Kirben
[23:12:12] <wjp> I gcc-config-ed back to gcc 3.3 myself
[23:12:37] <wjp> (or 3.3.2, to be exact)
[23:14:11] <Darke> I'll probably spend most of my time swapping back and foward, doing my best to persist with 3.4. I've already been through this fuss when gentoo moved from 2.9x to 3.0 and I was an easy adopter. *grin*
[23:19:01] <wjp> c++ ABI changes are not my idea of fun :/
[23:19:23] <wjp> I'll probably wait until gentoo declares 3.4.x stable
[23:22:09] <Darke> Heh.
[23:26:11] * Darke disappears. Work needing going to/doing. Bye!
[23:28:21] <wjp> bye :-)