#pentagram@irc.freenode.net logs for 2 Jan 2005 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:06:59] --> Kirben has joined #pentagram
[00:06:59] --- ChanServ gives channel operator status to Kirben
[00:28:26] <wjp> *phew*
[00:28:44] <wjp> got rid of all 'old' flex-type objects except for the savegames
[00:29:00] <wjp> hm, and some tools
[00:29:35] <wjp> gives me something to do tomorrow, I guess :-)
[00:29:37] <wjp> g'night
[00:30:02] <sbx> bye
[01:53:34] <-- Darke2 has left IRC ("Inficio-Infeci-Infectum")
[01:54:26] --> Darke has joined #pentagram
[03:26:30] <-- sbx has left IRC ("clicks the exit button")
[03:51:33] --> sbx has joined #pentagram
[04:38:54] <watt> well, I think that's the first time I ever got bit hard by signed vs. unsigned.
[04:39:44] <watt> something like "for(uint32 i = size - 1; i >= 0; --i)" just doesn't quite work
[04:41:19] <Darke> IIRC, there's a warning in gcc you can turn on to catch that.
[04:44:50] <Darke> (It should spit out something like, 'warning: test for i>=0 will always be true')
[04:51:03] <sbx> is there a better way to do that loop without sint32?
[04:53:04] <sbx> I have used it many times
[04:56:00] <watt> I used "for(uint32 i = size; i > 0;) { --i; }" to solve my issue
[04:56:28] <Darke> `for(uint32 i = size - 1; i >= 0; --i) { /* do stuff here */ if(i==0) break; }`? I usually just make it a sint32 myself, or reverse the algorythm to run ++ rather then --. I don't really see why there'd be a problem with using sint's, unless you had more then 2,000,000,000-ish entries in the array. *grin*
[04:57:28] <Darke> That works too. *grin*
[05:20:42] <watt> hmmm... GIMP_PLUGIN_DEBUG environment variable... yeah... that would be great right now.
[05:22:57] <watt> which is seeming to be very slow... hmmm.
[05:28:13] <watt> oh... I see.. I need to start the debugger
[05:42:49] --> Colourless has joined #Pentagram
[05:42:49] --- ChanServ gives channel operator status to Colourless
[05:52:50] <sbx> hi Colourless
[05:53:19] <watt> hi
[05:56:22] <Colourless> hi
[06:08:49] <watt> bleh..... this is lame... having to set a breakpoint on free to find out how a pointer is getting freed twice
[06:26:40] <watt> ahh.. user defined commands... that speed up my search quite a bit
[06:35:50] <watt> hmmm.. I think the problem is in my copy of gimp or a library gimp is using... well, good excuse to finally upgrade
[08:43:07] <-- Chetic has left IRC (Read error: 110 (Connection timed out))
[09:16:17] --> Chetic has joined #pentagram
[11:06:26] --> sbx|afk has joined #pentagram
[11:06:45] --- sbx|afk is now known as sbx2
[11:17:18] <-- sbx has left IRC (Read error: 60 (Operation timed out))
[12:57:19] <-- Kirben has left IRC ("System Meltdown")
[13:00:26] <-- Chetic has left IRC ()
[13:14:34] --> Chetic has joined #pentagram
[13:16:04] <wjp> zipped saves...
[13:16:25] <wjp> we could again store the description as the zip's global comment
[13:20:37] --- sbx2 is now known as sbx|afk
[14:31:06] <wjp> well, zipped saving and loading is working now as well
[14:31:51] <wjp> savegame is 136Kb at startup
[14:33:13] <wjp> I guess I should start thinking about committing all this :-)
[14:37:19] <wjp> any objections to using 'filesys/zip' as the directory to put the zip/unzip C files?
[14:37:19] --- sbx|afk is now known as sbx
[14:38:18] <watt> that sounds ok
[14:38:19] <Colourless> nope
[14:38:23] <Colourless> find with me
[14:42:05] <watt> hmmm... ok, I have no idea what pitch should be set to.
[14:42:40] <Colourless> pitch should be the number of bytes per line
[14:58:11] <wjp> ok, committed
[14:59:00] <wjp> I wonder if we'll have to convert those really-old-C style files to somewhat more modern C/C++
[15:00:23] <Colourless> um
[15:00:38] <Colourless> if they are using 'old style' C declarations, then yes :-)
[15:00:46] <wjp> fun :-)
[15:01:16] <wjp> I didn't use the already converted ones in exult because the newest version had i/o abstraction code already in it, by the way
[15:01:28] <Colourless> yeah i know :-)
[15:01:52] * wjp volunteers Darke to convert those files ;-)
[15:02:17] <Colourless> hehe
[15:02:44] <wjp> there was actually a bug in zip.c... it wouldn't compile if you disabled the ability to append to existing zip files
[15:02:51] <wjp> misplaced #ifdef
[15:05:31] <wjp> I guess I'll start converting those old files then :-)
[15:19:43] <wjp> ok, zip.cpp compiles with g++ now
[15:21:05] <wjp> I'm hoping that means MSVC will accept it too
[15:22:04] <Colourless> i would imagine it probably would
[15:24:00] <-- sbx has left IRC (Read error: 110 (Connection timed out))
[15:31:38] <wjp> ok, done
[15:31:48] <wjp> I hope they work for you now
[15:32:19] <Colourless> the old style would have worked
[15:32:26] <Colourless> but produced a million warnings :-)
[15:33:08] <wjp> now you tell me ;-)
[15:33:40] <wjp> fits in better with the linux build system now as well
[15:34:01] <Colourless> mixing c and c++ in 1 app is a pain though
[15:34:51] <Colourless> did you put the zip stuff in to pentagram namespace?
[15:35:30] <wjp> hm, no
[15:35:51] <Colourless> i imagine that it probably would be a good idea since zlib might be used in some other module loaded by pentagram
[15:36:36] <wjp> zlib itself is just linked normally as a library
[15:37:07] <Colourless> but those files
[15:37:18] <Colourless> could cause problems
[15:37:36] <wjp> we could put them in a namespace
[15:37:37] <Colourless> like the conflict between the fmsynth driver and sdl_mixer remember
[15:37:58] <wjp> maybe PentZip or something
[15:38:19] <Colourless> also need #include "pent_include.h" as well, MSVC build sort of needs it
[15:39:00] <wjp> should probably remove the extern "C"'s as well then
[15:39:27] <Colourless> yeah
[15:47:46] <Colourless> wjp, you forgot to include ctime in guiapp
[15:50:33] <wjp> committed another C++ update
[15:50:34] <wjp> I did?
[15:50:42] <Colourless> yes
[15:50:54] <wjp> right; fixed
[15:54:42] <wjp> forgot pent_include in ioapi.cpp; fixed now
[16:30:28] <wjp> saving is no longer instantaneous :/
[16:31:14] * Colourless can't load pentagram
[16:31:20] <Colourless> gets assertion failure
[16:31:36] <Colourless> in TypeFlags::loadArmourInfo()
[16:32:16] <wjp> which one?
[16:32:49] <Colourless> assert(msf->getShape(ai.shape));
[16:33:00] <Colourless> ai.shape is 0x00000212
[16:33:27] <wjp> hm, that sounds like an acceptable value
[16:33:34] <Colourless> it is
[16:33:41] <Colourless> armgaurds
[16:34:20] <wjp> what's msf->count ?
[16:35:09] <Colourless> 0
[16:35:23] <wjp> hm, so it didn't manage to load the shapes
[16:36:02] <Colourless> hmm... no... and i'm guessing config ends up sorting alphabetically and armguards are 1st of the top
[16:36:08] <Colourless> lets see why
[16:37:02] <wjp> FlexFile::isFlexFile and FlexFile::FlexFile are probably interesting places to look
[16:37:26] * Colourless does step by step look at the process of loading the file
[16:38:22] <Colourless> oh
[16:38:33] <Colourless> it's because it doesn't think my flex is a flex
[16:38:56] <Colourless> it checks the first 0x52 bytes for 0x1A
[16:39:00] <Colourless> my shape flex doesn't have that
[16:39:07] <wjp> really?
[16:39:22] <Colourless> yeah, shapeconv'd
[16:39:37] <Colourless> first 0x50 bytes are the 'comment'
[16:39:40] <Colourless> or description
[16:40:04] <Colourless> no wait
[16:40:08] <Colourless> ignore that
[16:40:28] <Colourless> i was reading the code wrong
[16:41:07] <Colourless> it still doesnt think i have a flex
[16:41:28] <Colourless> it goes 0x52 bytes without finding 0x1a and auto fails
[16:41:40] <wjp> but you do have 0x1a's?
[16:42:33] <Colourless> no, i don't. it's all 0
[16:43:21] * wjp looks at ShapeConv.cpp; ah
[16:45:04] <Colourless> perhaps we need to ensure that all the flexes have the 0x1a's then
[16:45:13] <Colourless> u8's flexes don't have any easy way to detect
[16:45:17] <Colourless> no magic numbers like u7s
[16:45:25] <Colourless> even if everything else is the same
[16:49:03] <wjp> yeah, it would be easy to change shapeconv to output 0x52 0x1A's
[16:49:27] <wjp> flexpack already does that, it seems
[16:55:39] <Colourless> silly thing...
[16:55:47] <Colourless> the 'songs' array
[16:55:57] <Colourless> in MusicFlex doesn't get zero'd when created
[16:56:03] <Colourless> so it's crashing
[16:57:49] <Colourless> finally, it runs
[16:57:54] <wjp> ah, oops
[16:58:34] <Colourless> zeroing memory is as far as I know, is implementation dependant behaviour
[16:58:41] <wjp> yeah, I know
[16:58:59] <wjp> it's just that all the other flexes were using vectors for the cached objects, and those do get zeroed
[16:59:05] <Colourless> yeah
[16:59:19] <Colourless> wonder why music is different
[16:59:56] <Colourless> should probably update it to use vectors
[17:00:02] <Colourless> code would be cleaner
[17:00:19] <wjp> does saving/loading work?
[17:01:03] <Colourless> it would appear so
[17:01:34] <wjp> did you have to change much to get things to compile and run?
[17:01:41] <Colourless> no :-)
[17:01:45] <wjp> good :-)
[17:01:56] <Colourless> music flex and my shape flex
[17:02:11] <Colourless> that is the MusicFlex class, and add 0x1a to my shape flex
[17:02:24] <Colourless> everything else was cool
[17:02:52] <Colourless> hmm.. the mouse
[17:03:02] <Colourless> should it be always 'centered' on the avatar?
[17:03:19] <Colourless> at the moment it's always 'centered' on the center of the screen
[17:03:26] <Colourless> i can't remember how the original acted
[17:04:40] <watt> I think it should be centered on thwe avatar.... but I'm not sure either
[17:05:00] <Colourless> it feels wrong as it is at the moment in conversations
[17:05:03] <wjp> I think it's currently centered a couple of pixels below the center of the screen
[17:05:22] <wjp> to coincide with the avatar's feet when the camera is on the avatar
[17:06:02] * wjp checks
[17:06:35] <Colourless> hmm... the
[17:06:45] <wjp> the original keeps it centered around the center of the screen
[17:07:05] <Colourless> the process spawned by the guard ouside the tenebrae gates in the docks is causing an error
[17:08:06] <watt> yup
[17:09:03] <wjp> let's see
[17:09:32] <wjp> one of these days I'll make watch_item/watch_class something that can be controlled from pentagram's console...
[17:09:58] <wjp> hm, pushing an illegal string
[17:10:17] <wjp> I wonder if I screwed up UsecodeFlex
[17:12:16] <watt> I can't seem to remember how the mouse worked in the test of centeredness
[17:14:49] <watt> ah... crap.. I should have seen that error coming... well, at least I finally noticed... negative x offset on the frame I believe
[17:21:57] <wjp> wow, amazing I didn't catch that bug earlier
[17:24:32] <wjp> that must've been there for years
[17:24:41] <watt> wohoo... my palette is definitely wrong... but I can load the graphics now
[17:24:48] <wjp> fixed in CVS
[17:27:48] <Colourless> wtf.... that bug
[17:28:13] <Colourless> how did you find that
[17:30:37] <wjp> hm, I was guessing the size of the datasource was getting set wrong
[17:31:11] <wjp> since the usecode trace was showing correct bytes up to the string, and then suddenly garbage
[17:34:08] * watt nods... that was the zero size'd datasource I ran into yesterday.
[17:35:15] <watt> hmm... well, now I gotta figure out how to draw these pixels only if they get set.. (I currently have no transparency)
[17:35:16] <wjp> hm, the new year is a good opportunity to change the '4' news posting schedule... *thinks*
[17:35:26] <Colourless> hehe
[17:35:44] <Colourless> 5!
[17:35:53] <watt> YEAH!
[17:35:56] <Colourless> strangly appropriate for Pentagram
[17:35:58] <wjp> would work :-)
[17:36:56] <wjp> watt: does gimp have an 'indexed with alpha' mode?
[17:37:40] <wjp> GIMP_INDEXEDA_IMAGE
[17:37:57] <wjp> I guess you'd have to use uint16's for the pixels
[17:38:07] <wjp> initialize everything to fully transparent
[17:38:27] <wjp> expand pal to uint16[], fully opaque
[17:38:49] <watt> yup.. it's the SoftRenderSurface.inl I have to deal with... currently it sets pixels as guchar's and I go back through the buffer and moved them and set i * 2 + 1 to 255
[17:39:24] <wjp> I think using pal would work better
[17:39:42] <Colourless> same here
[17:39:43] <wjp> you'd get transparency for free
[17:39:55] <watt> oh yes, I agree
[17:41:37] <wjp> Colourless: that .inl is really quite flexible :-)
[17:42:00] <watt> for (int i = 0; i < 256; ++i) {pal.native[i] = (i << 16) + 255; }???
[17:42:13] <watt> yes, it is flexible ;-)
[17:42:45] <wjp> watt: depends on how gimp expects the pixels
[17:42:49] <Colourless> well, it was designed to be able to handle 'almost' any situation could would want
[17:43:31] <wjp> I think the alpha is probably the MSB, though
[17:44:12] <watt> gimp want buf[i] to be the index and buf[i + 1] to be the alpha and buf is a unsigned char *
[17:44:40] <wjp> on both LE and BE systems?
[17:44:55] <wjp> then you'd have to make the pal array endian-dependant
[17:45:02] <watt> I believe so.
[17:45:12] <wjp> the one you gave would be for BE
[17:45:32] <wjp> SDL has some defines you can use for endianness
[17:45:38] <Colourless> setup a char array then cast to uint16
[17:45:54] <wjp> hm, yes, that might work better :-)
[17:45:58] <watt> I think I like that solution.
[17:50:16] <watt> guchar palHack[2]; palHack[1] = 255; for (int i = 0; i < 256; ++i) {palHack[0] = i; pal.native[i] = *((uint32 *) palHack); }
[17:50:22] <watt> does that seem right?
[17:50:32] <wjp> uint16*
[17:51:10] <watt> would it matter that native is a uint32 array?
[17:51:45] <wjp> hm?
[17:51:49] * wjp checks the .inl
[17:52:58] <wjp> oh, I see
[17:53:23] <wjp> it has to be uint16*
[17:53:30] <wjp> otherwise you'd be reading past the end of palHack
[17:53:45] <watt> oh right..
[17:53:49] <wjp> it doesn't matter than the native[] array is itself larger
[17:53:53] <wjp> s/than/that/
[17:59:43] <watt> that was a fairly neat hack
[17:59:47] <watt> works too
[17:59:52] <wjp> cool :-)
[18:00:03] <wjp> got any screenshots already? :-)
[18:01:51] <watt> not yet.. I want palettes to be right first.. evidently I can't simply take pentagram's palettes and cast them to (guchar *)
[18:02:30] <wjp> I can see how that would ruin screenshots, yes :-)
[18:02:38] <watt> also, I'm going to want to unpack a shape a bit more impressive than the fonts :-)
[18:02:51] <Colourless> pentagrams palettes are probably 32 bit or whatever format you've set everything up in
[18:02:56] <wjp> gimp has 24 bit palettes
[18:03:01] <Colourless> and gimp probably wants 24 bit
[18:04:01] <watt> we appear to have a palette of uint8 palette[768]... although I'm probably misusing that
[18:04:34] <wjp> hm, no, that should be ok
[18:04:57] <Colourless> what exactly is the problem your seeing?
[18:05:45] <watt> probably order. I'm not sure
[18:06:43] * Colourless asks again
[18:06:46] <Colourless> what exactly is the problem your seeing?
[18:07:10] <wjp> you might want to already use a real shape instead of fonts to see more
[18:07:21] <watt> good point
[18:08:06] <wjp> you're calling gimp_image_set_cmap on the image properly? (and not accidentally on a layer or something?)
[18:08:08] <Colourless> shape 1 frame 0 should be good enough :-)
[18:09:33] <watt> eww.. flexpack just bombed on me.
[18:11:17] <wjp> hm, I might not have tested that one all that well :-)
[18:12:34] <wjp> http://www.math.leidenuniv.nl/~wpalenst/3.u8o
[18:12:41] <wjp> use that while I fix flexpack :-)
[18:13:13] <wjp> (shape 3 from u8shapes.flx, in case you didn't guess yet :-) )
[18:18:31] <watt> ok... well.. I have screenshot... now I just have to figure out how to share (stupid ISP has me on a NAT)
[18:19:08] <Colourless> dcc!
[18:19:15] <watt> dcc it is!
[18:19:39] <Chetic> dcc!
[18:19:46] * Chetic feels like he missed something
[18:22:02] <Colourless> hmm didn't work
[18:22:22] <watt> email?
[18:22:24] <wjp> dcc send won't work through nat usually
[18:23:01] <wjp> scp to pentagram webspace?
[18:25:34] <wjp> Colourless: did you already update ShapeConv? (the 0x1A stuff)
[18:25:42] <wjp> if not, I will
[18:27:07] <watt> I went with email
[18:27:34] <wjp> hm, I see
[18:27:40] <wjp> R/B swapped?
[18:27:45] <Colourless> no i didn't
[18:28:00] <Colourless> rb swapped = simple fix :-)
[18:28:00] <watt> I need to go kick my ISP for that NAT issue
[18:28:08] <watt> yay!
[18:28:57] <wjp> hm, no
[18:29:07] <watt> no?
[18:29:58] <wjp> frame 0 is supposed to have brown dirt on the lower-left side, green grass top-right
[18:30:15] <wjp> is that really frame 0?
[18:30:31] <wjp> never mind, it does look like it
[18:30:48] <wjp> green is becoming purplish and brown is becoming green
[18:31:37] <Colourless> blue should be green... green should be red... red should be blue...
[18:31:42] <Colourless> an off by 1 bug?
[18:31:57] <wjp> almost sounds like it
[18:32:08] <Colourless> no..
[18:32:11] <Colourless> that's wrong
[18:32:31] <wjp> watt: are you reading u8pal.pal directly?
[18:32:40] <watt> yeah?
[18:32:41] <wjp> if so, you might be forgetting to skip the 4 bytes header
[18:32:54] <Colourless> looks like it
[18:33:00] <Colourless> look at the palette
[18:33:02] <wjp> in your palette the first two colours are back
[18:33:05] <Colourless> 1 blacks 0 and 1
[18:33:08] <wjp> while only the first one should be
[18:33:26] <watt> oh... I'm using the Palette::load method
[18:34:36] <wjp> yeah... U8Game::loadFiles does a seek before calling that
[18:34:39] <Colourless> well, you are getting the 4 byte header
[18:35:15] <wjp> just do a seek(4) before calling load
[18:38:21] <watt> looks a bit closer.
[18:38:37] <wjp> just closer?
[18:39:32] <Colourless> red/blue swapped?
[18:39:38] <watt> not quite sure yet
[18:39:56] <Colourless> is the upper right side of the tile green?
[18:40:31] <watt> It might be a little blue
[18:42:24] <Colourless> want to send another screenshot
[18:42:36] <wjp> can you give the hex triplets of the first couple of palette entries?
[18:43:54] <watt> actually.. I think it does look right..... I send another screen in a moment
[18:44:38] <watt> I need to make layers not visble by default.. except frame
[18:44:39] <watt> 0
[18:44:52] <wjp> good idea
[18:45:05] <wjp> hm, I might want to do that in the u7 one as well
[18:51:55] <wjp> bbl, dinner
[19:06:08] <Colourless> that shot is way out
[19:06:50] <Colourless> looks like green = blue
[19:07:11] <Colourless> which is quite wrong
[19:08:41] <watt> yeah... I sent one more set to show a comparison
[19:08:57] <Colourless> this is what is should sort of look like: http://users.on.net/~triforce/sortofright.png
[19:09:20] <watt> right.. I agree
[19:09:50] <Colourless> what change did you make
[19:10:04] <watt> Are we rgb?
[19:10:08] <Colourless> as it seems like you did something pretty severe to the code
[19:10:23] <Colourless> did you just seek forward 4 bytes or did you do other stuff too?>
[19:10:46] <watt> severe? No, I don't think I did anything too crazy
[19:11:04] <Colourless> are you trying to swap colours?
[19:11:14] <watt> I'm about to try.
[19:11:33] <Colourless> well, you've done something wrong, but i can't tell you without seeing the code
[19:11:38] <watt> oh... I might have switched something.
[19:12:05] <watt> Should I be commiting my progress soon?
[19:12:17] <Colourless> i guess so, but talk to willem
[19:13:12] <watt> yup.. I mucked up the palette a bit...
[19:13:47] <watt> accidently set cmap[i  3 + 2] = pal.palette[i  3 + 1]
[19:14:28] <watt> It looks nice now.
[19:17:49] <wjp> which directory did you put it in?
[19:17:57] <wjp> something behind tools?
[19:18:05] <watt> tools/gimp-plugin
[19:18:49] <wjp> works for me
[19:18:50] <watt> Do we know if any xoff or yoff of shapeframes have ever been negative?
[19:19:18] <wjp> that should be possible
[19:19:54] <watt> hmm.. well, if it's possible, guess I should code at least the load to support it
[19:20:02] <wjp> in paperdoll stuff I can imagine that happening
[19:25:43] <-- Chetic has left IRC (Read error: 104 (Connection reset by peer))
[19:25:55] <watt> the plugin itself is currently name pentshp
[19:26:02] <watt> s/name/named
[19:28:02] <wjp> sounds ok
[19:29:41] --> Chetic has joined #pentagram
[19:30:05] <watt> so... I just decided to open all the gumps in gimp.. this will take a while
[19:52:42] <wjp> I just updated the doxygen version to create docs to 1.4.0
[20:01:10] <Colourless> with the scalers i was thinking of rather than just have a 'scaling factor' like in exult, you instead specify the resolution of the 'game map'. And then have a primary scaler (such as 2xSaI or whatever) and then a secondary scaler (such as bilinear) to fix up aspect and other problems with arbitrary scalings. Now this is easy enough to do write in the ini file, but hell if i can think of how to do it cleanly in the options menu
[20:04:07] <watt> I think its a given that well be completely designing a menu for pentagram.. hopefully sooner rather than later... and there's likely to be chairs thrown over the design issues ;-)
[20:05:41] <watt> well, anyway.. I think I'll go ahead and commit this much of the work..
[20:07:09] <wjp> could also hide most of that from the user and just have have scaler type and aspect correction
[20:07:45] <Colourless> yeah wasn't thinking of allows the users total control
[20:08:14] <Colourless> i guess it can be something we 'solve' later
[20:13:10] <wjp> what would look better? aspect correction before or after the main scaling?
[20:13:17] <Colourless> after
[20:13:57] <Colourless> because for example bilinear filtering first will cause problems for the 'advanced' scalers
[20:14:33] <Colourless> but can try both to see which looks best
[20:14:46] <Colourless> pretty simple to do either way
[20:16:10] <watt> yay for heavily borrowing from exult.. anyway.. initial version is in.. let me know if I did anything too stupid
[20:16:49] <Colourless> hey, nothing wrong with that :-)
[20:17:04] <Colourless> pentagram old had a lot of exult code in it
[20:18:11] <watt> noticed exult cvs still has a pentagram module in fact
[20:19:04] <Colourless> which is years old
[20:29:13] <wjp> it might be a good idea to hardcode the default in-game palette
[20:29:44] <wjp> any idea if the default palette has any duplicate colours?
[20:29:54] <wjp> (different indices with the exact same RGB value)
[20:32:11] <Colourless> and also modified if required to ensure there are no duplicate values
[20:33:13] <wjp> gimp (last time I checked, may be different in 2.0) stored colours by RGB value and not by index
[20:51:13] <wjp> gimp plugin is working nicely for me
[21:00:06] <watt> I was thinking I might try to tie the palette into gimp's palette... look for specifically named palettes if they exist... choose a new one if it doesn't
[21:03:31] <wjp> hadn't tried building from outside the source dir in quite a while, but that still seems to be working smoothly; good :-)
[21:18:59] <watt> hehe awesome.... http://exult.sourceforge.net/forum/read.php?f=1&i=22526&t=22526
[21:24:03] <watt> somehow people never cease to amaze me.
[21:25:17] <wjp> well, just did a long overdue update to build system
[21:25:28] <wjp> config.h is now rebuilt when necessary
[21:28:30] <Colourless> since 'version' has only recently been introduced in, i would again like to suggest that rather than having to update a heap of files per update, that I think it would be a nice idea to have a header that defines version for if config.h isn't used
[21:30:31] <wjp> might be a good idea
[21:31:33] <watt> autonumbered version.h files... shudder
[21:32:00] <Colourless> no! never!
[21:32:01] <watt> We do that at my work... every time some types make.. the version number goes up
[21:32:20] <watt> and creates conflicts.
[21:32:50] <watt> I'm all for a version.h... as long as it gets set manually
[21:33:00] <watt> or intelligently
[21:33:07] <Colourless> the thing is, we already have a file called version.h :-)
[21:33:17] <Colourless> and it would be all done manually
[21:35:45] * Colourless looks at clock...
[21:35:51] <Colourless> um... i should be going :-)
[21:35:54] <Colourless> cya
[21:35:58] <watt> bye
[21:36:15] <-- Colourless has left IRC ("casts improved invisibility")
[21:37:47] <wjp> ok, config.h build process should work now
[21:40:43] <wjp> I should work on this stuff in a fake project, with fewer files to build :-)
[21:40:57] <wjp> constantly rebuilding everything takes way too much time
[21:41:31] * wjp starts a clean build _again_
[21:41:45] <watt> nah.... just use it as an excuse to buy a new computer... ;-)
[21:42:05] <wjp> hm, yes, I do only have to convince myself...
[21:43:04] <watt> Mine's a bit old now. 1Ghz P3, but I sort of don't need more yet
[21:43:49] <wjp> Athlon 3200 goes for Eur240... 1Gb of ram for Eur220, mainboard around Eur100
[21:44:31] <wjp> ah well, I don't really need an upgrade quite yet :-)
[22:11:57] <wjp> time for me to go; back to work tomorrow :-)