#exult@irc.freenode.net logs for 5 Apr 2002 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[09:46:29] --> exultbot has joined #exult
[09:46:29] --- Topic for #exult is: Exult: an open-source engine for Ultima 7: http://exult.sf.net/
[09:46:29] --- Topic for #exult set by wjp at Tue Apr 2 07:38:10 2002
[09:48:16] * Darke considers it's a pity that sb-x isn't here to go Ga Ga over the return of the bot. <grin>
[09:48:38] <wjp> :-)
[09:49:53] --> sb-x has joined #exult
[09:50:05] * sb-x goes Ga Ga over exultbot's return!
[09:50:08] <-- sb-x has left IRC (Client Quit)
[09:50:08] <wjp> lol
[09:50:52] * Darke giggles.
[10:52:31] <-- Kirben has left IRC ("System Meltdown")
[11:14:35] --> Kirben has joined #exult
[11:14:35] --- ChanServ gives channel operator status to Kirben
[11:21:06] --> Kirben2 has joined #exult
[11:21:18] <-- Kirben2 has left IRC (Client Quit)
[11:55:45] --> Fingolfin has joined #exult
[11:56:00] <Darke> Hi.
[11:56:08] <Fingolfin> yo
[11:56:12] --- ChanServ gives channel operator status to Fingolfin
[11:56:13] <wjp> hi
[11:59:51] * Darke wonders if it's more efficient to load+parse the usecode, and only store the fully parsed usecode in memory. Or to load and only doing basic parsing (putting each opcode+params into a vector/bytearray just as raw bytes), then parsing it as it executes. The first will use more ram, and will be faster when it executes, especially for tight loops.
[12:00:08] <Darke> The second will take less memory, but will be 'slower' when executing. Hmm...
[12:02:29] <Darke> Actually, in the first case if you use a union, like the original U8 would have, to store the int/string/whatever it might actually be a similar memory size to the second.
[12:04:49] <wjp> what do you mean by "fully parsing" ?
[12:06:33] * Darke tries to find a sufficiently complex, but not too complex opcode to explain. U8 usecode is _so_ much nicer then U7's. <grin>
[12:06:49] <wjp> indeed it is :-)
[12:10:53] <Darke> Ahh. Ok, take 0x0C 'push long'. 'Fully parsing' it, would take the four bytes of parameter, and turn it into a single 'unsigned int' and store it in memory in a structure that would look something like `union Vars { uint8 i8; uint16 i16; uint32 i32; }; class OpPair { uint8 opcode; vector<Vars> params; };` With the opcode set to 0x0C, and the first value of the parameter set to be the uint loaded.
[12:12:08] <Darke> Whereas the other option, the 'OpPair' class would look more like `class OpPair { uint8 opcode; vector<unsigned char>data; }` You would have to parse data yourself when executing;
[12:12:18] <Darke> s/executing;/executing./
[12:14:49] --> Colourless has joined #Exult
[12:14:49] --- ChanServ gives channel operator status to Colourless
[12:15:00] <Colourless> hi
[12:15:17] <Darke> So if you were trying to get a function from the usecode cache, whether you were either executing it, or just to print it out, you'd call a 'find' function, that would return a `const UCFunction &` (or UCSubFunction, or whatever), which would probably be a basic 'this is the function information', plus a vector<> (or whatever) of the OpPair classes.
[12:15:19] <Darke> Hi.
[12:17:12] * Darke is still juggling whether it'd be more logical to execute the function from memory (whether 'parsed' or 'non-parsed') or from disk, relying on the disk and os cache to make the execution quick.
[12:18:14] <Colourless> non parsed in memory is what i would do :-)
[12:18:20] <Colourless> even though i've no clue what you are doing
[12:18:59] * Darke is doing the same thing he does every night... confuse everyone. <grin>
[12:19:16] <Colourless> if done using an exult data_source class it would be simple to change it to read from disk rather than from memory
[12:19:53] <Colourless> s/data_source/DataSource
[12:22:13] <Darke> If we parsed and loaded only the usecode needed on a 'level', at the beginning of the level, (like the opengl.txt file is suggesting to do for shapes/globs), the 'parsing' it would make sense.
[12:22:50] * Darke is working on that usecode loading/caching system still.
[12:23:34] <Colourless> how would you work out what was required though?
[12:24:27] <Colourless> i relation to shapes it's easy... but i'm talking about things like utility functions
[12:24:33] <Colourless> s/i/in/
[12:25:24] <Darke> You'd need to load the usecode to 1) all the spells you know 2) All the items on your person 3) All the items in the 'level'. As you load up all these usecode functions. You note the ones that call other ones, and load those recursively.
[12:25:37] <Fingolfin> I wouldn't trust the OS / HD cache, but rather would cache the stuff myself - a HD cache is general, it never will know as good as you do what should be cached and what not
[12:26:18] <Fingolfin> how much RAM do we talk about anyway when we talk about "loading it all during start" ?
[12:26:23] <Darke> It doesn't stop you from dynamically loading them in the game. I'm planning that a call to the 'find()' function will get it to try and load it from the disk, if it isn't in the cache.
[12:26:29] <Colourless> also usecode REALLY need execute fast
[12:26:54] <Fingolfin> there are two concerns with loading it all during start, I think: 1) memory - no big issue today, and 2) start time - not nice to have this long, but better than slow run time
[12:26:58] <Colourless> waiting for the os to read the usecode from the HD will be annoying
[12:26:58] * Darke nods. That's why he's considering preloading it and pre parsing it. So you can have a very tight loop when you're executing it.
[12:27:33] <Fingolfin> how mcuh mem would the full usecode take, parsed etc.? roughly
[12:27:52] <Darke> (start time) Yep. I'm definately hard coding the parsing at the moment, just because it's much simpler then something like ucxt which needs much more data.
[12:27:53] <Fingolfin> i.e. 1 MB? 10? 100? :-)
[12:28:03] <Colourless> also what exactly do you mean by parsing?
[12:28:39] <Colourless> u8's usecode is a fairly simple bytecode and could be executed quickly without parsing
[12:29:19] <Darke> (memory) For the entire SI usecode file, ucxt very inefficiently uses 20Meg. But it's got three copies of the usecode file, plus all the configuration data in there at that time. <grin>
[12:30:00] <Darke> (parsing) I described parsing just before you came it. It should be in exultbot's logs, but I can cut&paste from the scrollback if you wish.
[12:30:12] <Colourless> i'll look in the logs
[12:31:16] <Colourless> hmm sounds like you are over engineering the interpreter
[12:31:40] <Fingolfin> hm... I dunno, but I can't imagine it would be that bad to just keep the usecode "raw"... but then it's not me working on this stuff, so I am not one to judge it :-)
[12:32:12] <Colourless> i agree with Fingolfin here
[12:32:25] <Fingolfin> Colourless: which part? =)
[12:32:27] <Colourless> i find no advantage with parsing the usecode
[12:32:33] <Darke> (usecode) <nod> The parsing is very simple too. I was just considering the 'special cases'.
[12:32:47] <Fingolfin> well
[12:33:19] <Fingolfin> if we keep the code modular and clean enough, then we can just start out "raw", and if determine later that it's better to do "pre-parsing", we can replace that module w/o problems
[12:33:41] * Darke also happens to think that having it 'raw' would be quicker. He's also just juggling things like seperating the knowledge of the structure, from the execution of the usecode.
[12:36:04] <Fingolfin> well, if you were to create a new scripting/bytecode language
[12:36:06] <Darke> For example, if the loading, was completely seperate from the execution in exult. You could (if the world was perfect) just increase the size of all the opcode data from 16 to 32, completely transparently from the execution. You technically wouldn't need to use new opcodes, just have a note in the function header for those one or two functions to load in 32bits rather then 16bits.
[12:36:15] <Fingolfin> but we are trying to cope with existing stuff, after all
[12:36:27] <Fingolfin> hm yeah
[12:36:53] <Fingolfin> but it's very easy to overplan and overdesign, I'd be careful :-)
[12:36:55] <Darke> <nod> That's why I'm throwing ideas out. <grin> Lots of theories and perhaps one or two that would make sense or work.
[12:37:00] <Colourless> hmm, well what are you intending to do with the interpreter?
[12:39:39] * Darke has not really done much planning on the interpreter at the moment. The only thing he's working on is a simple command line 'tester' of this Cache, which looks to be gradually turning into a gdb look alike. <grin> He might add some basic 'step through' debugging/executing to it as it grows.
[12:40:32] <Colourless> have you calculated things like the average opcode size and the largest opcode size?
[12:41:26] <Colourless> average opcode size btw is for the usecode file itself
[12:42:13] * Darke hasn't yet. He's within an hour's work of implementing the usecode loading code, thus the questions.
[12:43:56] <Colourless> Hmm, ok. I doubt any of use have helped you much have they. :-)
[12:45:28] <Darke> What? Helped me get code done now? Or helped me not waste a week of coding doing something that was either the Wrong Thing or just useless? <grin>
[12:51:19] <Colourless> as far as I can tell your main problem you will face will be with jump instructions. if you change the size of the opcodes it will be *annoying* to handle jumps
[12:52:07] <Colourless> when using raw bytecode you can just do IP+=offset
[12:52:48] <Colourless> using a parsed usecode you'll obviously need to resolve all the jumps before execution
[12:55:46] <Colourless> it's not a difficult thing to do, but it will slow down loading quite a bit
[12:57:54] <Darke> Hmm... noted. With parsed usecode, you'd need a two pass loading. The first to load all the opcodes and create a map from the offset to the list index. Then a second pass to walk through the usecode and replace the 'offset' for all the jumps to be the 'index' to the opcodes list. That could be a little slow.
[12:58:56] <Colourless> also how would you store the parsed opcodes?
[13:05:58] <Colourless> any method that uses linked lists will have extremely slow jumps when being interpreted
[13:05:58] <Darke> (opcode/data storage) The same way you'd probably store values pushed onto the stack, as a union of all the possible types and a flag to tell you which one. Although the flag won't be necessary with the parsed data, since it'll be 'obvious' to the interpreter what type of data it is.
[13:05:58] * Darke nods. He's thinking vector<> but vector has problems enlarging and such, so you'd need good guesses as to how big the function is going to be, from the size of 'code size' of the function.
[13:05:58] <Colourless> u8's stack work just the stack of a real processor
[13:05:58] <Colourless> s/work/works/
[13:08:25] <Colourless> a proper implementation would just be a buffer with stack and base pointers pointing to the top of the stack with it growing downwards
[13:08:38] <Fingolfin> indeed, trivial enough to implement
[13:09:12] * Darke nods. Elements are pushed on in 2 byte pairs or something, then things and reference (end of stack)-2 or -4 or whatever?
[13:09:36] <Colourless> variables as bp-num and arguements are bp+num
[13:10:42] <Darke> Thanks. Foggy memory.
[13:16:36] <Colourless> also the stack should be implemented using little endian numbers. i say this because the usecode may for example push a 32 bit int and then pop 2 16 bit ints or whatever.
[13:17:06] <Colourless> i really doubt it would actually do that though
[13:17:55] --> Dominus has joined #exult
[13:18:05] --- ChanServ gives channel operator status to Dominus
[13:18:08] <Colourless> hi
[13:18:08] <Dominus> hi
[13:19:08] <Dominus> any idea how to make the manuals by Robbe in our Patch tracker somewhat readable for non-Unix users?
[13:19:26] <Fingolfin> hi Dominus
[13:20:43] * Darke hmms... so if the stack was reimplemented identically to the original, he'd need to either parse into 16bit chunks, or use raw. He guesses strings would have been handled by u8 mallocing a char[] and copying the string data into there, then dropping that into an array, then using the index from that array as the value to push onto the stack.
[13:20:52] <Darke> Hi Dominus.
[13:22:03] <Darke> Ack. Or just push the char* directly to the stack, since the pointers are all 16bit.
[13:22:29] <Colourless> actually the pointers are 32 bit. 16 bit offset + 16 bit segment
[13:22:59] <Colourless> however that doesn't matter
[13:23:06] <Darke> Thanks.
[13:25:10] <Colourless> actually.... just wait a sec on that
[13:27:40] <wjp> pointers are somewhat weird in U8
[13:28:01] <wjp> the actual pointers are 32 bit, but they're often stored as some kind of 16 bit reference, from what I can tell
[13:28:03] <Colourless> 0D push string
[13:28:04] <Colourless> 6B str to ptr
[13:28:33] <wjp> these 'references' have to be converted to 'real' pointers when they're passed to intrinsics
[13:28:50] <wjp> (that's what 'str to ptr' does for string refs)
[13:31:59] <wjp> Dominus: about those manpages: do you have groff?
[13:32:23] <Dominus> nope
[13:32:32] <wjp> cygwin?
[13:32:39] <Dominus> nope :-)
[13:32:47] <wjp> nroff? troff? ;-)
[13:33:10] <Dominus> never could get into that but if you recommend that I can try
[13:33:30] <wjp> I wish I could recommend cygwin, but it was slow as hell when I tried it
[13:33:44] <wjp> Linux, OTOH, I can really recommend :-)
[13:33:50] <Dominus> he he
[13:34:07] <Colourless> note he said "for non-Unix users"
[13:34:32] <Colourless> using linux wouldn't exactly class him as a "non-Unix user"
[13:34:34] <Colourless> :-)
[13:34:36] <wjp> yeah, Linux is perfectly capable of transforming it to ascii :-)
[13:34:46] <Colourless> neither would cygwin either really :-)
[13:34:54] <Fingolfin> Linux isn't a Unix, though, strictly spoken :-)
[13:34:56] <Dominus> so I take it that with groff you can output the file in a readable format and probably just copy pasting that would work
[13:35:52] <Fingolfin> Abort (core dumped)
[13:35:56] <Fingolfin> how i love that, sigh
[13:36:06] <Dominus> so, is anybody interested to just take a look at those manuals and put them in readable format into the source? :-)
[13:36:08] * Fingolfin removes another 200 MB core file from his HD
[13:36:21] <Colourless> Fingolfin: can't you disable that?
[13:36:27] <Dominus> or even if nobody is interested would anyone do it anyway? :-)
[13:37:11] <wjp> ascii, html, utf8?
[13:37:24] <wjp> dvi?
[13:37:26] <wjp> ps?
[13:37:33] <Dominus> :-)
[13:37:37] <Fingolfin> Colourless: yeah I guess I can somehow, just to lazy to look it up. I never got core dumps before two days ago (that was when I updated glib 2.0.0 to 2.0.1 -> they have this nice feature in the new version that makes a core dump if you say 'g_print("test")' and your locale is not set to C, really... funny
[13:37:38] <wjp> any preference?
[13:37:39] <Dominus> ascii
[13:38:28] <wjp> hm, that seems to be the trickiest one
[13:38:36] <Dominus> he he
[13:38:38] <wjp> it keeps putting formatting codes in there
[13:38:50] <Dominus> anything that is readable
[13:39:05] <Colourless> so these docs are man pages?
[13:39:11] <wjp> yeah
[13:39:13] <Dominus> for example html can be easily formatted into text
[13:40:52] <Darke> Fingolfin: Maybe `ulimit -c 0`? Admittedly not likely to work, but...
[13:40:52] <Colourless> hmm... man pages = bad :-)
[13:41:00] <wjp> ugh... html pages don't come out that well either
[13:41:02] <wjp> *sigh*
[13:41:13] * wjp kicks troff... stupid thing
[13:41:19] <Fingolfin> well
[13:41:39] <Fingolfin> if you wnat man->html, don't use troff for that :-) there are some special tools to generated HTML from man pages which actually give quite good results
[13:43:06] * wjp notices he has a 'man2html'
[13:43:26] <Colourless> My Computer->Properties->Advanced->Startup and Recovery->Write Debugging information->Small Memory dump (64k) :-)
[13:43:46] <Colourless> such an option would be useful for you Fingolfin
[13:44:46] <Darke> Or a makefile that automatically runs 'rm -f core' in the appropriate directory, when you recompile. <grin>
[13:44:54] <Fingolfin> hehe, I know there is an option, just too lazy to look it up
[13:45:55] <wjp> ulimit -c 0?
[13:47:48] <Fingolfin> that would be here: "limit coredumpsize 0"
[13:48:23] <Fingolfin> and in fact this is the default
[13:48:24] <Fingolfin> ah!
[13:48:26] <Fingolfin> I know what happend
[13:48:50] <Fingolfin> I did an "unlimit" in those windows, since glib uses a biiig stack size, so I have to unlimit the stack
[13:49:12] <Fingolfin> but since I was lazy, I didn't type "unlimit stacksize" but just "unlimit", hence I get coredumps only when I work on glib2 stuff =)
[13:49:20] <Fingolfin> or gtk-quartz like now
[13:50:02] <wjp> tcsh?
[13:50:43] <Fingolfin> aye, default shell here. got used to it, like it more than bash now :-)
[13:51:11] * wjp just switched from tcsh -> bash
[13:51:53] <wjp> tcsh's scripting really started to annoy me after a while
[13:53:19] <Fingolfin> I am not using it for scripting
[13:54:15] <wjp> I'll bbl
[13:54:17] --- wjp is now known as wjp|away
[14:25:30] --- wjp|away is now known as wjp
[14:31:38] <Dominus> he he
[14:31:48] <Dominus> I found man2html for Windows as well
[14:32:23] <Dominus> so if you are not doing it I can do it (put those manuals into CVS)
[14:32:59] * wjp is not doing it :-)
[14:33:11] <Dominus> ok, I'm volunteering :-)
[15:11:01] * Darke notices that his 'quick hack' of a program to test his usecode caching class is actually completely, if a little succinctly, documented.
[15:13:59] * Darke is not sure if he should be scared, or in awe of this fact. Or if he should suddently change everything around so that said documentation is completely inaccurate, can't have people actually _knowing_ how to use the program, can we? <grin>
[15:14:14] <Dominus> :-)
[15:18:56] * Darke notices an incompletely documented feature, and feels the strange compulsion to document it correctly.
[15:19:20] <Dominus> Hey, do it! No one is holding you back :-)
[15:29:14] <-- Darke has left IRC (calvino.openprojects.net irc.openprojects.net)
[15:29:55] --> Darke has joined #exult
[15:31:40] * Darke completes the documentation, and corrects a previous 'bug' in the docs. Then gets the feeling someone just said 'Good rabbit' and petted him on the head. <blinkblink>
[15:31:58] <Dominus> Good rabbit
[15:32:07] * Dominus pets Darke on the head
[15:36:15] * Darke purrs, and adds a `to get help type 'help'` banner to display when the program starts, just for Dominus. <grin>
[15:36:47] <Dominus> :-)
[15:38:09] <Darke> Currently the docs are imbedded as a 'help system' into the program. Theoretically, I'll produce 'proper' docs, probably cut & pasted and tidied up from the code, sometime in the future if this does eventually do something other then be an 'interesting' toy. <grin>
[15:38:33] <Dominus> no one reads docs anyway :-)
[15:38:58] <Dominus> just something so we can say we are well documented
[15:40:06] <Darke> And as something to point at when the 43rd person on the forum asks the same question... *grin*
[15:40:59] <Dominus> maybe I should put that in the FAQ: Why are you writing this? So I can politely tell you to RTFF!
[15:42:50] * Darke suggests putting that under section '42'.
[15:43:15] <Dominus> :-)
[15:44:31] <Darke> Go on. Hurry up.
[15:45:09] * Darke thinks it'd be a perfect addition to the FAQ. <grin>
[15:48:31] <Dominus> seriously what I really need to do is a "language check" so people know what we are talking about when we mention stuff like "usecode", "gumps", "shapes", "flexes" and such
[15:49:21] <Dominus> these are kind of our everyday language but no outsider knows what these are
[15:52:59] <Darke> Agreed, that would certainly be helpful. Just another section of the FAQ? Or another document itself?
[15:54:43] <Dominus> I guess either in the Docs or FAQ (probably Dosc in the introduction section)
[15:55:44] <Dominus> I always think it is needed but when I do an update I forget it again
[15:55:59] * Darke nods. Intro to Docs looks ok.
[15:56:10] <Dominus> But now it is in my usefull text file where I store the stuff I need to add
[15:57:16] <Darke> One thing, under Docs 4.2, it mentions 'Bilinear' is only 2x, but there's no mention if 'BilinearPlus' is 2x or not. I've never used it so I'm not sure though...
[15:57:46] <Dominus> me neither, but I guessed from it that it should be so if it is based on bilinear
[15:57:52] * Darke tries to test it but doesn't have a compiled version of exult at the moment.
[15:58:23] * Dominus ahs his hands full at the moment
[15:58:41] <Darke> NP. I should have a working version in a few minutes.
[15:58:51] <Dominus> my girlfriend picks me up in about 10 minutes and I have to do some stuff until then
[16:11:19] <Dominus> ok, got to go!
[16:11:23] <Dominus> see you!
[16:11:28] <-- Dominus has left IRC ("Exult! Exult! Exult!")
[16:11:28] <Colourless> bye
[16:17:59] <Darke> Nope. BilinearPlus does not seem to like anything other then 2x.
[16:40:31] * Darke commits and waits for people to complain that it's not 'working as documented'. <grin> Or rather waits for wjp to complain anyway, since it's not going to work 'right' under anything but linux at the moment.
[16:40:48] <Colourless> well that's just poor coding :-)
[16:41:58] * wjp wonders why he should complain if it works under linux ;-)
[16:42:22] <Darke> Colourless: Nah. It's just me being lazy. <grin> I don't suppose there's anything in MS's libraries that's as easy to use as 'readline'? That is, a one line call that returns some form of char* gotten from stdin? I know I can use getline() to do the job, it's just so ineligant. <grin>
[16:47:54] <Darke> Fingolfin: I don't suppose the GNU 'readline' library exists under OSX? `man readline` should produce something if it is.
[16:48:13] <Fingolfin> Darke: ...
[16:48:19] <Fingolfin> Darke: I do have readline installed
[16:48:24] <Fingolfin> http://fink.sf.net
[16:48:31] <Fingolfin> I also have Gnome installed, for that
[16:48:36] <Fingolfin> just FYI =)
[16:48:44] <Fingolfin> and I can always static link readline if necessary
[16:51:33] <Darke> No problem. <grin> OSX is just that weird GUI unixy thing to me at the moment, I should probably get some experience with it sometime in the future.
[16:57:05] <Darke> Hmm... and cygwin comes with readline. But that's probably not going to help, since we use mingw to compile IIRC.
[17:00:33] <Kirben> there is readline port for mingwhttps://sourceforge.net/project/showfiles.php?group_id=7382&release_id=45655
[17:06:20] --- wjp is now known as wjp|dinner
[17:07:22] <Darke> Thanks. Want me to make the modifications to Makefile.cygwin, but not include it in the `tools:` make list?
[17:08:16] * Darke is going to commit the changes that _hopefully_ will let it work under OSX in a few minutes, he can commit that whilst he's at it.
[17:14:39] <Kirben> ok
[17:22:20] <-- Kirben has left IRC ("System Meltdown")
[17:34:30] * Darke commits and decided that going to sleep soon is probably a good idea. His keyboard is looking comfortable.
[17:35:12] <Colourless> cya
[17:37:08] <Darke> Night. <bow>
[17:37:11] <-- Darke has left #exult ()
[17:56:38] --- wjp|dinner is now known as wjp
[18:52:37] <Colourless> hmmm my interpreter seems to now partly work.... dcmp8 decompression pass 1 actually works
[18:53:04] <Colourless> pass 2 is a different matter all together though.... something isn't quite working there yet
[18:54:18] <Fingolfin> Colourless: so what are you doing? are you writing a mini x86 interpreter or what?
[18:54:25] <Colourless> Fingolfin: yeah
[18:54:40] <Fingolfin> Colourless: ok, so you use data from the installed u8.exe or something?
[18:54:48] <Fingolfin> I just wonder, couldn't there problems with different versions...
[18:55:04] <wjp> the dcmp code is the same in both versions, I would think
[18:55:06] <Colourless> yeah i've thought about that myself
[18:55:06] <Fingolfin> like the updated one vs. the original buggy version, and also maybe english<->french<->german
[18:55:16] <Fingolfin> wjp: dunno, no way for me to look ATM
[18:55:25] <Fingolfin> my machine refuses to mount my U8 CD :-/
[18:55:29] <Fingolfin> still
[18:55:31] <wjp> still? :-(
[18:55:42] <Fingolfin> I really need to go to a friend and get a disk image or something, hrm
[18:55:54] <Fingolfin> but I had no time yet to do this (or maybe I had time, but then I didn't think of it :-)
[18:55:56] <Colourless> well if someone has some 2.13 exe's from and the prepatch version.... sending them to me might be a nice idea :-)
[18:56:03] <Colourless> i have v 2.12
[18:56:23] <Fingolfin> anyway, you could worry about this later
[18:57:12] <Fingolfin> Colourless: e.g. you could do checksums over the files, and store a map from checksum -> function offset or so
[18:57:21] <Colourless> the location of dcmp8 isn't hard coded in my program, i attempt to locate it by searching for "Copyright 1993 Speech Compression; all rights reserved"
[18:57:22] <Fingolfin> unknown versions of U8 would just give a warning, and no sound, or something
[18:57:28] <Fingolfin> ah cool
[18:57:48] <Colourless> i then read the exe's segment table to ensure that I use the proper offsets
[18:59:12] <Colourless> the dcmp8 functions were coded in asm so i don't think they will vary between versions
[19:01:10] <Fingolfin> yeah
[19:01:35] --> freedman has joined #exult
[19:01:35] --- ChanServ gives channel operator status to freedman
[19:01:38] <Fingolfin> except for the legal reasons, you could rip it out; but it's of course much better to require the orignal .exe, reduces the chances of getting banned
[19:01:41] <Fingolfin> hi jeff!
[19:01:45] <freedman> Hi!
[19:01:46] <Fingolfin> s/banned/sued/
[19:01:46] <wjp> hi!
[19:01:49] <wjp> long time no see :-)
[19:01:58] <freedman> Hello!
[19:02:04] <Colourless> hi
[19:02:28] <freedman> Work was wasting my time:-)
[19:03:43] <Colourless> and you think you might do something productive here?
[19:04:01] <Fingolfin> freedman: be careful what you say, or we end up hoping you get laid off 8-)
[19:04:03] <wjp> :-)
[19:04:32] <freedman> Nope. But it's a good way to waste time before lunch:-)
[19:05:38] <wjp> btw, the IRC redirect I put up last time is still up. (in case you're IRCing through telnet now)
[19:05:51] <freedman> Okay, let me try it...
[19:06:29] <wjp> although latency might be kind of bad, atm... (*looks at download filling up bandwidth*)
[19:07:13] <freedman> Got to be better than teleporting to my ISP... that's the main reason I usually don't do IRC.
[19:09:23] <freedman> Doesn't seem to be working (port 8080?)
[19:09:34] <wjp> wjp.2y.net, port 23
[19:09:42] <freedman> Anyway, how's Pentagram going? Can I play yet? How about multiplayer:-)
[19:09:53] <wjp> lol, dream on :-)
[19:10:13] <freedman> Sorry... been reading the Forum for too long.
[19:10:29] <wjp> is your IP still 157.95.10.138?
[19:10:48] <freedman> Yes
[19:11:02] <wjp> I'm not getting any traffic from that IP
[19:11:25] <freedman> Something to do with the firewall, probably.
[19:12:04] <wjp> *sigh*.. ah well, it was fun while it lasted :/
[19:12:34] <freedman> :-) They're always fiddling with it. Good thing my old ISP still provides a shell login.
[19:14:07] <freedman> BTW, could that WinXP problem have anything to do with the zlib bugs being found? There's a new one mentioned on linuxtoday.
[19:14:28] <Colourless> what's the new one?
[19:14:43] <freedman> "Double Free in zlib"
[19:14:50] <wjp> same one, I think
[19:14:52] <Colourless> hmm, that's pretty bad :-)
[19:14:56] <wjp> Caldera is just a bit late, it seems :-)
[19:15:11] <freedman> :-)
[19:15:23] <Colourless> from what i knew, that only occured with a malformed zip file
[19:15:46] <wjp> yeah, this doesn't occur 'naturally'
[19:15:49] <freedman> Any idea what's causing our problem?
[19:15:52] <Colourless> unless we are producing malformed zips, the bug shouldn't effect us
[19:16:16] <freedman> I'm just looking for something to blame besides our own code:-)
[19:16:34] <Colourless> well, it doesn't make too much sense for it to be our code actually :-)
[19:16:48] <Colourless> of course monsnpc.dat seems to grow a little large
[19:17:35] <Colourless> actually saying a little large is an under exaggeration... it gets pretty damn huge
[19:17:49] <freedman> Uh oh... that doesn't sound reasonable.
[19:18:19] <Colourless> in the most recent problem savegame, monsnpcs was over 200k
[19:19:20] <freedman> I think that get's written from a global list. But since we purge monsters that are more than a chunk away, that doesn't sound right.
[19:19:52] <Colourless> exactly
[19:20:14] <wjp> where's the code that should purge them?
[19:20:44] <freedman> I think it's the emulate_cache() code in gamewin.cc.
[19:21:36] * wjp wonders if he screwed something up when ensuring NPCs are never deleted
[19:21:48] <wjp> (the main numbered ones, that is)
[19:23:58] * wjp probably did
[19:24:23] <wjp> so who didn't tell me a Monster_actor is inherited from Npc_actor? :-)
[19:24:51] <Colourless> you !
[19:24:55] <freedman> All of us:-)
[19:27:39] * wjp notices that the monster list is updated in the Monster_actor destructor
[19:28:16] <wjp> that "never delete" probably only goes for the numbered NPCs, right?
[19:28:31] <Colourless> yeah i would guess so
[19:28:35] <wjp> so a check for npc num != -1 should be ok?
[19:28:46] <Colourless> yeah should be
[19:28:59] <wjp> (-1 was the default, right?)
[19:29:11] <Colourless> -1 = no npc num
[19:31:20] <freedman> That global list has had lots of problems. Maybe the 'write' routine should just search surrounding chunks for monsters to save.
[19:31:57] <Colourless> in Silver Seed the NPCs are all monsters that aren't temporary
[19:32:20] <Colourless> just saving in the surrounding chunks won't save them :-)
[19:32:42] <wjp> wow, a 380Kb monsnpcs.dat here
[19:32:46] <freedman> Yes. I'd hate to mess that up.
[19:33:17] <freedman> Heh. They're accumulating throughout the game.
[19:33:19] <Colourless> ok, just noticed another problem with the monsters
[19:33:47] <Colourless> they are only removed from the linked list once they are being deleted
[19:33:59] <wjp> yes, that's what I said :-)
[19:34:03] <Colourless> however they only get deleted once a removed->flush(); is done
[19:34:36] <freedman> Ugh. They're also not deleted when they die.
[19:34:46] <Colourless> they should get removed from the list as soon as a remove is done
[19:35:16] <Colourless> and when they die too :-)
[19:35:18] <freedman> Yes. And have their links set to 0 so they don't get removed twice.
[19:36:55] <freedman> Also, what if a Usecode function removes a monster and then adds it back? I guess move() should add to the list if it's not already linked.
[19:37:24] <Colourless> remove_this
[19:37:24] <Colourless> (
[19:37:24] <Colourless> int nodel // 1 to not delete.
[19:37:24] <Colourless> )
[19:38:13] <Colourless> when usecode removes an object remove_this(1) is called so the object is removed from the world, but not deleted
[19:38:24] <freedman> Ryan: Do the SS NPC's get flushed out when you walk away from them?
[19:38:31] <Colourless> no they don't
[19:38:52] <Colourless> the usecode clears the is_temporary flag on them as soon as they are created
[19:40:24] <freedman> Okay. Maybe I'll rewrite the monster-list handling so it links/unlinks when the monster is added/removed from the world.
[19:40:35] <freedman> Having it in the constructor/destructor was bad coding.
[19:40:41] <Colourless> what we could also do is not save and not load all npcs are are not around the avatar that have is_temporary flag set
[19:41:12] <Colourless> in fact, we should do what i suggest anyway to clean up everythongs monsnpc.dat
[19:41:30] <Colourless> hmm. interesting word i typed then :-)
[19:41:47] <Colourless> s/everythongs/everyones/
[19:41:50] <freedman> :-) That seems like it would work.
[19:42:19] <freedman> I'll rewrite the list-handling tonight.
[19:42:39] <freedman> (Then I'll fix all the new bugs in the next week:-))
[19:43:22] <Colourless> :-)
[19:45:37] <freedman> Time to break for lunch.
[19:45:40] <freedman> Bye
[19:45:45] <Colourless> bye
[19:45:46] <-- freedman has left IRC ("Leaving")
[20:16:19] --> artaxerxes has joined #exult
[20:16:32] <artaxerxes> hi all
[20:17:15] <artaxerxes> I've got news regarding the translation.
[20:17:22] <Colourless> hi
[20:17:51] <artaxerxes> We are probably going to move to SF too. Name: si-french (if accepted)
[20:18:14] <artaxerxes> I realise not having CVS is such a pain
[20:19:20] <artaxerxes> We are also getting close to be ready to politely ask the exult team to add a link to our site. :)
[20:21:16] <artaxerxes> ?seen talking_people
[20:21:16] <exultbot> I haven't seen talking_people lately
[20:21:28] <artaxerxes> :)
[20:21:30] <Colourless> well fancy that :-)
[20:24:11] * artaxerxes has never seen the exult team that quiet.. :/
[20:24:23] <artaxerxes> do I come at a wrong time ?
[20:24:56] <Colourless> i don'think anyone is actually here paying any attention
[20:25:49] <artaxerxes> friday late afternoon.... yes... the worst time
[20:27:06] <Colourless> there is no one here in that time zone
[20:27:16] * artaxerxes is :)
[20:27:27] <Colourless> you don't count :-)
[20:27:33] <artaxerxes> as usual! :)
[20:28:34] <artaxerxes> btw, did you read my comment on the phorum about the intrinsic hard coded phrases ? Jeff said it is planned... but before or after 1.0 ?
[20:28:36] * Fingolfin pops in for a sec, says "hello", and goes back to coding
[20:29:16] <artaxerxes> hi Fingolfin.... I'd rather you code than you loose time in idle chat ! thx for the headsup!
[20:29:18] <Colourless> artaxerxes: don't know
[20:29:52] <Colourless> jeff was here and left about 30 mins before you entered
[20:30:19] <artaxerxes> it'll become a more crucial issue when we are done translating and debugging our texts...
[20:30:43] <Colourless> what string are you talking about anywat
[20:30:44] <artaxerxes> I just wanted to make sure you guys knew about that pb.
[20:31:27] <artaxerxes> in intrinsic.cc
[20:32:16] <wjp> hm, I only see debugging strings
[20:32:36] <artaxerxes> phrases that are said when for instance you want to sleep in an occupied bed
[20:32:42] <artaxerxes> that's hardcoded
[20:32:55] <wjp> ah, there
[20:33:21] <wjp> aren't those supposed to be in text.flx somewhere?
[20:33:25] <Colourless> much of that is probably supposed to be read from text.flx
[20:33:25] --- wjp is now known as wjp|away
[20:33:30] <wjp|away> back in an hour
[20:34:15] <artaxerxes> nap_time (L1912) contains such text
[20:34:43] <Colourless> i only saw 2 cases of hard coded text there. nap_time and armageddon
[20:34:46] <artaxerxes> and seems to drive the answer... not text.flx
[20:35:28] <Colourless> is the text actually in text.flx?
[20:35:29] <artaxerxes> true... but again, it is just a heads-up thing
[20:35:35] <artaxerxes> I doubt it....
[20:35:48] <artaxerxes> I don't remember translating that text... maybe KK did
[20:36:28] <artaxerxes> after reflexion, it is not in text.flx... I've looked at each line and didn't see anything like that.
[20:39:23] <Colourless> hmmm
[20:41:29] <artaxerxes> even gumps/Newfile_gump.cc has some text like that.
[20:42:18] <Colourless> that isn't intrinsics.cc :-)
[20:43:02] <artaxerxes> true :) but we still need to be able to offer a patch to a compiled file that won't change a lot!
[20:43:14] <artaxerxes> or a static text/flex file
[20:43:32] <artaxerxes> I know I'm a pain...
[20:43:36] <Colourless> well, what we need is a mechanism to load localized text from a flex
[20:43:43] <artaxerxes> exactly!
[20:44:01] <Colourless> i don't think that will occur before 1.0
[20:44:03] <artaxerxes> that's what I meant in the phorum and it seems Jeff has planned it.
[20:44:33] <artaxerxes> that's ok... maybe you want to make a list of where such text appears in the source.
[20:44:49] <Colourless> me??? no i don't want to do that :-)
[20:45:43] <artaxerxes> :)
[20:45:58] <artaxerxes> who's going to do it then ? :)
[20:46:23] <Colourless> you? :-)
[20:46:31] * artaxerxes was expecting that
[20:47:19] <Colourless> i'm too busy to do such things
[20:47:40] <artaxerxes> I understand.. and as I said earlier, there is no urgency.... yet
[20:47:44] <artaxerxes> :)
[21:05:40] <Colourless> ow, add with carry not working may have been a bit of a problem for me :-)
[21:07:43] <Colourless> YAY IT FINALLY WORKS!
[21:08:06] <Colourless> My x86 interpreter/emulator/virtual machine actually works!
[21:11:41] <artaxerxes> sth like Bochs ?
[21:12:03] <Colourless> kind of, but not really :-)
[21:40:03] --- wjp|away is now known as wjp
[21:40:11] <wjp> wow, cool
[21:40:11] <artaxerxes> hi wjp
[21:40:15] <wjp> hi
[21:43:22] <Fingolfin> Colourless: nice!!
[21:43:26] <Fingolfin> wb wjp
[21:43:40] <wjp> thx
[22:00:23] <artaxerxes> we have been approved for SF!
[22:00:34] <artaxerxes> si-french.sourceforge.net...
[22:00:53] <artaxerxes> give it a day to replicate to the DNS
[22:00:53] <wjp> cool
[22:01:00] <artaxerxes> Yay! :)
[22:01:24] <wjp> replicate to which DNS?
[22:01:42] <artaxerxes> dunno... that's what they say in the email
[22:02:01] <artaxerxes> "Your DNS will take up to a day to become active on our site"
[22:02:03] <Fingolfin> usually it's much quicker
[22:02:05] * wjp can already reach the page. ("Index of /")
[22:02:08] <Fingolfin> up to = maximal amount of time
[22:02:29] <Fingolfin> they also say they handle SR in up to 72 hours, but often it happens (for me at least :-) in 10 mins - 10 hours
[22:03:30] <artaxerxes> SR ?
[22:03:48] <wjp> service request
[22:03:59] <wjp> support request, sorry
[22:04:43] <artaxerxes> I see... hey wjp, you reached the site even before I did! :)
[22:04:55] <wjp> muahaha! ;-P
[22:05:29] <wjp> are you going to move the webpage there?
[22:05:41] <Fingolfin> hey, then maybe I can modify the site before you do? =)
[22:06:31] <Fingolfin> anyway, I better go to bed now
[22:06:35] <Fingolfin> before wjp! ha! :-)
[22:06:39] <-- Fingolfin has left IRC ("good night, folks")
[22:06:46] <artaxerxes> bye!
[22:06:57] <wjp> bah... he beat me to it :-)
[22:07:10] <artaxerxes> let's see the struc of the filesystem..
[22:07:43] <wjp> the webpage should be in /home/groups/s/si/si-french/htdocs, IIRC
[22:07:57] <artaxerxes> wjp: we'll move the site there... fed up of the popping ad
[22:07:59] <Colourless> decompressing with disassembler output enabled is a very very bad idea... it's very very very very slow :-)
[22:08:00] * wjp made a symlink to that dir (well, the exult one) from his homedir on SF
[22:08:15] <wjp> Colourless: I can imagine :-)
[22:08:33] <wjp> artaxerxes: let me know when you moved it; I'll add a link from our links page (it it isn't already there?)
[22:09:07] <artaxerxes> no more Directory Listing... :)
[22:09:50] <artaxerxes> otherwise, KK is the webmaster. He alone got access to the multimania.com files.... I'll tell him to send over the files...
[22:10:17] <artaxerxes> please put the link on the exult page once the site has been transfered.
[22:10:26] <artaxerxes> (should be on Monday)
[22:10:51] <wjp> sure, just send me an email when it's ready
[22:11:09] <Colourless> it's taking me approx 450 ms to decompress a 4 second sample
[22:11:42] <artaxerxes> Colourless: what kind of compression you are decompressing ?
[22:11:48] <Colourless> sonarc
[22:11:58] <Colourless> aka ultima 8's compression
[22:12:15] <wjp> how much sound is there to decompress in total?
[22:12:32] <artaxerxes> that's why you created the x86 interpreter/emulator/virtual machine ?
[22:12:43] <Colourless> 4.63 mb
[22:13:13] <Colourless> and it took 450 ms to decompress 25k :-)
[22:14:08] <wjp> so about 1.4 minutes?
[22:14:16] <Colourless> yeah not long at all
[22:14:27] <wjp> what CPU do you have?
[22:14:33] <Colourless> Athlon 1Ghz
[22:15:14] * wjp tries to remember how long it took to decompress the shapes on a 486
[22:16:38] <Colourless> I'm using some hand coded inline asm optimization though. I am still yet to write the more portable code. Of course the portably code will be written to only work with DCMP8. The asm code is a little more general
[22:16:55] <Colourless> s/portably/portable/
[22:17:13] <artaxerxes> got to read the doc from SF... have a good we!
[22:17:49] <artaxerxes> (week-end)
[22:17:51] <artaxerxes> Bye
[22:17:55] <Colourless> bye
[22:17:57] <wjp> bye
[22:18:02] <-- artaxerxes has left IRC ("using sirc version 2.211+KSIRC/1.1")
[22:25:10] * Colourless yawns
[22:27:02] <wjp> hm, it must be _very_ late for you
[22:27:10] <wjp> 10am?
[22:27:20] <Colourless> 8 am
[22:27:27] <wjp> oh, right, summer time again
[22:27:42] <Colourless> yeah, things are 2h different now :-)
[22:27:56] <wjp> just when I got used to the 9:30h difference :-)
[22:28:17] <Colourless> :-)
[22:28:43] <Colourless> oh well, you've only got 6month till it goes 'back' :-)
[22:28:51] <wjp> :-)
[22:30:36] <Colourless> well, i kind of think it's time for me to go
[22:30:46] <wjp> good night
[22:30:52] <Colourless> cya
[22:30:59] <-- Colourless has left IRC ("no comment")