#exult@irc.freenode.net logs for 27 Dec 2002 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[00:00:16] <matto|wookin> hi
[00:00:39] * Darke waves. Hi.
[00:01:53] <matto|wookin> DARKE
[00:02:28] <matto|wookin> do you know anything about C++ templates?
[00:02:40] * Coren_ could help with templates.
[00:02:53] <matto|wookin> coren!
[00:02:55] * Darke knows a bit.
[00:03:07] <matto|wookin> well this is probably a common problem... at least I hope ti is
[00:04:13] <matto|wookin> I have my "templated" class in a .h file ... I have the actual functions in a .cpp file... all of this works... but if I introduce another .cpp file and try to use a new datatype with this template, it gets a linking error saying it can't find a function for that datatype.. so I need to figure out some way to tel the template that 'yes, this datatype will be used eventually, so make sure you create a function for it' .. do you know how
[00:05:09] <Coren_> That's immensely compiler-dependent.
[00:05:15] <matto|wookin> oh it is?
[00:05:15] <Coren_> Which compiler are you using?
[00:05:20] <matto|wookin> g++ 3.0
[00:05:41] <Coren_> Okay, then all you need to do is provide for an explicit instanciation. This is how:
[00:06:00] <Coren_> Given, say, template<typename T> class F { ... };
[00:06:23] <Darke> It's only compiler dependant since most C++ compilers have yet to implement an 'export' keyword. *grin*
[00:06:43] <Coren_> In the appropriate .cc instanciate the specific template by saying:
[00:06:52] <Darke> Not that that little bit of info helps much. *grin*
[00:06:53] <wjp> hi Darke
[00:06:55] <Coren_> template F<some_type>;
[00:07:29] <Coren_> Err, rather:
[00:07:37] <Coren_> template class F<some_type>;
[00:08:08] <matto|wookin> Coren_ : ah.. excellent
[00:08:47] <matto|wookin> does that also work in MSVC++ by chance? hehe
[00:08:58] <Coren_> Yes. Thank the gcc people; gcc 3 is one of the very rare compilers that actually implements the C++ language. :)
[00:09:14] <Coren_> matto|wookin: I wouldn't count on it. Does it even support 'bool' nowadays?
[00:09:19] <matto|wookin> ya it does
[00:09:25] <Coren_> It's about time! :)
[00:09:44] <Darke> Hey you could get it to use 'bool'! Erm... provided you included <iso646.h>, IIRC. *grin*
[00:09:46] <Fingolfin> gcc 3 has one of the best ISO C++ supports I know of in fact. better than VC++ for example
[00:09:51] <Fingolfin> which isn't hard of course =)
[00:10:06] <Darke> No, really not hard at all. *grin*
[00:10:10] <matto|wookin> hehe
[00:10:15] <Coren_> You can try it. That is the canonical way of explicitely instanciating a template type according to the standard, but MS has been notoriously innacurate in their implementation of that language. :)
[00:10:43] * Darke hmms... his flatmate has VS.NET installed on a machine downstars, sould check it to see if they've unbroken the ide and/or compiler recently.
[00:10:56] <matto|wookin> well I am porting from an MSVC++ source collection, so I am just wondering if should enclose it in an #ifdef or not hehe..
[00:11:01] <wjp> I think this form of explicit instantiation worked for Colourless in pentagram with MSVC
[00:11:02] <Coren_> Darke, that depends what you mean by "broken".
[00:11:54] <Coren_> Darke: remember that MS breaks the C++ language standard by design. They *want* code written for MSVC to /not/ compile and work right on true standard compilers.
[00:12:18] <Darke> Coren_: The compiler has somewhat more vague C++ compatability (even just fixing it's brane damaged for scoping would be nice), and the ide can actually be used without tearing one's hair out, that would be nice too.
[00:12:28] <Coren_> Of course, that's because they provide "extensions" that are not provider by the other "less enlightened" software producers. :)
[00:12:37] <Dark-Star> Can anyone of you help me with a small C++ polymorphism problem? --> http://dark-star.homeftp.org/test.cpp
[00:12:56] <Coren_> Dark-Star: looking at it now
[00:12:56] <Dark-Star> I think I'm missing some basic aspect of virtual functions here... but I don't know which ;-)
[00:13:03] <matto|wookin> thx for the help
[00:13:36] <Dark-Star> compiler says it can't convert char * to int, so it seems it doesn't find the function f(char *) from the base class...
[00:14:35] <wjp> hm, maybe because you define b as a B*
[00:15:00] <wjp> if you do A* b = new B(); it does work
[00:15:02] <Coren_> wjp: b must be defined as a A*
[00:15:11] <Dark-Star> hmm...
[00:15:11] <Coren_> Err, Dark-Star
[00:15:27] <Dark-Star> so the compiler doesn't check back in the class hierarchy to find functions?
[00:15:38] <Coren_> Dark-Star: In fact, it must specifically not.
[00:16:14] <Coren_> Dark-Star: f(char*) is a property of A objects; B is an A, but you specifically asked for it as a B, and not as a subtype of A
[00:17:12] <Dark-Star> Coren_: hmm... but a B is a subtype of A by definition, so _every_ B has all methods of A. So that doesn't quite make sense to me . . .
[00:17:27] <Dark-Star> ... but I can live with it ;-)
[00:17:44] <Dark-Star> it's just .. umm... ugly that way
[00:18:14] <Coren_> Dark-Star: That's a basic principle of polymorphism... what you expected is that the compiler would /imply/ you wanted to use the B as an A-- but that would break as soon as you have multiple inheritance and would be damn confusing.
[00:18:17] <Darke> Nah. The problem is that char * can be equal to an int.
[00:18:30] <Darke> You need to change the struct B to look something like this:
[00:18:41] <Darke> struct B : public A
[00:18:41] <Darke> {
[00:18:41] <Darke> virtual void f(explicit int i) { cerr << "B.f(int)" << endl; }
[00:18:41] <Darke> };
[00:18:59] <Darke> See the 'explicit' keyword? That's what stops it from being confused. *grin*
[00:19:03] <Dark-Star> hmm...
[00:19:04] <Coren_> Darke: That won't have any effect; a B still does not provide an f(char*)
[00:19:08] * Dark-Star tries that . . .
[00:19:21] <Darke> Coren_: Umm... A does. That's the whole point of polymorphism.
[00:19:48] <Coren_> Darke: No, the point of polymorphism is being able to use a B through a A* without having to know that the A* really points to a B
[00:20:15] <Dark-Star> Coren is right. It doesn't work.
[00:21:02] <Coren_> Dark-Star: You code would work exactly as you wanted if you declared:
[00:21:08] <Coren_> A *b = new B(); // instead
[00:21:12] <Darke> Dark-Star: What compiler are you using?
[00:21:16] <wjp> renaming f(char *c) to g(char *c) does work, though
[00:21:33] <Coren_> wjp: Sure, because then you no longer /have/ polymorphism. :)
[00:21:39] <Dark-Star> Darke: gcc 3.2 (actually "gcc version 3.2 20020927 (prerelease)" under cygwin)
[00:22:26] <wjp> well, you're not supposed to have any on the f(char*) function anyway
[00:22:50] <Coren_> Dark-Star: think of "A" as the name of the /interface/ you want to use (that provides the f(char*) function). The fact that it points to an A implemented as a B object is irrelevant.
[00:23:04] <Dark-Star> Coren_: If I do "A *b = new B()", could I then do "b->g()", where g() is a method declared in B but not in A? Or would I need another typecast then?
[00:23:07] * Darke ohs. They've both named the same in the base class. That won't work. You need to duplicate the definition of the f(char *c) in the derived class else things will get confused.
[00:23:25] <Darke> Coren_: (point of polymorphism) That's not the reason I use polymorphism, but each to their own. *Grin*
[00:24:06] <Coren_> Darke: Then you're not using polymorphism at all, you're simply doing 'C with classes', that is reusing types by deriving new types from them. :)
[00:24:24] <Coren_> Darke: Which, incidentally, is what *I* do 99% of the time.
[00:24:28] * Coren_ grins.
[00:25:28] <matto|wookin> C with classes rules!
[00:25:35] <matto|wookin> err..
[00:25:35] <Coren_> Dark-Star: Yes, if you want to "cheat" by using knowledge that your A* really points to a B, the you have to be explicit about it. Normally, however, if you want to do things the 'OO' way you would provide a method in 'A' that would do g() on a B, and nothing (or throw an exception) on a non-B.
[00:25:38] * matto|wookin goes back into his cave
[00:25:54] <Dark-Star> OK, now I have 3 solutions... (1) Use "A *b = new B()" (2) implement B::f(char *) that just calls A::f(char *) (3) rename the two f()'s to distinct names...
[00:26:04] * Dark-Star wonders which one is the 'best' solution...
[00:26:37] * Darke has only just recently been dragged kicking and screaming into naming his files with .cpp rather then .cc (c with classes).
[00:26:56] <Coren_> Dark-Star: The "Canonical OO solution" is (1), but I would use (2) unless I expect to derive a lot of very different types from A.
[00:26:58] <Darke> Dark-Star: Renaming the two functions would probably be the 'best' solution. Hard to tell without knowing the context of the code.
[00:27:03] --> Kirben has joined #exult
[00:27:03] --- ChanServ gives channel operator status to Kirben
[00:27:56] <Coren_> Dark-Star: decent compilers will completely throw away the code for the downcall if you inline it.
[00:28:40] <Coren_> Dark-Star: and solution (2) has the property of documenting the fact that you expect f(char*) to be part of the interface to a B, and will break if you forget about it and remove f(char*) from A in the future.
[00:28:45] <Darke> Coren_: Can't be inlined. It's a virtual function.
[00:28:54] <Dark-Star> Coren_: (2) is out I guess, because I happen to _have_ to subclass A a lot. I don't like (3) either because the 2 functions do exactly the same (load a file from different 'sources')
[00:29:25] <Coren_> Darke: It *will* be inlined if the type of the object is known to be a B at compile time.
[00:29:39] <wjp> adding a 'using A::f;' to B will work too, btw
[00:30:02] <Darke> Coren_: Uh,uh. It is *strongly* likely it will. There is no guarantees with that. *grin*
[00:30:10] <Coren_> wjp: Yes, but that's a dangerous hack because it relies on A not overloading things in B you don't want it to.
[00:30:24] <wjp> true
[00:30:29] <Coren_> Darke: Yes, true.
[00:30:45] * Darke does occasionally wish there were a few more guaraneets in C++, it would make life *so* much easier occasionally. *grin*
[00:30:54] <Coren_> Darke: "Good" compilers "will" inline it even though they aren't required to. :)
[00:31:28] <Coren_> Dark-Star: Solution (1) is definitely the "Right Way".
[00:31:32] <Darke> Coren_: One hopes yes. *grin*
[00:32:02] <Coren_> And probably the one I would use given that particular context.
[00:32:36] * Dark-Star will use (1) then ... seems the cleanest solution to me too
[00:33:41] <wjp> it's amazing how long you can work with C++ and still miss some of these things :-)
[00:33:55] * wjp picked up another couple of snippets of knowledge :-)
[00:33:57] <Dark-Star> thanks a lot
[00:40:05] <wjp> I should be going; g'night
[00:40:11] <matto|wookin> goodnight
[00:40:26] <-- wjp has left IRC ("Zzzz...")
[00:40:30] <Darke> Night!
[01:01:17] <Coren_> wjp: Mind you, C++ is a moving target, so knowing it any point in time usually means that you still have much to (un)learn a year later. :-)
[01:01:27] <Coren_> Erm. He left.
[01:01:33] <Coren_> I hate it when I do that.
[01:03:27] * Coren_ poinders.
[01:03:39] <Coren_> Character creation or wearable objects next?
[01:09:42] <Fingolfin> kuran: the bug is still there with the latest (Dec 2002) dev tools, just FYI
[01:09:54] <Dark-Star> is "__attribute__((packed))" portable?
[01:09:59] <Fingolfin> Coren_: BTW ISO C++ is a fixed standard
[01:11:01] <Coren_> Fingolfin: *now* it is, but wjp was refering to having worked with C++ for years, which must therefore predate the standard. :-) I know *I* have at least three revisions of the ARM. :)
[01:11:05] <Dark-Star> or are there any other (better) ways to control struct packing?
[01:11:26] <Fingolfin> Dark-Star: no and no
[01:11:33] <Dark-Star> hmmm
[01:11:34] <Fingolfin> not AFAIK at least
[01:11:45] <Dark-Star> __attribute__((packed)) is a gcc thing then?
[01:11:56] <Coren_> Dark-Star: Not portably. __attribute__ is a gccism, too, but #define __attribute__(x) is enough to make it not break other compilers-- but remember __attribute__ is a hint only.
[01:12:49] <Dark-Star> it's a shame that such things aren't standardized properly... Sometimes one just _needs_ struct packing...
[01:13:12] <Dark-Star> MSVC calls it "#pragma pack" or something like that I think...
[01:13:24] <Coren_> Layout of compound types is implementation-defined; and there are very few garantees the C++ standard makes about it. Specifically, if you use no intervening access declarations, and you have no virtual members, the C++ type is mandated to be "like C" for the same members.
[01:14:08] <Coren_> Dark-Star the only way to specify a specific memory layout that does not depend on a compiler is to marshall and unmarshall it from a char*
[01:14:43] * Dark-Star puts some sanity checks in the code: if (sizeof(myStruct) != 16) perror("alignment problem");
[01:15:04] <Dark-Star> yuck. ugly. but it works...
[01:15:46] <Coren_> I have also used bitfields to great effect in the past when I needed to portably define the exact memory layout of a struct
[01:16:35] <Coren_> But that will only work if you don't have bigger-than-char types straddling the "wrong" alignment boundary.
[01:17:14] <Coren_> unsigned long foo:8, bar:16, baz:8; worked nicely though.
[01:17:49] <Coren_> It's endianness-dependent however.
[01:18:09] <Coren_> But then, so is any specific memory layout requirement.
[01:18:23] <Dark-Star> oh well... I think I will handle that later if I ever encounter some of the "alignment problem" error messages ;-)
[01:19:45] <Coren_> So, which should I work on next? Character generation or wearables? :)
[01:23:02] <Coren_> Checking in game_explore.cc;
[01:23:06] <Coren_> /cvsroot/low/low/game_explore.cc,v <-- game_explore.cc
[01:23:06] <Coren_> new revision: 1.53; previous revision: 1.52
[01:23:07] <Coren_> done
[01:23:08] * Dark-Star votes for wearables
[01:23:29] <Coren_> Hmmm. Looks like that file has been fiddled with often. :)
[01:25:09] <Coren_> Wearables it is, then, by unanimous acclaim. :-) Besides, playing with the paperdoll will be fun. :)
[01:30:35] <Coren_> Any of you setup with mingw?
[01:31:16] <Darke> Nope.
[01:43:54] * Dark-Star waves
[01:44:14] <Dark-Star> I have mingw. But auto{conf,make} still don't work :-(
[01:44:47] <Coren_> Suckyness. :(
[01:46:21] --- Darke is now known as DarkeAFK
[01:52:26] <-- Fingolfin has left IRC ("42")
[02:17:49] <Dark-Star> anyone got some pointers on the BMP file format?
[02:18:25] <Coren_> Hm; I have it on dead trees. Need a specific answer or just looking for general specs?
[02:19:04] * Coren_ tries to understand why anyone would /want/ to use that antediluvian format.
[02:19:51] <Dark-Star> do 24 bit BMPs need any padding or something?
[02:20:02] * Coren_ checks.
[02:20:54] <Dark-Star> I have a 24 bit BMP where I can't figure out how the file has the size it has. it's 102x76 pixels. makes 23310 bytes for me. but it's 152 bytes larger...
[02:22:00] <Coren_> No; if biCompression==BI_RGB, then the pixels are defined as three bytes per.
[02:22:24] <Dark-Star> hmmm...
[02:22:30] <Dark-Star> that's what I read, too.
[02:22:58] <Coren_> 102x76x3 = 23256
[02:23:15] <Coren_> 23310-23256 = 54
[02:23:39] <Coren_> biSize == 54
[02:23:45] <Coren_> I see no extra bytes there.
[02:23:54] <Dark-Star> yes, but the file is 23462 bytes large...
[02:24:08] <Dark-Star> it _should_ be 23310, that's what I calculated too...
[02:24:12] <Coren_> Ah, okay, the size you gave was /before/ the extra bytes.
[02:24:34] <Coren_> Well, there is no /requirement/ that the BITMAPINFOHEADER has 54 bytes, there might be extra data in there.
[02:24:40] <Coren_> Check the biSize field.
[02:25:17] <Dark-Star> no, I compared the "original" bitmap and my "read and saved" version, and the beginning is exactly the same (not the fileSize field, though)
[02:25:19] <Coren_> That bmp might have been generated by a program which adds more data to the header
[02:25:40] <Coren_> Perhaps trailing data?
[02:26:27] <Coren_> Have you tried rereading the file in?
[02:26:50] <Dark-Star> the funny thing is that if I open my "new" (i.e. smaller) file in ACDSee, it says "file stream truncated".
[02:27:35] <Coren_> Hm. So there is extra data that the tool your read-and-save operation truncated because it didn't know about it.
[02:27:44] <Coren_> Doesn't seem like an unlikely scenario.
[02:27:59] <Dark-Star> I rechecked it, and the headers are exatly the same for both files (except for the 3rd byte, which is the LSB of the file size)...
[02:28:00] <Coren_> This is why PNG specifies exactly what to do with data you don't understand. :-)
[02:28:31] <Dark-Star> and the beginning of the pixel data seems identical too
[02:28:35] <Coren_> That would be the problem; if the header contained information your tool didn't know about, but the tool /copied/ the header on save, you'd get that.
[02:29:01] <Coren_> Try doing this: open the original, copy, create a new file, paste, save.
[02:30:11] <Coren_> What is the value of the 14th byte in the file?
[02:30:15] <Coren_> (original)
[02:30:26] <Dark-Star> hmm ok, but why does ACDSee say that my version is corrupt when it has the right file size (23310 bytes). btw I don't copy the header I recreate them by filling in the various fields
[02:30:49] <Dark-Star> 14 dec? 0x28, as it should be (40)
[02:31:05] <Coren_> In the original too?
[02:32:32] <Dark-Star> yes.
[02:32:42] <Coren_> Hrmph.
[02:32:54] <Dark-Star> funny... I opened it and resaved it in Photoshop, and the resaved version is 2 bytes longer...
[02:32:55] * Coren_ doesn't get it.
[02:33:45] <Coren_> Well, I don't understand why we are having a problem. BMP is a well defined, open standard with no implementation quirks by the creator of the format and... oh, wait...
[02:33:49] * Coren_ smirks.
[02:33:52] <Dark-Star> the header and first data bytes are equal, but something strange happened to the last bytes in the file...
[02:34:36] <Dark-Star> in the original they are "15 0A 15 17 72 77" and in the resaved bitmap they are "15 0A 15 17 06 14 00 00"
[02:35:56] * Coren_ boggles.
[02:36:22] <Coren_> Well, my specs date, so this may be consequences of "improvements" to the format in years past.
[02:36:41] * Coren_ starts.
[02:36:56] <Coren_> Actually, my reference dates from 1991. Might be very slightly outdated.
[02:37:39] <Coren_> IIRC, that is the last Microsoft-related publication I have bought.
[02:38:07] * Dark-Star looks for a different 24 bit BMP...
[02:38:53] <Coren_> better yet: load some non-bmp and save it as a 24 bit BMP and see what happens to the file size then.
[02:39:43] <Dark-Star> hmmmmmmmm
[02:40:13] <Dark-Star> using an 800x600x24 BMP worked...
[02:40:43] * Dark-Star thinks it's a padding problem after all...
[02:40:55] <Coren_> Oooo. Might be _line_ padding.
[02:41:00] * Coren_ calculates.
[02:41:10] <Dark-Star> each line is 102 bytes long, add 2 bytes per line makes it divisible by 4.
[02:41:11] <Coren_> Yep, that's it. Lines are padded to 4 byte boundaries.
[02:41:25] <Dark-Star> 2 bytes / line * 52 lines is exactly the amount of data my file lacks...
[02:41:31] <Dark-Star> hmmm...
[02:41:48] <Dark-Star> but why do they pad lines with some nonsense-data instead of 0 bytes?
[02:42:21] <Coren_> Possibly they just never bother to zero out the buffer knowing that the read implementation will simply ignore the padding?
[02:42:42] <Dark-Star> hmm.. might be.
[02:43:02] <Coren_> Try it yourself: zero out the padding bytes and see if that breaks anything.
[02:43:35] <Coren_> Actually, BTW, each line is 306 bytes long, but you still need to add two bytes to make it divisible by 4. :)
[02:43:51] <Dark-Star> oh. right. :)
[02:44:13] <Dark-Star> ok then I'll rewrite my load and save routines so that they automatically flip the image while reading
[02:44:38] <Coren_> I still can't help but wonder why you *want* to use BMPs anyways. :)
[02:45:27] <Dark-Star> actually it's for reading in files that are BMP. the save routine is just for debugging. I thought it would be the most simple format if you want to dump some screenshot or something ;-)
[02:45:56] <Coren_> And the funny thing is, reading the specs I find no mention of line padding. Probably was added later as they realized that modern CPUs wouldn't like odd-aligned scanlines. ;)
[02:46:33] <Coren_> Few windows users needed 24 bit images back then, or even could display them in the first place. :)
[02:46:47] <Dark-Star> yes, I remember these times quite well :)
[02:47:26] <Coren_> I don't, but that's because I had a nifty, kickass DecStation as my PC back then. :)
[02:48:41] <Coren_> The happy benifit of working for MPGNet. :)
[02:48:47] * Dark-Star thinks about starting his first sourceforge project soon :-)
[02:48:59] <Coren_> Coolness. What about?
[02:49:26] <Dark-Star> hmm I thought since everybody seems to be doing engine reimplementations right now, I could start one myself...
[02:49:33] * Coren_ chuckles.
[02:49:35] <Coren_> Which one?
[02:49:44] <Dark-Star> too bad I piced one of the most complicated engines out there, the Infinity Engine...
[02:50:01] <Dark-Star> ... that's why it'll never be finished I suppose...
[02:50:05] <Coren_> Well, the added challenge is all the better. :)
[02:50:21] <Coren_> Use the Bazzar, Luke!
[02:50:24] <Coren_> Get help.
[02:50:25] <Coren_> :)
[02:51:05] <Dark-Star> the funny thing is that there once was an IE reimplementation project, but it was dead for years.
[02:51:28] <Coren_> Can you salvage source from its corpse? Or at least data?
[02:51:29] <Dark-Star> so I planned a little on starting my own. and now that I started, I found out that they restarted, too :)
[02:51:37] <Coren_> Ah.
[02:51:38] <Coren_> :)
[02:51:51] <Coren_> Well, perhaps collaboration is the key, then.
[02:51:55] <Dark-Star> and they're quite a bit ahead ... so I'll have to catch up a bit :)
[02:52:28] * Coren_ notes that he and Michael Fink have now made a regular habbit of pulling each other up by our respective bootstraps. :)
[02:52:30] <Dark-Star> _they_ even have screenshots, and I don't (yet :-)
[02:54:01] <Dark-Star> but I'll do it just for the fun of it, and because I've never done anything similarily large before...
[02:54:47] <Coren_> For some reason, the guy that started UW2 revival is uncommunicative and unresponsive. Odd. Basically every other reimplementation project out there is eager to share and collaborate.
[02:55:11] <Coren_> "Because I have yet to do that" is the best geek motivation there is. :-)
[02:57:11] <Coren_> On the other hand I'm toying with the idea of making some changes to the gameplay. Since the biggest part of the Underworlds maps isn't overlapping, there are pretty little reasons not to use a top-down view. The name that keeps popping up in my mind is Legend of Zelda - Link to Past. I never said this would be a 1:1 remake. the matter isn't settled by far, though....
[02:57:18] <Coren_> [quoted from his news]
[02:57:29] <Coren_> He doesn't seem overly serious after all, does he? ;)
[02:57:46] <Dark-Star> hehe... ;-)
[02:58:25] <Dark-Star> what I always wanted to know: why are there 2 projects for the 2 underworld games? are they so different WRT the data files? or are you using different approaches?
[02:58:51] <Coren_> I have no idea why he does it. He has refused to communicate with me.
[02:59:32] <Coren_> Perhaps he was unsatisfied with my early tech demos; or he started independently unaware of my project.
[02:59:34] <Dark-Star> no, actually I meant uwadv and LOW ;-)
[02:59:42] <Coren_> Oh!
[03:00:06] <Coren_> Independent invention; but we're also going about the same basic task from two different approaches.
[03:00:31] <Coren_> Michael is reimplementing, then improving. I'm rewriting. But we are sharing a great deal of information.
[03:01:09] <Coren_> He is intent on reproducing the original interface faithfully, whereas my aim is to modernize it while keeping the spirit intact.
[03:01:46] <Coren_> But chances are that both our project will eventually be able to run both games.
[03:02:34] <Dark-Star> well... that was just what I was about to ask right now :)
[03:03:18] <Coren_> This is Open Source at its best, actually. Our "compeeting" implementations have managed to benefit each other greatly.
[03:04:00] <Coren_> I don't expect there will ever be a merge; both uwadv and low will retain very different flavors, and players will tend to be attracted to one or the other.
[03:04:01] <Dark-Star> yes, that's often the case. I remember that it was the same with exult, there was another project which actually "revived" exult from the dead :-)
[03:04:29] <Coren_> Hmm, yes, albeit exult can be said to have "won".
[03:04:38] <Dark-Star> you could split it into a front-end and a back-end :)
[03:04:53] <Dark-Star> the back-end code could be shared by uwadv and low...
[03:05:10] <Dark-Star> yes, exult has "won", but only because the other project gave up after exult was revived...
[03:05:15] <Coren_> That's unlikely. We do things /completely/ differently internally. Different coding philosophies, I guess, and different approaches to the same problems.
[03:06:23] <Coren_> For one, uwadv is much more gentle on modest hardware because it basically renders the world the same way UW2 did at a fundamental level.
[03:07:29] <Dark-Star> yes, but hardware requirements for LoW are not _that_ high, are they?
[03:07:33] <Coren_> My engine constructs a "modern" 3d world from the game data on the fly, and renders that with (more) modern techniques. This is why I get to do things like vertex lighting and particle systems.
[03:07:34] --> Dominus has joined #exult
[03:07:40] --- ChanServ gives channel operator status to Dominus
[03:08:12] <Dominus> hi
[03:08:15] <Dark-Star> will I still be able to run it on my GeForce 1 in the future?? *g*
[03:08:18] <Dark-Star> Hi
[03:08:26] <Coren_> I would say the hardware requirements are roughly equivalent to, say, Quake3. But the Underworlds are very playable even if you have relatively low framerates which makes it easier.
[03:08:46] <Coren_> Hello, Dominus.
[03:09:07] <Coren_> Well, LoW runs well on my GeForce 2 MX. :-)
[03:09:20] * Dark-Star looks at the time
[03:09:36] * Dark-Star thinks the BMP reimplementation will have to wait until tomorrow...
[03:10:07] <Coren_> Besides, I'm no Carmack. My 3D engine could certainly be improved by an order of magnitude by someone who is competent in such things.
[03:10:28] <Dark-Star> Coren_ wait till you see the mess of code I'm creating ATM ;-)
[03:11:13] <Dark-Star> actually I'm a bit reluctant creating a CVS repository, because the code is *really* messy . . .
[03:11:17] <Coren_> I just finished playing Arx, actually, and it was a bit disheartening. LoW pales by comparison. :-)
[03:11:21] * Coren_ LOL.
[03:11:56] --- DarkeAFK is now known as Darke
[03:11:56] <Coren_> That is *exactly* why LoW was closed source for a long time before I moved it to sf. I finally decided "Oh, what the heck. Let someone improve it if they can do it nicer."
[03:12:27] <Coren_> Some parts of the LoW codebase are still ugly as hell. :-)
[03:12:41] <Dark-Star> yes, and I won't move it to SF until it actually shows some screenshots ;-)
[03:12:50] <Coren_> // WARNING: This code is ugly as hell, contains black magic, and is
[03:12:51] <Coren_> // probably going to be a nightmare to fiddle with. It's also suspected
[03:12:51] <Coren_> // to contain at least one buffer overflow, and to contribute to
[03:12:51] <Coren_> // holes in the Ozone layer.
[03:13:09] <Coren_> From granny.cc. :)
[03:13:18] <Dark-Star> hmm.. I need such headers too...
[03:13:34] <Dark-Star> :)
[03:14:15] <Coren_> Some guy once wanted to give me a hand with my physics system way back then but ran away screaming in horror after seeing my code. :-)
[03:14:28] <Dominus> he he
[03:14:29] <Dark-Star> hmm... can't be as bad as mine ;-)
[03:14:39] <Dark-Star> I _bet_ my code is far uglier *g*
[03:15:14] <Coren_> Go check out physics.cc in the cvs and then say that again with a straight face. :-)
[03:16:01] <Coren_> Right now my physics seem to work pretty well, but I don't think I could tell you why. :-)
[03:16:56] * Dark-Star looks at physics.cc
[03:17:21] <Dark-Star> ok, this is _really_ a write-only piece of code...
[03:17:46] <Coren_> Not all my code is that bad. :-)
[03:18:12] <Dark-Star> yes, I've looked at other bits before and they were a lot clearer IMHO
[03:20:05] <Dark-Star> what does ">?=" do?? I can't make any sense out of that. In granny.cc, Texture::Texture(Chunk *c)
[03:20:36] <Coren_> GCCism. >? is the max operator. >?= is just the assignment version of it.
[03:21:32] <Coren_> "a >?= b;" is equivalent to "if(b>a) a=b;" only it evaluates a and b exactly once.
[03:22:05] <Coren_> I like >? and <? very much. :-)
[03:22:05] <Dark-Star> aah ok...
[03:22:45] <Dark-Star> but it's gcc only, isn't it? so you'll need to change it in the long term :-)
[03:23:07] <Coren_> No. I have decreed that LoW is buildable with GCC >=3.0 only.
[03:23:39] <Coren_> Which is not that big a requirement when you think about it given that I require SDL, which requires gcc on all platforms except windows. ;-)
[03:23:58] <Dark-Star> well.. right :)
[03:24:55] <Coren_> But don't look to hard at granny.cc; its complexity is mandated by the baroqueness of the Granny 3D format and my limited understanding of it from reverse engineering it.
[03:25:35] <Coren_> granny.cc and physics.cc are the two worst parts of my whole code base.
[03:27:46] <Coren_> babl.cc contains mildly clever code that's very readable if you are familiar with vm interpreters, and most of the rest is understandable at the very least.
[03:27:54] <Dark-Star> I like this:
[03:28:05] <Dark-Star> '//// DOING SO AT THIS STAGE WILL DESTROY THE WORLD DATA
[03:28:14] * Coren_ chuckles.
[03:28:30] <Dark-Star> so what _is_ LoW really? some kind of super-evil virus? *g*
[03:29:03] <Dark-Star> and why can't I write lines that start with a slash in mIRC?
[03:29:11] <Coren_> Well, I to warn //// DO NOT BUILD AND RUN THIS PROGRAM!
[03:29:15] * Coren_ chuckles.
[03:29:48] <Coren_> Because mIRC thinks you want to give it a command.
[03:30:01] <Coren_> IIRC, /say /something with a slash
[03:30:05] <Coren_> will work around that.
[03:30:08] <Dark-Star> /test
[03:30:12] <Dark-Star> aah ok :)
[03:30:27] <Dark-Star> good to know, if I ever need to paste comments in IRC again . . .
[03:31:02] <Coren_> levdump is the tool I used to extract some of the data I needed to massage for LoW; but running it again will reset all the data to its pre-tweaked stage.
[03:31:14] <Coren_> I.e.: it will break everything in data/levels/
[03:31:17] * Coren_ smiles.
[03:31:20] <Coren_> Hence the comment.
[03:31:52] * Dark-Star wonders what a vm interpreter is, for he can't understand anything in babl.cc...
[03:32:08] <Dark-Star> maybe it's just too late (it's 4:30 A.M. here)
[03:32:27] <Coren_> Look at whatever part of exult interprets usecode for an equivalent. :-)
[03:33:18] <Coren_> babl.cc interprets the virtual machine language used by the Underworlds for scripting and conversations.
[03:34:09] <Dominus> Coren_: did anything groundbreaking happen with LoW in the last two weeks? like new features?
[03:35:07] <Coren_> Dominus: lots of tweaks to the UI, including a new kickass Ultimaesque font I did while studying for my finals in order to cool off. It's VERY pretty, and in fact looks better than any Ultima font I've seen. :-)
[03:35:10] * Dark-Star makes a mental note to consider using namespaces and exceptions
[03:35:38] * Dominus ahs
[03:35:38] <Coren_> Dark-Star: beware that gdb still has some issues coping with namespaces.
[03:36:09] <Coren_> Dominus: It's actually so cool looking it's worth the cvs update and download of the game data (1MB). :-)
[03:36:26] <Dark-Star> I actually favor cerr over gdb :-)
[03:37:14] <Coren_> Dominus: No major new features because of said finals. :-) Though there were a number of conversation fixes in the past few weeks that make, basically, all non-trade related conversation now work right.
[03:37:16] <Dominus> Coren_: I have this little problem that my compile of low is not even starting due to msys/auto-tools problems
[03:37:41] <Coren_> I can build a win32 executable for you if you want
[03:37:46] <Dark-Star> my test program, which only opens the resource index file and loads the indices, creates about 80 lines of debug output :-)
[03:38:17] <Dominus> Coren_: I'll come back to this some other time, I don't have much time for such in the next few days...
[03:38:43] <Coren_> Oh, allright. I *would* have taken me all of 30 seconds. :-)
[03:39:20] <Dominus> :-)
[03:39:47] <Dominus> atm I'm pretty fucked up anyway
[03:41:02] <Dominus> the night of 25/26th I spent partying and getting to bed at 7 am, got up at 12 pm, drove back to my mom's place and then later drove 700 km to my place
[03:41:21] <Dominus> and that with freezing highways (Autobahnen)
[03:42:50] * Coren_ chuckles.
[03:42:58] <Coren_> Just tell me this, do you have a P4 or some other cpu?
[03:43:06] <Dominus> P3
[03:43:43] <Dominus> (and that optimized 586 exe is not working for me for some strange reason)
[03:43:47] <Dark-Star> Coren_: for the records, I just re-read my BMP documentation and actually it _says_ that pixel lines are padded to 4 byte bounadries... I guess I shouldn't be coding that late ;-)
[03:43:55] <Coren_> I'll still build and dcc you the executable; all you'll need to do is download the small 'data files' archive whenever you feel like trying.
[03:44:08] <Dominus> ok
[03:44:18] <Dominus> you moved the big one to sf now?
[03:44:42] <Coren_> Yeah; I decided I'll take my chances on EA not throwing a fit.
[03:44:57] <Dominus> good, need to download that as well
[03:45:26] <Coren_> Almost none of them changed since mid november, so it's likely you don't have to.
[03:45:39] * Coren_ chuckles.
[03:45:48] <Dominus> well, my zip was kind of corrupted...
[03:46:02] <Coren_> There is some perverse satisfaction in building a win32 executable from linux, and then testing it with Wine. :-)
[03:46:12] <Dominus> he he
[03:46:25] * Dominus was wondering about the chuckling :-)
[03:47:36] <Coren_> Anyone else want the latest win32 executable?
[03:47:49] <Dark-Star> oh, why not...
[03:47:52] <Dark-Star> :)
[03:48:04] <Dominus> thx
[03:48:14] <Coren_> np
[03:49:05] <Coren_> Remember that http://low.sourceforge.net/low-gdata-251202.zip is needed for that executable.
[03:50:10] <Dark-Star> thanks
[03:50:38] <Coren_> Someone try this and tell me what you think of the new font.
[03:50:57] <Coren_> To date, Willem is the only one who has seen it. (He keeps his cvs updated all the time). :-)
[03:50:57] <Dark-Star> do I need to unpack the data into the uw2 directory?
[03:51:20] <Coren_> Unpack it from the directory containing your uw2_low directory.
[03:51:37] <Coren_> It contains the paths.
[03:51:40] <Dark-Star> I don't have an uw2_low directory ... (yet)
[03:51:54] <Dark-Star> I thought about putting low.exe into the main uw2 directory...
[03:51:55] <Coren_> Erg, you want to unpack all your older archives first then.
[03:51:57] <Dark-Star> is that a bad idea?
[03:52:30] <Coren_> It's not a bad idea, it just won't work. ;-) You want to unpack all of low in its own directory, and edit low.ini to point to where your UW2 install is.
[03:53:27] <Coren_> low.exe goes into uw2_low, above the data/ directory.
[03:53:35] <Coren_> Replacing the older one.
[03:54:17] <Dominus> the font that the conversations are in?
[03:54:38] <Coren_> Everything uses the new font, actually, conversation, messages, etc.
[03:54:39] <Dark-Star> aaah ... yes, now I remember, I always hat trouble downloading the other data files that's why I don't have them yet :)
[03:54:56] <Dominus> looks nice
[03:55:20] <Dominus> I get about 4-5 fps in the crowded throne room
[03:55:26] <Coren_> Go click on Lord British. The rendering of that name ends up really purtty. :-)
[03:55:36] <Coren_> 4-5? Ouch, that's bad.
[03:55:37] <Dark-Star> umm.. what's that, Athlons don't support i686 instructions????
[03:55:52] <Coren_> Dark-Star; that's that.
[03:56:07] <Coren_> Dark-Star they have their very own set of magic instructions.
[03:56:15] <Dark-Star> I'm using Linux packages compiled for i686, and they work fine too. . .
[03:56:45] <Dark-Star> just curious: what instruction(s) are problematic?
[03:56:54] <Coren_> Most of the time, people use -i686- when they mean -i586- or -pentium3-
[03:57:04] <Darke> Athlons are 100% i686 compliant. Else I wouldn't be here talking to you, since my entire machine, from kernel to compiler is compiled with that. *grin*
[03:57:15] <Dominus> on starting in the avatar's room I have about 25 fps and when I'm leaving the throne room into the fountain room I'm back at 12...
[03:57:28] <Coren_> SSE2 instructions, mostly.
[03:57:52] <Darke> I think you're thinking of the specific `athlon`/`duron`/`athlon-xp` march flags.
[03:58:13] <Dominus> low fps: only 256MB RAM (after the other 256 MB died) 1GHz CPU, Voodoo 5...
[03:58:33] <Coren_> Ahh, may be the voodoo; I might be using features it only implements in software.
[03:58:59] <Coren_> You are my first tester who reports a non-nVidia card. :-)
[03:59:03] <Dominus> could be and the drivers for XP are not exactly optimized
[03:59:48] <Coren_> LoW isn't particularly ram-hungry though.
[03:59:58] <Coren_> But it does press hard on texture memory.
[04:00:02] <Dominus> the OpenGL icd is only OpenGl 1.1 specs
[04:00:33] <Coren_> I don't think I use anything that's beyond 1.1 with common extensions.
[04:00:44] <Dominus> k
[04:00:47] <Coren_> Are you running fullscreen or windowed?
[04:00:57] <Dominus> fullscreened
[04:01:28] <Coren_> Try windowed; I have heard people report that XP gave better performance this way in some setups.
[04:01:49] <Coren_> Though what happens with a Voodoo5 is hard to predict.
[04:02:14] <Dominus> what do I have to set in the ini for windowed?
[04:02:58] <Coren_> It's not in there yet; you can start low.exe with -w on the command line, or Alt-Enter once running.
[04:03:26] <Coren_> Does your voodoo5 obey the setup.video.gamma value?
[04:03:47] <Coren_> For some reason, many windows nVidia setups do not (which makes the whole game painfully dark)
[04:04:13] <Dominus> I may need to try different glide files (Colourless and KoolSmokey are each working on different ones) as OpenGl relies on the glide files...
[04:04:20] <Dominus> hm, seems bright enough
[04:04:36] <Coren_> Then it probably does; the default of 1.3 is right for most people.
[04:05:08] <Dominus> yeah, it brightened noticable on starting it windowed
[04:05:33] <Coren_> Have you noticed the way the text "Lord British" ends up being rendered? The best part is that wasn't planned, just the way I hinted the kerning information in the font. ;-)
[04:06:04] <Dark-Star> I'm getting only 12 fps too while looking into the throne room...
[04:06:35] <Dominus> in windowed mode it is even worse for me
[04:06:48] <Coren_> The throne room is painful for most people; LOTS of polygons in those models. It's 3d card dependent, and mostly unavoidable until I get new models.
[04:07:09] * Dominus is not really complaining
[04:07:18] <Coren_> I am told that GeForce 3 Ti's do 25 fps in the throne room without breaking a sweat.
[04:07:32] <Coren_> And 4 MXes still reach over 20
[04:07:55] <Dominus> I would like to know how Colourless' Voodoo 5 6k would hold up
[04:07:58] <Coren_> IIRC, Ti's have accelerated geometry too.
[04:08:48] <Dominus> oops, I killed the console...
[04:08:55] <Coren_> The portraits look surprisingly nice once filtered by OpenGL, huh?
[04:09:10] <Dominus> meaning I don't get to see the overlays anymore :-)
[04:09:10] <Coren_> The console is not very robust; it's there mostly as a debugging hack.
[04:09:11] <Dark-Star> the "Lord British" text is really nice :)
[04:09:19] <-- Dominus has left #exult ()
[04:09:28] --> Dominus has joined #exult
[04:09:29] --- ChanServ gives channel operator status to Dominus
[04:09:33] <Dominus> oops
[04:09:33] <Dark-Star> ok I have to go now. 2 hours till sunrise ...
[04:09:36] <Coren_> Dominus: TAB
[04:09:43] <Dark-Star> bye!
[04:09:46] <Coren_> Dominus: TAB toggles all the UI panels on and off.
[04:09:47] <Coren_> :-)
[04:09:53] <Dominus> ah
[04:10:05] <-- Dark-Star has left #exult ()
[04:10:06] <Coren_> See ya, Dark-Star!
[04:10:12] <Coren_> Darn. Missed him.
[04:10:19] <Dominus> stupid tirlian closes the chat window when you hit ESC
[04:10:27] <Dominus> Trillian
[04:11:40] <Coren_> I still need to tweak a couple of kerning pairs on the font, but I think I did a very nice job. :-)
[04:11:48] * Coren_ pats himself on the back a bit.
[04:11:49] <Dominus> the pictures look really great
[04:12:08] <Dominus> and I like the font
[04:12:49] <Dominus> low seems to have a hard time deciding on what you click
[04:15:16] <Dominus> he he
[04:15:18] <Dominus> http://cgi.ebay.com/ws/eBayISAPI.dll?viewitem&item=1945568257&ssPageName=ADME:X:ON:DE:2
[04:15:36] <Dominus> the Japanese Underworld PSX port
[04:15:59] <Dominus> sold for 149.99 to an invalid Ebay user :-)
[04:17:02] <Coren_> Actually, it's because all of the cardboard cutout objects are bound by an invisible square, which means you can click on what seems to be one but be in fact hitting the border around another in front. No easy way around this until the billboards are replaced gradually with models.
[04:17:26] * Darke snickers. That's just odd, I wonder how that happened? *grin*
[04:18:46] <Dominus> when clicking on the user's history you see that he seemed to have been doing it all over Xmas :-)
[04:19:37] <Coren_> I'm glad to see the font is readable. I was affraid it might be too stylized to be practical.
[04:19:51] <Dominus> it is quite readable
[04:19:55] <Coren_> But I worked damned hard on it. :-) I'm really pleased on how it came out.
[04:20:18] <Dominus> g
[04:20:30] <Coren_> Certainly looks better than Courrier for the game. :-)
[04:20:36] <Dominus> I got the feeling you are pleased :-)
[04:21:51] <Coren_> Fonts are a hobby of mine I indulge whenever I need to decompress. Finals usualy ends up with my having designed a new font, not all of which are good. :-)
[04:22:02] <Coren_> This time, I actually had a /use/ for one. :-)
[04:22:25] * Coren_ giggles.
[04:22:38] <Coren_> Cute. I hadn't tried it before, but LoW copes well with Xinerama.
[04:22:56] <Dominus> say, you wouldn't be interested do a Pagan-font? in the style PAGAN was written during the intro of U8...
[04:23:19] * Coren_ smiles.
[04:23:36] <Coren_> Tell you what, come finals for the winter term, I'll work on that one. :-)
[04:23:47] <Dominus> wow
[04:24:46] <Dominus> that leaves me in some kind of dillema, one, I would really like to have Pentagram have a nice logo nw, otoh, I'd rather have you work on Low :-)
[04:24:56] <Coren_> Building a font pixel-by-pixel and hand tweaking antialiasing is a /really/ good way to flush one's brain. :-)
[04:25:25] <Dominus> I wouldn't have the patience
[04:25:42] <Coren_> Don't worry-- when exam time comes around the *last* thing I want to do is code. :-)
[04:26:02] <Dominus> he he
[04:26:33] <Coren_> Take a look at data/textures/font1.png if you want to see the font itself.
[04:27:48] <Dominus> that misses the most important letters in the world: :-)
[04:30:54] <Coren_> Well, actually, given the language of the original, it's not that are missing, but and . :-)
[04:31:13] <Dominus> true
[04:31:21] <Coren_> But I don't expect the typical player to be able to parse thorn or eth nowadays. :-)
[04:33:59] <Coren_> Besides, Britain's english is some baroque form of bastardized elisabethan, not middle english. :-)
[04:34:23] <Coren_> It might be an amusing translation project, though. :-)
[04:34:51] <Dominus> it is more what some looney thinks proper old english should sound like :-)
[04:35:33] <Coren_> God; they have obviously never *seen* old english. Gaelic is easier to read.
[04:35:52] <Dominus> he
[04:36:11] <Coren_> But then again, most people who say 'old english' mean 'middle english'
[04:38:24] <Coren_> Hark! Mine bed summonses, I needs must heed the call!
[04:38:38] <Dominus> me too
[04:38:45] <Dominus> bye
[04:38:49] * Coren_ wavies.
[04:38:54] <-- Dominus has left IRC ("enough for now")
[04:38:55] * Coren_ is away: bedtime!
[13:19:27] <-- Coren_ has left IRC (Remote closed the connection)
[13:30:12] --> Colourless has joined #Exult
[13:30:12] --- ChanServ gives channel operator status to Colourless
[13:30:33] <Colourless> hi
[13:30:36] <Darke> Hi!
[14:21:24] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[14:33:32] --> Dark-Star has joined #exult
[15:11:46] --- Darke is now known as DarkeZzz
[15:16:26] --> wjp has joined #exult
[15:16:26] --- ChanServ gives channel operator status to wjp
[15:16:30] <wjp> hi
[15:16:57] <Colourless> hi
[15:43:39] <matto|wookin> good morning
[17:02:15] <-- kuran has left IRC (Remote closed the connection)
[17:15:08] <-- Colourless has left IRC ("brb, restarting")
[17:17:57] --> Colourless has joined #Exult
[17:17:57] --- ChanServ gives channel operator status to Colourless
[17:53:03] --> Coren_ has joined #exult
[17:54:56] <matto|wookin> coren!
[17:55:02] <Coren_> Matto.
[17:55:06] <Coren_> :)
[17:55:13] <Colourless> no, you say it incorrectly
[17:55:19] <Colourless> the proper way to do it is:
[17:55:22] <Colourless> MATTO!!!!!!!!!!!!!
[17:55:26] <matto|wookin> indeed :)
[17:55:29] <Coren_> Ah.
[17:55:32] * Coren_ sits corrected.
[17:55:36] <matto|wookin> let's have some enthusiasm, why don't we? ... hehe
[17:55:40] <Coren_> "MATTO!!!!!!!!!!!!!"
[17:56:03] <Colourless> much better, next time without the quotes though :-)
[17:56:32] <Coren_> Nah, I'd rather keep my image of being aloof and mysterious. :_)
[17:57:23] * Coren_ wishes he had about $10K for a Granny 3D license.
[17:57:23] <Colourless> you sound like a wisp
[17:57:24] <matto|wookin> I have an interesting problem with this C++ program I'm working on ... one or more of its member variables are giving me "cannot access memory at 0x????" errors in gdb and segfault when the program tries to execute them... yet I can access them alright in the constructor.. so somewhere along the lines they are being marked as 'inaccessible', as if the memory was being de-allocated
[17:57:53] <Coren_> matto|wookin: classes with vtables?
[17:58:02] <matto|wookin> I really have no idea how to track this down...
[17:58:16] <matto|wookin> vtables meaning virtual functions?
[17:58:26] <Colourless> if you are calling virtual functions in a constructor, or function called by a constructor, you are asking for big problems
[17:58:48] <matto|wookin> the constructor isn't...
[17:58:48] <Coren_> Usually; though implementation are allowed to do vtables even for classes with no virtual members.
[17:59:00] <matto|wookin> I don't know how to tell whether it has vtables or not
[17:59:30] <Coren_> But what you describe sounds suspiciously like one of two things: You are dereferencing a bad pointer, or you are attempting to access the wrong object through an Evil Cast of Doom.
[17:59:31] <Colourless> well, can you give us more details about what line in your program is causint the problem?
[18:00:12] <matto|wookin> well I don't think it's either of those problems, coren, and I will tell you why
[18:00:25] <Coren_> Well, show me some code, then. :-)
[18:00:37] <matto|wookin> unfortunately I cannot do that, but I will try to describe it as best I can
[18:01:06] <wjp> oh, this is that linux port you told about earlier?
[18:01:14] <matto|wookin> ok, class A ... has a function called Add() which has a few internal pointers to form a linked list ...
[18:01:18] <Coren_> Hey Willem. :-)
[18:01:24] <wjp> hi Coren
[18:01:30] <matto|wookin> wjp : ya, I am porting Dragon's Lair 3D to linux.. they made me sign an NDA, so I can't show you the code...
[18:02:08] * Coren_ suggests hypothetical code. Works. :-)
[18:02:15] <matto|wookin> class B ... has an instance of class A in its 'protected' section ... something like "A mInstanceA;" ...
[18:02:24] <Colourless> you'd be then converting windows (msvc) code to linux right?
[18:02:34] <matto|wookin> then in A::SomeFunction() there is a call that does mInstanceA.Add(whatever);
[18:02:38] * Coren_ groans at the hungarian misnotation.
[18:02:54] <matto|wookin> Colourless : that is correct
[18:03:34] <matto|wookin> however... by doing gdb, and doing "print mInstanceA" it says that the memory cannot be accessed.. although I can still 'step' into the add function, at which point, nothing there can be accessed either and it segfaults
[18:03:45] <matto|wookin> so there aren't any casts going on, nor are they any pointers being used :(
[18:03:56] <Coren_> Wait, there is something I don't get...
[18:03:58] <matto|wookin> at least not that I am aware
[18:04:00] <Colourless> well, obviously mInstanceA isn't a valid object
[18:04:02] <Coren_> B is derived from A?
[18:04:08] <matto|wookin> no, it is not
[18:04:12] <wjp> so that would mean the current B is invalid?
[18:04:31] <matto|wookin> Colourless : but how could it not be a valid object? it should be created when the class is created
[18:04:37] <Coren_> Wait...
[18:04:53] <Coren_> A::SomeFunction() calls Add on WHICH mInstance?
[18:05:03] <Coren_> Since that is a member of a B?
[18:05:11] <wjp> maybe B::SomeFunction()?
[18:05:23] <Coren_> <matto|wookin> then in A::SomeFunction() there is a call that does mInstanceA.Add(whatever)
[18:05:35] * Colourless guesses it should be B::SomeFunction()
[18:05:38] <matto|wookin> hold on ...
[18:05:44] <matto|wookin> ok ... sorry, typo
[18:05:47] <matto|wookin> B::SomeFunction() is what I meant
[18:05:52] <Coren_> Ah, okay.
[18:06:08] <wjp> what's 'this' (and *this) while in B::SomeFunction()?
[18:06:53] <matto|wookin> one moment, firing up gdb.. hehe
[18:07:00] <Coren_> This is clear. B::SomeFunction is being called on an invalid B. Either through a wrong B* or a stale B&.
[18:07:08] * wjp nods
[18:07:46] <matto|wookin> (gdb) print this
[18:07:46] <matto|wookin> $1 = (DataStore *) 0x6f0062
[18:07:46] <matto|wookin> (gdb) print *this
[18:07:46] <matto|wookin> Cannot access memory at address 0x6f0062
[18:07:48] <Coren_> Or, possibly more subtly, though something not a B mistakenly casted/implicitely converted to a B
[18:08:01] <wjp> 0x6f0062? what a peculiar value
[18:08:04] <Coren_> 6f0062 is not a valid heap address under win32
[18:08:15] <wjp> ooh, you just 'disclosed' the name of B :-)
[18:08:21] <matto|wookin> hehe... doh
[18:08:25] <wjp> this is under linux, isn't it?
[18:08:30] <matto|wookin> yes this is under linux
[18:08:32] <Coren_> Gimme a backtrace from that point, matto (possibly editing function names if you want)
[18:08:53] <Coren_> Ah, well then 0x6f0062 is possibly valid, but doesn't *smell* right.
[18:09:05] <Coren_> The alignment is all wrong for a compound object.
[18:09:28] <Colourless> that much is obvious
[18:09:34] <Colourless> it's only word aligned
[18:09:40] <matto|wookin> just a sec, the backtrace isn't showing the whole thing.. lemme fiddle with it a sec
[18:09:52] <Coren_> Just the few 2-3 levels is probably enough...
[18:10:01] <Coren_> I just want to see how 'this' got this value.
[18:10:22] <wjp> the last call from outside B is probably the most interesting
[18:10:50] <Colourless> well, firstly we'd want to know how B::SomeFunction() was called
[18:11:15] <matto|wookin> #0 DS::TZ(wchar_t const*) (this=0x6f0062,
[18:11:15] <matto|wookin> iFS=0x8525eac) at DS.cpp:548
[18:11:15] <matto|wookin> #1 0x082a091b in VFDS::GNT() (this=0x6f0062)
[18:11:15] <matto|wookin> at VFDS.cpp:445
[18:11:25] <matto|wookin> that's all the backtrace is showing, oddly enough
[18:11:29] <Coren_> ~\o He was a skater boy / she said "see you later boy" / He wasn't good enough for her ~\o
[18:11:53] <Colourless> no singing avril songs in #exult *please*
[18:11:54] <matto|wookin> DS is B .. TZ is SomeFunction
[18:11:57] <wjp> lol
[18:11:59] <Coren_> Ah. Then you have something stepping over your stack.
[18:12:23] <matto|wookin> that's right before it makes the call
[18:12:35] <matto|wookin> do I really?
[18:12:39] <Colourless> yes
[18:12:40] <wjp> does sound like stack corruption, yes
[18:12:44] <Coren_> Which would explain why the backtrace gets eaten *and* this gets a strange value.
[18:12:47] <matto|wookin> how does one trace that?
[18:13:04] <Coren_> matto|wookin: One doesn't. One single steps and hopes its not an heisenbug.
[18:13:05] <wjp> any local arrays around?
[18:13:37] <Coren_> matto|wookin: Do you know the code flow that lead to that point?
[18:13:50] <wjp> if there was an out-of-bound array access in VFDS::GNT() it could cause this, couldn't it?
[18:13:50] <matto|wookin> Coren_ : yes
[18:14:12] <Coren_> wjp: Yes, but so could something like this any number of levels up.
[18:14:13] <wjp> or maybe the level above it..
[18:14:20] <Colourless> yes i would guess the problem is in VFDS::GNT()
[18:14:22] <Coren_> matto|wookin: Then what I would do:
[18:14:35] <matto|wookin> I suppose I could do backtraces are regular intervfals and watch to see at what point it starts to look fishy
[18:14:53] <wjp> hm, maybe the level directly above VFDS::GNT() would be most likely? (assuming the out-of-bounds access is somewhat continuous?)
[18:14:55] <Coren_> matto|wookin: put a breakpoint on the outermost function call that uses that instance of B, and single step watching for that pointer to go poof.
[18:15:16] <Colourless> wjp: it depends, i'm just thinking about it
[18:15:37] * wjp is trying to refresh his knowledge of the x86 stack :-)
[18:15:50] <Coren_> A hint: '6f' and '62' look suspiciously like text; are you manipulating a file name per chance?
[18:16:02] <Coren_> Some time before the call to TZ?
[18:16:08] <Colourless> unicode/wide text
[18:16:11] <matto|wookin> ok I put a break on GNT and when it arrives into that function, the backtrace looks normal and this is a different value
[18:16:15] <Colourless> wchar_t const*
[18:16:19] <matto|wookin> (this=0x8519190
[18:16:19] <wjp> oh, yes, of course.. that would explain the 0
[18:16:32] <wjp> that's a normal this value
[18:16:42] <Coren_> Colourless: possibly, or just the tail end of a buffer that contained a few strings one after the other.
[18:17:01] <matto|wookin> Coren_ : good observation.. it probably is text
[18:17:05] <Coren_> Ok; are you manipulating text in GNT at all?
[18:17:09] <matto|wookin> yes
[18:17:27] <Coren_> Chances are you are overrunning a buffer doing it then. :-)
[18:17:27] <wjp> any local char arrays?
[18:17:37] <matto|wookin> well I'll be danged
[18:17:58] <matto|wookin> wjp : I don't think there are any local char arrays... but I'll check hehe
[18:19:13] <Coren_> matto|wookin: count yourself lucky. I spend a *month* tracking down a buffer underrun on the *heap* in LoW. Them are bitches, because heap overruns tend to change whenever you play with debugging.
[18:19:21] <Coren_> s/spend/spent/
[18:19:33] <matto|wookin> ahh... I found the spot where it corrupts my 'this' ...
[18:19:43] <matto|wookin> I'll be really embarrassed if this is a bug that I injected! hehe
[18:20:03] <matto|wookin> I had to do a little tweaking because on windows, wchar_t is 2 bytes big and on linux it's 4 bytes
[18:20:06] <matto|wookin> so maybe I broke something...
[18:20:39] <matto|wookin> wjp: do you live in Leiden by chance?
[18:20:41] <wjp> any fixed buffer sizes would have to doubled then, I guess
[18:20:46] <wjp> matto|wookin: nearby, yes
[18:20:59] <matto|wookin> wjp: my bro was just there on Christmas.. he gave us a call
[18:21:03] <wjp> ("couple of minutes by bike" nearby)
[18:21:08] <wjp> cool :-)
[18:21:14] <Colourless> wjp stack frames in i386 look like this: arg2 arg1 arg0 this CS EIP EBP var0 var1... varN-1 varN
[18:21:37] <wjp> is that in push order or in memory order?
[18:21:42] <Colourless> push order
[18:21:56] <matto|wookin> you guys are pretty smart :) thx for your help hehe
[18:22:05] <matto|wookin> definitely some above average programmers in this channel :)
[18:22:25] <Colourless> arg2 has highest memory address
[18:22:27] <Coren_> matto|wookin: np.
[18:22:28] <wjp> ok, so a overrun in a local var would indeed corrupt the 'this' and backtrace info
[18:22:50] <matto|wookin> normally I expect buffer overruns to crash at the exact spot where the first illegal memory operation occurs... when that didn't happen this time.. that made it difficult to track down hehe
[18:23:21] <wjp> buffer overruns hardly crash where they occur, unfortunately :/
[18:23:27] <Colourless> buffer overruns are like that
[18:23:30] <Coren_> matto|wookin: overruns rarely are deterministic in their effect, this is why they are so easily exploited by malicious malformed data.
[18:23:41] <Colourless> hence the security issues with them
[18:24:32] <Colourless> if you can predictably change the stored EIP and EBP you can cause lots of problems
[18:24:52] <wjp> Colourless: where does the new EBP point in the above list, btw?
[18:25:22] <Coren_> Security programming rule number 1: never use fixed size buffers. rule number 2: if you can't avoid doing (1), make sure no tainted data can get in it. Rule (3) if you can't avoid (2), savagely truncate user data-- better safe than sorry. :-)
[18:25:26] <Colourless> var0 if i'm not mistaken
[18:25:47] <matto|wookin> hmm.. I always use fixed size buffers... hehe...
[18:25:54] <matto|wookin> but lately I've been getting away from that
[18:26:07] <Colourless> wjp: you normally do push ebp, move esp, ebp
[18:26:14] <Colourless> opps
[18:26:28] <Colourless> put esp and ebp the wrong way round :-)
[18:26:54] <matto|wookin> I've been doing some network programming as of late, and it seems to me that fixed sized buffers are sort of mandatory for that sort of thing... but maybe there are other ways
[18:26:54] <wjp> "move dest, src", I guess?
[18:27:01] <Coren_> Law of programming #726: There exists only three number of things. None, One, and Infinity.
[18:27:01] <Colourless> so it would actually be push ebp; mov ebp, esp :-)
[18:27:05] <matto|wookin> socket programming, rather
[18:27:24] <Colourless> wjp: yes it's mov dst, src
[18:27:53] <Coren_> matto|wookin: Ouch. That's the most horrible kind of code to use fixed buffers! Makes your box vulnerable to external attacks!
[18:28:00] <Coren_> Witness the Ping of Death. :-)
[18:28:05] <Coren_> Fixed buffers are Evil.
[18:28:06] <Coren_> :-)
[18:28:24] <Colourless> or CodeRed is a nicer example
[18:29:03] <Coren_> But seriously, robust code must handle zero, one, or a variable quantity of anything. There is never a good reason to limit something to some n number where n>1.
[18:29:35] <matto|wookin> Coren_ : well I am thinking specifically about the recv() function which takes as one of its arguments, the size of your receive buffer
[18:30:31] <Coren_> Ah, yes, but recv() obeys rule (3). If it doesn't fit, truncate it savagely. :-)
[18:31:29] <Coren_> But protocols which used fixed size packets are broken at any rate-- if not now, then at some future point when someone realizes they would have needed 'one more byte' for the application du jour.
[18:31:52] <matto|wookin> so I guess you are much against sprintf? sprintf is one of my favorite functions, despite the buffer overflow dangers... but I would love to find a safe replacement that is as convenient
[18:32:01] <Coren_> vsnprintf()
[18:32:04] * Coren_ smiles.
[18:32:23] <Colourless> or snprintf (or _snprintf)
[18:32:26] <matto|wookin> is that available on wind0ze too? hehe
[18:32:48] <Coren_> But yes, using sprintf() with user-provided data is making certain there exists at least one point of attack to your program.
[18:33:04] <Colourless> _snprintf and _vsnprintf are available in windows
[18:33:14] --> kuran has joined #exult
[18:33:21] <Coren_> I do security audits and disaster recovery for a living; any code which contains sprintf() [or, worse, gets()] is automatically marked as insecure.
[18:33:22] <matto|wookin> ah... in that case, I will begin using those from now on :)
[18:33:31] <matto|wookin> haha I love gets! ...
[18:33:33] <matto|wookin> j/k
[18:33:45] <Colourless> the functions though are not standard ANCI C/C++ though so there will likely be some variation on the naming of them
[18:34:02] <Coren_> snprintf() is ISO C.
[18:34:03] <matto|wookin> Colourless I might have to use a macro or something
[18:34:15] <Colourless> Coren_: C99?
[18:34:21] <Coren_> IIRC, yes.
[18:34:33] <Colourless> well, then, that would be it :-)
[18:35:02] --- Dark-Star is now known as Dark-Star|away
[18:35:26] <Coren_> Mind you, the fact that some feature x is part of the standard of the language means the probability of MSVC implementing it at all is roughly 95%, 80% if you insist on correct implementation. :-)
[18:36:41] <Coren_> ~\o Yo! Listen up, here's the story / About a little guy that lives in a blue world ~\o
[18:38:29] <Colourless> yep [v]snprintf are new in C99
[18:38:37] <Coren_> Is Effeil 65 kosher for #exult? ;-)
[18:39:22] <Coren_> s/ffeil/iffel/
[18:39:26] <matto|wookin> strcpy must also be bad, I suppose?
[18:39:31] * matto|wookin uses strcpy like there is no tomorrow
[18:39:42] <Colourless> yes it's evil too
[18:39:44] <matto|wookin> maybe it's time I broke down and started using STL strings
[18:40:01] <Coren_> matto|wookin: It is *probably* evil, but can be secure if you *know* the size of the source.
[18:40:16] <Coren_> matto|wookin: strncpy() is better in most cases.
[18:40:17] <Colourless> Coren_: think of it this way, anyone who names a song like 'sk8terboi' (I hope i've got it correct) is not allowed
[18:40:40] <Colourless> and i know i've got it wrong :-)
[18:41:05] <matto|wookin> my only gripe with strncpy is it does not null-terminate the string if it copies its limit.. I'd like it to always null-terminate the string even if it means chopping off the last character
[18:41:18] <Coren_> ~\o Daddy DJ, please take me to the party / and let the music play until the break of day ~\\o
[18:41:54] <Coren_> void mycopy(char* dest, const char* src, size_t len) { strncpy(dest, src, len-1); dest[len-1]=0; };
[18:42:00] <matto|wookin> heh
[18:42:12] <matto|wookin> indeed
[18:43:10] * Colourless almost but doesn't quite change the topic to: Secure Programming Lessing in #exult right NOW!
[18:43:25] <Colourless> s/lessing/lessons/
[18:43:48] <Coren_> STL is a collection of security holes. Never use it in secure applications.
[18:43:54] <matto|wookin> :(
[18:44:07] <matto|wookin> well, I guess Exult isn't secure
[18:44:22] <Coren_> In *theory* is is secure. Someday perhaps there will exist a correct implementation.
[18:44:30] <Colourless> wjp: I guess that means that Pentagram has got to stay off of networks :-)
[18:44:37] <wjp> Colourless: of course :-)
[18:44:49] <Coren_> Exult probably isn't, but exult has no privileges above that of the user running it so it's not an issue.
[18:44:54] <wjp> Colourless: hm, this may be a good argument for not doing multiplayer ;-)
[18:44:58] <matto|wookin> my daphne project doesn't use any STL, but it is full of strcpy and sprintf... but ... I can change that
[18:45:03] <Colourless> wjp: indeed :-)
[18:45:32] <Coren_> wjp: Actually, it would be.
[18:46:00] <Coren_> wjp: That is part of the reason I've never played multiplayer games from my production boxen.
[18:46:11] <matto|wookin> !
[18:46:15] * matto|wookin stares guiltily at the floor
[18:46:36] <Coren_> matto|wookin: No need to; few people are quite as paranoid as I am about security. :)
[18:46:55] <Coren_> matto|wookin: But I'm paid to be extremely paranoid. :-)
[18:47:00] <matto|wookin> I am by far the most paranoid security person here at work
[18:47:12] <Coren_> And you use sprintf()! :-)
[18:47:14] <Colourless> you work for microsoft dont you?
[18:47:43] <matto|wookin> not at work, I don't use sprintf... I use C# here, which doesn't require sprintf
[18:47:44] <Coren_> Colourless: I *hope* that question wasn't directed at me!
[18:47:57] <matto|wookin> nor does it require strcpy for that matter
[18:47:58] * Colourless was directing it to matto|wookin
[18:48:23] * Coren_ is unaware of the security implications of C#, but given MS's track record on security, I wouldn't touch it with a ten foot pole.
[18:48:29] <matto|wookin> lol
[18:48:39] <matto|wookin> I am not paid to be worried about security though..
[18:48:54] * Coren_ chuckles.
[18:49:17] <Colourless> then you really MUST be working for MS if you are the most security paranoid persion where you work :-)
[18:49:25] <matto|wookin> but I do frown on my work's practice of emailing clients their passwords, not using SSL, and using cookies for authentication *frown* ... I've expressed my displeasure about that more than once... but they all look at me as if I am trying to give them more work to do than they already have
[18:49:26] <Coren_> That, I think, is the crux of the problem. MS doesn't seem to have *anybody* paid to worry about security. :-)
[18:49:39] <matto|wookin> oh ya, everyone here has super weak passwords (Except me of course!)
[18:50:02] <Colourless> that would be a problem in most places (weak passwords)
[18:50:09] * Coren_ laughs.
[18:50:24] <matto|wookin> I also setup a firewall on my box hehe...
[18:50:30] <Coren_> If you had an account on my box, Colourless, I can GARANTEE you wouldn't have a weak password. :-)
[18:50:49] <matto|wookin> I discovered (to my dismay) that any Windows Admin could just open up my C: drive remotely whenever they pleased... no longer
[18:51:05] <Coren_> My passwd refuses anything that fails three different cracklibs. :-)
[18:51:16] <matto|wookin> Coren_ : where did you get that passwd? I want it
[18:51:52] <Coren_> matto|wookin: It's actually just PAM configured creatively.
[18:51:58] <matto|wookin> oh I see
[18:53:20] <Coren_> Hell, even sometimes *my* passwords get refused because they were guessable in a way not obvious to me. :-)
[18:53:28] <matto|wookin> hehe
[18:53:34] <Coren_> And I use good passwords.
[18:53:42] <Coren_> Old example: xky7%0nM
[18:53:45] <Colourless> matto|wookin: I expect that we all get a special thanks in Dragon's Lair 3D linux port credits :-)
[18:54:05] <matto|wookin> Colourless : hehe... if they'll let me, sure :)
[18:55:12] * Coren_ starts.
[18:55:15] <Coren_> Wait a minute.
[18:55:32] <wjp> that was your current password? :-)
[18:55:39] <matto|wookin> hehe
[18:55:39] <Colourless> hehe
[18:55:52] <Coren_> matto|wookin: You work for the the Borg Coll^M^M^M^M^M^M^M^M^M Microsoft? And you are doing a *linux* port?
[18:56:03] <matto|wookin> Coren_ : no I don't work for MS
[18:56:07] <Coren_> Ah!
[18:56:12] <matto|wookin> Cless was just joking
[18:56:13] <Colourless> Coren_: the MS was just a joke :-)
[18:56:22] <wjp> ^M? wasn't that a CR?
[18:56:32] <Coren_> wjp: Yes. Braino.
[18:56:42] <Coren_> I /meant/ ^H
[18:56:58] <matto|wookin> I was a bit dismayed to read somewhere that they ported ROTT to linux in 24 hours... since I've been working on this danged thing for over a week now
[18:57:07] * Coren_ chuckles.
[18:57:18] <Coren_> ROTT wasn't written for MSVC
[18:57:22] <matto|wookin> hehe
[18:57:31] <matto|wookin> and probably in C too
[18:57:39] * matto|wookin is just guessing
[18:57:49] <Coren_> Actually, I found that most any old thing written to compile with borland tools will usually port to SDL in hours.
[18:58:00] <matto|wookin> oh ya?
[18:58:09] <matto|wookin> I've written some old DOS stuff in Turbo C++ 3.0
[18:58:15] <Coren_> Borland used to have one hell of a good tool chain.
[18:58:17] <matto|wookin> it used some weird stuff like conio.h
[18:58:34] <Colourless> well, conio.h is so dos centric
[18:58:34] <kuran> is there a site where I can get up-to-date on all things ROTT?
[18:58:40] <matto|wookin> kuran!!!
[18:58:46] <kuran> eek, hello :)
[18:58:55] <matto|wookin> try icculus.org, I think they are hosting it
[18:59:10] <kuran> just interested in any developments on an osx port :)
[18:59:15] <matto|wookin> hehe
[18:59:17] <Coren_> Kuran!!! KURAN!!! Kuran is awake! Joy! Rapture!!!! ... err, who is kuran?
[18:59:28] <kuran> thats what I was thinking :)
[18:59:42] <matto|wookin> I am still trying to get Fingolfin to get daphne ported to OSX .. but he hasn't appreciated my X86 assumptions in the code hehe
[18:59:43] <Colourless> hell if i know. just some person who wondered into #exult
[18:59:57] <kuran> erm
[19:00:09] <kuran> im just an exult user
[19:00:17] <kuran> and Im trying to catch the guy who did the osx port
[19:00:32] <Coren_> Well, at least *I* have a good reason to be here. I'm basking in Exult glory so that I can subly divert some attention to LoW. :-)
[19:00:33] <wjp> did you catch Fingolfin's comment last night?
[19:00:39] <matto|wookin> kuran : you mean Fingolfin? hehe...
[19:00:41] <kuran> no wjp
[19:00:55] <Colourless> kuran it works like this: as long as you are here, fingolfin will not be here :-)
[19:00:55] <wjp> <Fingolfin|afk> kuran: 10.2.3 has nothing to do with the bug. it's the development system version that matters
[19:01:00] <matto|wookin> lol
[19:01:08] <kuran> that was updated recently too
[19:01:16] <kuran> thanks
[19:01:32] <wjp> yes, but Fingolfin didn't get the chance to try the latest version yet. (a couple of days ago, anyway)
[19:02:05] <Coren_> Talking about that; I should probably try to coax/bully/bribe him to take a peek at LoW too.
[19:02:20] <matto|wookin> ok.. I'll bite.. what is LoW ?
[19:02:36] * Coren_ pounces on matto. "You said the magic word!!!!"
[19:02:41] * Coren_ chuckles.
[19:02:54] <Coren_> Labyrinth of Worlds; an UW2 engine rewrite I'm working on.
[19:03:00] * matto|wookin wonders if Coren_ is related to Darke with his 'pouncing' hehe
[19:03:17] <matto|wookin> ah ha
[19:03:29] <matto|wookin> Under World 2 ?
[19:03:33] <matto|wookin> is that what UW2 stands for
[19:03:37] <Coren_> Without the space, yes. :-)
[19:03:39] <Colourless> low: adj. not tall, high or elevated :-)
[19:03:40] <matto|wookin> ok
[19:03:44] <matto|wookin> I didn't know they had a 2
[19:03:54] <Coren_> Eeep!
[19:04:05] <matto|wookin> did it use the same engine as the first one?
[19:04:21] <Colourless> yes it pretty much did
[19:04:27] <Coren_> 'twas the best! It was an incredible follow up to U7, and is probably the best background on the Guardian.
[19:04:27] <matto|wookin> the first one was the one used in system shock, right?
[19:04:39] <Colourless> the engine was also updated for System Shock
[19:04:49] <Coren_> matto|wookin: Yes, with slight improvements (bigger view, higer resolution sprites)
[19:04:50] <matto|wookin> ya I remember it.. it was pretty cool, I used to watch my brother playing it
[19:05:01] <matto|wookin> the old 486/33 days
[19:05:07] <Colourless> then from what I know, some elements then made it into Terra Nova
[19:05:10] <Coren_> matto|wookin: LoW uses OpenGL for rendering, though, so it looks marginally better. :-)
[19:05:16] <matto|wookin> well I should hope so!
[19:05:33] <matto|wookin> I want to learn how to do the elusive per-pixel-lighting in opengl
[19:05:51] <Coren_> matto|wookin: I'm just being falsely modest. LoW looks pretty nice, and it has a kick ass font!
[19:05:54] * Coren_ chuckles.
[19:06:08] <matto|wookin> is the font done using bitmaps or polygons?
[19:06:21] <Colourless> i would imagine both
[19:06:24] <Coren_> matto|wookin: both.
[19:06:26] <matto|wookin> hehe
[19:06:27] * Coren_ smiles.
[19:06:43] <matto|wookin> is it a 3D font? or a 2D one
[19:07:29] <Coren_> 2d, but it looks really really good. Did I mention I am very satisfied with it. 100% of respondents in an informal survey liked it. (four people have seen it to date, me included). :-)
[19:07:51] <Colourless> impressive
[19:08:08] <matto|wookin> for a game I did earlier this year, I used a 3D font... it looked really cool on my geforce3 and Athlon 1.4 ghz... I tried it on a Rage 128 and it was way too slow though..
[19:08:49] <Colourless> 2d fonts are generally more useful
[19:09:03] <matto|wookin> I am sure that a 2D font can look good, make no mistake.. as long as it is a high enough resolution so it doesn't turn into a filtering mess when scaled hehehe
[19:09:08] <Colourless> of course with 3d fonts you can do some cool effect
[19:09:17] <Colourless> s
[19:09:28] <Coren_> matto|wookin: Mine aren't high resolution, but the alpha channel is hand tweaked. :-)
[19:09:41] <matto|wookin> http://www.cs.utah.edu/~ownby/entombed-0502.zip
[19:09:52] <matto|wookin> there's the game I did, you can see the font for yourself hehe
[19:09:57] <matto|wookin> that's a windows binary, BTW
[19:09:57] <Colourless> i guess if you want really large characters, then you are possibly best to go with some 3d fonts
[19:10:10] <Coren_> Where is the source?
[19:10:18] <matto|wookin> safely stashed in my CVS
[19:10:27] <Colourless> however, you run into the distinct problem of really bad aliasing when you reduce the size of the characters
[19:10:40] <matto|wookin> indeed
[19:10:56] <Coren_> Stroke fonts suffer from low resolution rendering unless VERY well hinted.
[19:11:15] <Coren_> Ah, well then I won't be able to play your game. Do you have screenshots>?
[19:11:37] <matto|wookin> a slightly old one
[19:11:41] <matto|wookin> http://group.rulecity.com
[19:11:45] <matto|wookin> you can see the font there
[19:11:53] <matto|wookin> at the bottom
[19:12:41] <matto|wookin> of course, the it looks really cool while running because the currently selected menu item bounces in and out and changes colors :)
[19:12:43] <Coren_> Looks prutty! :-)
[19:12:49] <matto|wookin> and the 'entombed' letters pop in and out hehe
[19:13:01] <Colourless> it's.... a picture of you??
[19:13:06] <matto|wookin> yes that's me
[19:13:23] <matto|wookin> apparently my teammates took their pictures offline.. it was a 3-person group project for our senior CS project
[19:14:21] <Coren_> Heh. You're taking MAME on? Sheesh.
[19:14:35] <Coren_> You like tall orders, do you?
[19:16:23] <Coren_> I should probably make a new screenshot for my main page with a conversation.
[19:17:55] <matto|wookin> not really taking MAME on, precisely... daphne does something that mame doesn't do
[19:18:12] <matto|wookin> in fact, quite a few people have told me that they have a "mame/daphne" box ... which I think is pretty cool :)
[19:19:29] <Coren_> I have a mame box in an arcade cabinet. I'll have to take a look at daphne. :-)
[19:21:35] <matto|wookin> yes you will :)
[19:21:46] <matto|wookin> I haven't been able to work on it that much lately, but I would like to get back to it
[19:25:36] <Colourless> i think it's about time i left
[19:25:37] <Colourless> cya all
[19:25:40] <-- Colourless has left IRC ("casts invisibility")
[19:25:40] <matto|wookin> http://www.xmission.com/~redflame/cs4500-project.tar.bz2
[19:25:46] <matto|wookin> there's the source code to our game
[19:26:04] <matto|wookin> I did keep it up to date on linux, so it should compile 'out of the box'
[19:27:16] <Coren_> There, I have added a "conversation" screenshot to the main low page.
[19:28:00] <matto|wookin> and that can be found at ? ...
[19:28:16] <wjp> low.sf.net
[19:28:20] <Coren_> http://low.sf.net/
[19:30:12] <matto|wookin> ahh neat
[19:30:20] <matto|wookin> does that use data from the original game?
[19:30:25] * Coren_ nods.
[19:30:36] <wjp> Coren_: one of the captions there says "etheral plane"
[19:31:41] <matto|wookin> that looks like a cool project
[19:32:43] <Coren_> wjp: I'll fix it. Soon.
[19:32:46] * Coren_ grins.
[19:32:55] <Coren_> Actually, I expect you have the permissions to.
[19:34:00] <Coren_> glm.h:288:7: warning: no newline at end of file
[19:34:00] <Coren_> In file included from main.cpp:19:
[19:34:01] <Coren_> chat.h:19: ISO C++ forbids declaration of `init' with no type
[19:34:01] <Coren_> In file included from main.cpp:19:
[19:34:02] <Coren_> chat.h:31:32: warning: no newline at end of file
[19:34:02] <Coren_> ../shared/game.h:101: warning: `const char*g_penalty_names[9]' defined but not
[19:34:03] <Coren_> used
[19:34:10] <Coren_> Looks like your bits have rotten.
[19:34:30] <Coren_> Doesn't my font look great? :-)
[19:34:35] <wjp> Coren_: indeed I do. fixed :-)
[19:36:53] <Coren_> Erp. Maybe I should have shut seti@home down before I made the screenshot. that 7.6fps displayed isn't very flattering. :-)
[19:37:04] <wjp> hehe :-)
[19:40:33] <matto|wookin> Coren_ : how about giving init a type then? hehe
[19:41:10] <matto|wookin> it is doubtless void if we never gave it a type before...
[19:41:43] <Coren_> I expect so.
[19:42:04] * matto|wookin looks at the code
[19:42:05] <matto|wookin> yes, definitely void
[19:42:33] <matto|wookin> apparently I used g++-2.95 to compile it and it didn't complain
[19:43:17] <Coren_> gcc <3 is a bit overly permissive.
[19:43:39] <Coren_> It works, but the framerate is abysmal.
[19:44:35] <Coren_> The font is amusing though.
[19:44:47] <matto|wookin> ya... we targetted it for geforce3's and athlon 1400's which is what the school had (and what I had at home)
[19:44:49] * Coren_ gets <2fps
[19:45:18] <Coren_> I meet those specs, basically.
[19:45:42] <matto|wookin> odd... it should be quite smooth
[19:47:50] <matto|wookin> a bit choppy on this Rage 128 at work.. hehe...
[19:48:20] <matto|wookin> if you start a game, the framerate should theoretically improve
[19:49:05] <matto|wookin> then again I haven't tested it.. it might not.. lol
[19:49:17] <Coren_> Doesn't; but there are odd effects far in the background-- this may be an SDL version oddness, or GCC >=3 problems.
[19:49:28] <matto|wookin> hmm...
[19:53:07] <wjp> it's semi-smooth on my athlon 1800, tnt2 ultra
[19:53:48] <matto|wookin> I'd play a game with you guys, but I'm at work... perhaps later <grin> ... I haevn't played it for a while hehe
[19:54:29] <matto|wookin> it works really well with high latency connections... unfortunately this also makes it vulnerable to cheating...
[20:56:54] <matto|wookin> ah ha... I fixed the buffer overrun problem :)
[20:59:24] <matto|wookin> it was related to the wchar_t issue
[22:01:25] <-- kuran has left IRC ()
[22:01:53] --> kuran has joined #exult
[22:07:36] <-- kuran has left IRC ()
[23:03:55] --- Dark-Star|away is now known as Dark-Star
[23:08:10] --> Fingolfin has joined #exult
[23:08:11] --- ChanServ gives channel operator status to Fingolfin
[23:08:28] <wjp> hi
[23:08:33] <Fingolfin> yo
[23:27:45] <matto|wookin> hi
[23:47:08] <-- matto|wookin has left IRC (capek.freenode.net irc.freenode.net)
[23:47:18] --> matto|wookin has joined #exult