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

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:55:28] <watt> I'm shifting a few small things so some more objects can be used by the plugin... notably, the PalTransforms enum needs to be moved out of PaletteManager in order to link Palette into the plugin.
[00:56:00] <watt> I think simply putting it into a new file would be best.
[00:56:14] <wjp> a new file for a single enum?
[00:57:25] <wjp> could also move it to Palette.h
[00:58:36] <wjp> (assuming that that's where you need it)
[01:01:50] <watt> Yes, but I'm assuming the declaration of struct Palette in PaletteManager may be to avoid a similiar situation... although PaletteManager.cpp does directly use the Palette
[01:03:03] <watt> well, I try moving it to Palette firsty
[01:03:14] <watt> s/y$//
[01:08:05] <wjp> there we go; first commit of 2005 :-)
[01:08:29] <watt> that's cheating... I'm still in 04 :-)
[01:12:13] <wjp> time to go; night
[01:12:16] <watt> night
[01:19:27] <sbx> cya
[01:21:18] <watt> ugh... a change to IDataSource means a rather hefty recompile... sigh... good change though,
[01:27:42] <watt> okay.. looks like moving to the enum to Palette was safe
[01:28:34] <sbx> Heh, somehow I got the balancing animation when walking.
[01:28:44] <sbx> but this is an older copy of Pentagram I have
[01:32:07] <watt> oh.. nasty seg fault when approaching the gaurd
[01:33:25] <watt> balancing animation happens if you are about to walk off a ledge and the next step is more than 8 down.. might not be perfect still.
[01:33:38] <sbx> it was in the middle of a field
[01:34:05] <watt> right.. guess it didn't "see" the object on step in front of you.
[01:38:58] <watt> hmmm.. error at IDataSource.h:399
[01:51:35] <watt> hmmm.. count = buf - buf_ptr + size.... have a good feeling that should be count = buf_ptr - buf + size
[01:52:53] <watt> hmmm.. or not... one moment
[01:54:45] <watt> size - (buf_ptr - buf) = size - buf_ptr + buf..... erk. Is this an off by one?
[01:55:52] <watt> yeah, think so.
[01:57:31] <watt> crap.. but attempting to read greater than the actual size shouldn't cause a seg fault.
[02:05:27] <-- Fl00der has left IRC (":P")
[02:05:31] <-- sbx has left IRC ("BBL")
[02:46:51] <watt> although reading negative numbers is alway bad.... well.. ok
[03:09:15] <watt> hmm.. yeah... size of the datasource is set to zero for some reason .. that woulddo it
[03:09:47] <watt> anywho... it's time to party... bye
[05:06:23] <-- Chetic has left IRC (Read error: 110 (Connection timed out))
[06:37:59] --> Chetic has joined #pentagram
[06:46:02] --> sbx has joined #pentagram
[07:39:53] <-- Darke has left IRC ("Inficio-Infeci-Infectum")
[07:40:17] --> Darke has joined #pentagram
[09:24:57] <-- sbx has left IRC ("good night/morning & happy new year")
[10:52:00] --> Colourless has joined #Pentagram
[10:52:00] --- ChanServ gives channel operator status to Colourless
[11:41:42] <wjp> watt: no, that isn't an off by one; just see what happens when buf == buf_ptr
[12:32:35] --> servus has joined #pentagram
[12:33:03] <-- servus has left #pentagram ("Leaving")
[12:33:29] --> servus has joined #pentagram
[12:33:55] <-- Kirben has left IRC ("System Meltdown")
[13:33:48] --> edbgon has joined #pentagram
[15:18:33] --> Fingolfin has joined #pentagram
[15:18:33] --- ChanServ gives channel operator status to Fingolfin
[15:22:32] <wjp> hi Max
[15:28:23] <wjp> well, I've got a working ZipFile wrapper class around unzip.c
[15:28:44] <Colourless> sool
[15:28:46] <Colourless> *cool
[15:29:55] <wjp> http://www.math.leidenuniv.nl/~wpalenst/archive
[15:30:33] <wjp> ArchiveFile is the abstract base class
[15:31:14] <Colourless> that is almost the sort of thing i had started to make
[15:31:29] <Colourless> my idea
[15:31:37] <Colourless> though had a 'FileBased' object
[15:31:57] <Colourless> that would be an abstract class which be inherited by Zip and Directory classes
[15:32:06] <Colourless> so don't have to replicate the 'indexing' stuff
[15:33:08] <wjp> yes, I was thinking of doing that once there were multiple types with 'named' objects
[15:33:16] <wjp> (U8SaveFile doesn't count since that's too special purpose)
[15:33:59] <wjp> but indeed if we want a Directory'File' class, it would be useful
[15:34:52] <wjp> anyway, my idea was to create a Flex (or something) class that could have multiple ArchiveFile classes as input sources
[15:35:02] <Colourless> for the override/patch stuff (for flexes) my basic idea was just use a vector and allow multiple sources to be opened and added to the vector.
[15:35:32] <wjp> yes :-)
[15:35:51] <Colourless> a 'directory' based 'file' would be useful for dev stuff
[15:35:59] <wjp> true
[15:36:42] <wjp> currently all filenames are case sensitive... maybe that wasn't the best idea
[15:37:16] <wjp> luckily changing that should be a simple matter of changing some strings to istrings
[15:39:05] <Fingolfin> hi ryan, willem, all
[15:40:30] <Colourless> hi max
[15:40:35] <Colourless> Happy New Year :-)
[15:40:39] <Colourless> now that we are all in it :-)
[15:44:25] <Fingolfin> thankss, and a happy new year to you all as well :-)
[16:08:23] <-- Chetic has left IRC ("gaydows gaydate")
[16:58:44] --> Darke2 has joined #pentagram
[17:07:16] <-- Darke has left IRC (Read error: 60 (Operation timed out))
[18:08:35] <watt> wjp: I did track down the source of the problem. The datasource had a size of zero for some reason and buf_ptr > buf
[18:09:56] <watt> ended up being if (buf_ptr + 16 > buf + 0) { count = buf - buf_ptr + 0; }
[18:11:55] <wjp> how is that wrong?
[18:12:21] <wjp> oh, buf_ptr > buf ?
[18:12:49] <watt> count became negative
[18:16:28] <watt> perhaps the assert in IBufferDataSource's constructor should be assert( data != 0 && len > 0); ?
[18:18:26] <wjp> why was buf_ptr > buf ?
[18:19:05] <wjp> well, I guess that could happen
[18:19:08] <watt> the datasource had been read from by other methods.
[18:19:28] <wjp> that count = ... breaks whenever buf_ptr is past the end of the buffer
[18:19:34] <wjp> so I guess it would be best to add a check at that point
[18:20:11] <wjp> if (buf_ptr > buf + size) return 0;
[18:20:19] <wjp> or >=, actually
[18:20:21] <watt> It was going to read a string of "Halt, stranger!" with 16 bytes.. I'm guessing a previous byte was read to get the string length
[18:21:05] <wjp> I'm confused; why would it read that from an empty IBufferDataSource?
[18:21:33] <watt> I think the best was is to ensure that the size never equals 0 in the first place.. it was incorrect elsewhere
[18:21:51] <wjp> but having size > 0 doesn't help in this case at all
[18:21:58] <watt> the datasource must not have actually been empty
[18:22:10] <wjp> count would become negative whenever buf_ptr is past buf + size, whether size is 0 or not
[18:25:40] <watt> true
[18:26:48] <watt> although I'd argue that is an error that should be asserted.
[18:30:01] <wjp> hm, I wouldn't assert on that
[18:30:17] <wjp> it just indicates that the caller should've paid better attention to the buffer size
[18:31:13] <wjp> *sigh*; sorry for the double commit... I wasn't thinking
[18:31:28] <wjp> updated the file APIs in http://www.math.leidenuniv.nl/~wpalenst/archive/
[18:31:36] <watt> I dunno.. it seems like failing silently to me.
[18:32:07] <watt> I'd at least try to raise a stink to let the caller know they messed up
[18:32:10] <wjp> it returns '0 bytes read', which is how fread() indicates a similar error condition as well
[18:33:37] <watt> ok. That's a good argument.
[18:35:01] <wjp> [file API] there's now a NamedArchiveFile which handles index->name conversion
[18:35:16] <wjp> ZipFile, DirFile (new as well) and U8SaveFile are subclasses of that one
[18:35:23] <watt> cool
[18:35:59] <watt> erk. what was the APIs link again?
[18:36:15] * wjp points 4 minutes up :-)
[18:36:25] <wjp> http://www.math.leidenuniv.nl/~wpalenst/archive/
[18:37:07] <watt> for all of pentagram?
[18:37:24] <wjp> what do you mean?
[18:38:05] <watt> the doxygen API docs.
[18:38:29] <wjp> oh, those: http://www.math.leidenuniv.nl/~wpalenst/pentagram/doxygen/
[18:38:51] <watt> perhaps those should be in the links for the site?
[18:39:07] <wjp> it isn't?
[18:39:17] <wjp> should be in the devel section
[18:39:49] <watt> oh
[18:40:08] <watt> must have forgotten
[18:41:15] <-- edbgon has left IRC ("Lost terminal")
[18:41:23] <wjp> next would be the replacement Flex class that uses these *File classes
[18:44:27] <wjp> or maybe Archive, or something like that
[18:44:44] <wjp> anyway, dinner first
[18:48:15] <watt> committed a few changes that will be used in the plugin
[18:58:03] <watt> hmm.. oh... I didn't actually have to detect the shapeformat myself... shrug
[18:58:44] <Colourless> no :-)
[18:58:51] <Colourless> pentagram can automatically do that itself
[18:59:52] <watt> well, I guess it didn't hurt anything to detect it in the plugin.
[19:13:53] --> Chetic has joined #pentagram
[19:22:51] <wjp> back
[19:23:31] <wjp> hm, I wonder if it's feasible to make Archive a drop-in replacement for the current Flex class
[19:25:30] <wjp> need to consider Flex' subclasses as well... ShapeFlex, FontShapeFlex, ...
[19:25:51] <Colourless> it should be possible
[19:26:24] <wjp> another question is if it's desirable, of course :-)
[19:26:24] <Colourless> and IMO, it is desirable
[19:26:27] <wjp> ;-)
[19:26:43] <Colourless> if not, why not
[19:27:07] <Colourless> because don't we want the functionailty...
[19:27:30] <wjp> well, I was mainly thinking about constructors in this case
[19:29:16] <wjp> right now they're created 'from' a IDataSource
[19:29:33] <wjp> could of course keep it that way, autodetecting the type
[19:34:50] <-- Fingolfin has left IRC ("42")
[19:48:41] <Colourless> cya
[19:48:43] <-- Colourless has left IRC ("casts improved invisibility")
[20:16:57] <wjp> the Flex, ShapeFlex, FontShapeFlex hierarchy doesn't feel quite 'right'
[20:17:12] <wjp> thinking about a cleaner way of handling different types of objects
[20:17:17] <wjp> maybe something templated
[20:17:46] <wjp> oh, and GumpShapeFlex, UsecodeFlex, MusicFlex
[20:21:39] <wjp> basically the use of those classes is to store objects of a specific type (raw data, Shape, ShapeFont, XMidiFile) that are loaded from an ArchiveFile, along with some additional data
[20:22:39] <wjp> so it sounds like there should be a base class Archive (probably abstract) that handles the interface with multiple ArchiveFile sources
[20:24:03] <wjp> the classes that are then actually used by pentagram would be subclasses of Archive that would only need to implement constructing an object (Shape, ShapeFont, ...) from loaded data and storing any additional data
[20:24:59] <wjp> I think Archive should be purely indexed for now (so no named entries)
[20:35:52] <watt> hmm.. this is tough... trying to figure out how to map the ShapeFrame to a pixel range on a layer in gimp....
[20:36:24] <wjp> did you look at exult's plugin?
[20:36:43] <wjp> had to solve the same problem there
[20:38:10] <watt> yes.. it's using gimp_pixel_rgn_set_rect, but since I'm using ShapeFrames I don't think that will work
[20:38:33] <wjp> hm, what do you mean exactly?
[20:40:06] <watt> exult's plugin has the shape and frame structure defined in the plugin and loads the frames in a fairly gimp friendly fashion. I'm attempting to reuse Shape, ShapeFrame, and Palette.
[20:41:04] <watt> and I've tried using gimp_pixel_rgn_set_rect with the ShapeFrame
[20:41:18] <watt> 's rle_data
[20:41:28] <watt> but that didn't work out too well.
[20:42:05] <wjp> you'll have to at least decompress the data
[20:43:00] <watt> yeah, so I'm thinking that I take the code from SoftRenderSurface.inl and try to adapt it.
[20:43:12] <wjp> you might actually be able to directly include that file
[20:43:25] <wjp> with the right #define's set before including it
[20:43:49] <wjp> it's fairly 'flexible' :-)
[20:44:45] <watt> I.. don't think so.. I think it assumes it's part of a RenderSurface... although I could attempt to make a GimpRenderSurface...
[20:45:05] <wjp> hm, it should use very little of the rendersurface
[20:45:56] <wjp> it probably just needs pixels, width, height and pitch
[20:46:18] <wjp> and it doesn't assume those are member variables
[20:48:05] <wjp> a lot of the more complex stuff (transforms) can be removed by setting the right #defines
[20:49:05] <wjp> clipping won't be necessary either
[20:49:50] <watt> might work... although then I think I'd be dealing with a RGB picture instead of a Indexed one at that point....
[20:50:44] <wjp> hm, true
[20:51:17] <wjp> probably can be worked around by making pal the identity map
[20:51:58] <wjp> you'd make uintX an uint8 and pal an array of uint8's with pal[i] = i
[20:52:09] --> sbx has joined #pentagram
[20:52:46] <watt> hmm.. yeah... that'd be neat
[20:57:38] <sbx> hi
[20:59:42] <watt> hiya
[21:14:40] <wjp> http://www.math.leidenuniv.nl/~wpalenst/archive/Archive.h
[21:27:55] <watt> I like it.. Is the new FlexFile.h intended to completely replace Flex.h? That seems like a fairly large change if so.
[21:32:13] <wjp> no, a subclass of Archive will replace the current Flex
[21:32:35] <wjp> one that will look suspiciously like the current Flex :-)
[21:34:07] <watt> oh.. right.. didn't notice that ArchiveFile is not a subclass Archive.
[21:34:44] <wjp> renaming the classes is still possible :-)
[21:53:13] <wjp> well, I wonder how badly it'll crash and burn when I actually plug this code in :-)
[22:18:43] <wjp> ok, Flex replacement 'done'...: http://www.math.leidenuniv.nl/~wpalenst/archive/RawArchive.h
[22:19:00] <wjp> (note that all those classes there are already fully implemented even though I only uploaded the .h files)
[22:19:02] --> sbx|afk has joined #pentagram
[22:40:27] <-- sbx has left IRC (Read error: 113 (No route to host))
[22:43:52] <wjp> well, fixed.dat is loaded with the new flex api and working
[22:44:08] <wjp> I wonder if replacing it with a .zip will work :-)
[22:45:23] <wjp> yay, it did :-)
[22:48:12] <wjp> less luck with the 'DirFile' class :/
[22:49:54] <sbx|afk> zipped saves?
[22:49:59] --- sbx|afk is now known as sbx
[22:50:32] <wjp> 'soon' :-)
[22:50:53] <wjp> can't write zips yet
[22:51:12] <sbx> how big would a savegame + screenshot be unzipped? 800k?
[22:52:29] <wjp> 700-800Kb, yeah
[22:52:45] <wjp> should be around 200Kb zipped
[22:53:51] <sbx> that's great, yeah 800k is too big
[22:54:01] <sbx> i wonder if Crusader saves are smaller
[22:54:36] <sbx> but maybe their screenshots would be bigger?
[22:54:57] <wjp> they'd definitely be smaller, yes
[22:55:19] <wjp> I really haven't given too much thought to the savegame UI (and therefore screenshot size) yet
[23:01:08] <wjp> ok, DirFile fixed
[23:24:53] <wjp> hm, it's kind of tempting to get rid of MainShapeFlex and GumpShapeFlex altogether