[2008-11-05 23:45:29] [INFO] Now logging to . [2008-11-05 23:45:29] [INFO] Channel view for ``#ohrdev'' opened. [2008-11-05 23:45:30] =-= User mode for MikeCaron is now +i [2008-11-05 23:45:34] -->| YOU (MikeCaron) have joined #ohrdev [2008-11-05 23:46:15] hi [2008-11-05 23:46:18] yo [2008-11-05 23:46:30] writing email... [2008-11-05 23:46:38] hmm [2008-11-05 23:47:03] I guess this XML idea might not bloat RPG files by that much [2008-11-05 23:47:18] well, I was going to gzip them anyway [2008-11-05 23:47:18] maybe only a factor of 2 [2008-11-05 23:47:21] but, that's beside the point [2008-11-05 23:47:24] oooo [2008-11-05 23:47:26] zlib [2008-11-05 23:47:37] I forgot to notice [2008-11-05 23:47:46] and, also, zlib was included only because libxml is dependent on it [2008-11-05 23:47:57] but, since I was going to use it anyway... yeah [2008-11-05 23:48:21] !op [2008-11-05 23:48:27] oh well [2008-11-05 23:48:49] but yeah, I had an idea for a new format [2008-11-05 23:48:59] oh wait [2008-11-05 23:49:21] even gzipped, those xml lumps are going to be several times the size of existing lumps [2008-11-05 23:50:05] well, less than an order of magnitude. [2008-11-05 23:50:09] at most. [2008-11-05 23:50:18] but, either way, that's not important now [2008-11-05 23:50:38] why not [2008-11-05 23:50:46] since everyone has an irrational fear of xml, I'm going to fool them with a new format, called RELOAD [2008-11-05 23:50:55] I'm fooled already! [2008-11-05 23:50:58] Really Efficient List Of Arbitrary Data [2008-11-05 23:51:15] which is going to essentially be a binary version of XML [2008-11-05 23:51:25] now I'm really irrationally interested [2008-11-05 23:51:37] what was that HDF Neo mentioned? [2008-11-05 23:51:42] no idea [2008-11-05 23:51:44] I will look it up [2008-11-05 23:52:51] http://www.hdfgroup.org/HDF5/whatishdf5.html [2008-11-05 23:53:03] that page doesn't really say what it is [2008-11-05 23:53:19] but, I suspect that's as close as we'll get without spending large amounts of time looking [2008-11-05 23:53:44] sounds like XML to me >.> [2008-11-05 23:53:57] this page looks more informative: http://www.hdfgroup.org/why_hdf/index.html [2008-11-05 23:55:57] it sounds like XML knocked up MySQL and had a kid [2008-11-05 23:56:29] either way, it sounds like overkill [2008-11-05 23:56:49] anyway, RELOAD [2008-11-05 23:57:03] each element will have two parts [2008-11-05 23:57:15] the "header" will store the name, the size, and the number of children [2008-11-05 23:57:18] and the type [2008-11-05 23:57:33] then, the "body" will contain the children [2008-11-05 23:57:55] which may be other elements, or may be data [2008-11-05 23:58:11] the binary stream would look like this: [2008-11-05 23:58:13] so [2008-11-05 23:58:26] namesize - name - size - children - data [2008-11-05 23:58:36] *numchildren [2008-11-05 23:58:40] if current binary files were translated to this, would they have one element per record? [2008-11-05 23:58:49] yes [2008-11-05 23:58:56] would each field in the record be an element? [2008-11-05 23:59:10] more than likely [2008-11-05 23:59:18] it depends how we format it [2008-11-05 23:59:37] but, the main difference between the current formats and RELOAD is that we're attaching names to each piece of data [2008-11-05 23:59:42] if so, I nominate that the format be renamed Really Inefficient List Of Arbitrary Data [2008-11-06 00:00:12] well, other than the fact that it doesn't make a good acronym, I don't see why you would say that [2008-11-06 00:00:28] there's a few things to consider [2008-11-06 00:00:28] efficient in what way [2008-11-06 00:00:36] I don't think you meant filesize [2008-11-06 00:00:43] the goals of a new generic data file are: [2008-11-06 00:00:59] 1. backwards compatability (with itself, not the current format) [2008-11-06 00:01:14] in other words, I want to eliminate the need for an upgrade sub [2008-11-06 00:01:19] or, reduce it as much as posible [2008-11-06 00:02:02] like I said on the XML data plan on the wiki, if you eliminate default fields, and only store relevant data, it's much more resilient to time [2008-11-06 00:02:06] I propose: being a suitable format for the OHR forever in the future, including ports to low memory handheld devices [2008-11-06 00:02:34] wait what [2008-11-06 00:02:44] eliminate upgrade? well I really like the sound of that [2008-11-06 00:02:52] my example on the wiki was something like this: [2008-11-06 00:03:02] hello! [2008-11-06 00:03:25] unlike the current format, this is quite resilient to file format changes [2008-11-06 00:03:26] but won't you actually would need something far far nastier than upgrade [2008-11-06 00:03:38] depends how you look at it [2008-11-06 00:03:50] I can see the code to parse RELOAD being quite simple [2008-11-06 00:04:15] it's #2 that will make things complicated ;) [2008-11-06 00:04:25] 2. be easy to use, programatically [2008-11-06 00:04:57] for this, I intend to create an XPath like function that will let you select parts of the RELOAD tree [2008-11-06 00:05:19] like: /textboxes/textbox[1]/text [2008-11-06 00:05:28] OT: I want to make textbox text a binary stream [2008-11-06 00:05:45] which would select the first textbox's text [2008-11-06 00:05:50] OT: ? [2008-11-06 00:05:52] we can use ascii codes < 32 for things like changing font and changing font colour, and other codes [2008-11-06 00:05:56] offtopic [2008-11-06 00:06:07] er, that was my reply [2008-11-06 00:06:12] not asking for clarification [2008-11-06 00:06:15] hahah [2008-11-06 00:06:18] and, I tried that once [2008-11-06 00:06:23] ? [2008-11-06 00:06:33] I broke the sprite editor, remember? [2008-11-06 00:06:42] what's XPath [2008-11-06 00:06:46] no I don't remember [2008-11-06 00:06:49] oh [2008-11-06 00:06:51] well, I did [2008-11-06 00:06:55] when was this [2008-11-06 00:06:55] er, the cursor, anyway [2008-11-06 00:06:57] um [2008-11-06 00:07:01] a while ago [2008-11-06 00:07:05] can't remember exactly [2008-11-06 00:07:13] yeah, there are special characters in the font < 32 [2008-11-06 00:07:14] I'm sure the bug's still on bugzilla [2008-11-06 00:07:19] they're easy to avoid [2008-11-06 00:07:21] anyway [2008-11-06 00:07:26] just look at the font to see what's taken [2008-11-06 00:07:28] Xpath is like SQL for XML [2008-11-06 00:08:21] you feed it to the XPath processor, and it returns the node in the tree matching the query [2008-11-06 00:08:28] or, a list of nodes if more than one matches [2008-11-06 00:09:11] ok [2008-11-06 00:09:38] suggestionL [2008-11-06 00:09:44] and you're going to hate this [2008-11-06 00:09:47] possibly [2008-11-06 00:09:52] but I hate bloatly strings [2008-11-06 00:10:03] do explain [2008-11-06 00:10:08] store the names as ids instead of strings [2008-11-06 00:10:19] ? [2008-11-06 00:10:24] you mean, numbers? [2008-11-06 00:10:25] you can have a table corresponding ids to names elsewhere [2008-11-06 00:10:29] yes [2008-11-06 00:10:32] that's entirely possible [2008-11-06 00:10:39] heck, I was considering having a string talbe [2008-11-06 00:10:40] *table [2008-11-06 00:10:44] for the whole file [2008-11-06 00:10:52] ok, good [2008-11-06 00:11:07] which would be totally transparent to the user [2008-11-06 00:12:08] I'm going to quickly finish something unrelated, then write up a spec for the wik [2008-11-06 00:12:10] *wiki [2008-11-06 00:19:03] why not... constatns... instead of strings [2008-11-06 00:19:27] hmm... compile time string lookup [2008-11-06 00:19:46] compile time? [2008-11-06 00:19:57] if only C-like languages didn't have such nonexistant compile time features [2008-11-06 00:19:58] there is no compile time [2008-11-06 00:20:19] I suppose one could use constants [2008-11-06 00:20:21] like, "/textboxes/textbox[1]/text" could be translated to id codesat compiletime [2008-11-06 00:20:27] oh [2008-11-06 00:21:01] well, strictly speaking, xpath is simply a shortcut [2008-11-06 00:21:13] in DOM XML, you can do the same thing like: [2008-11-06 00:22:07] doc->getRootNode()->findChildByName("textboxes")->findChildByName("textbox")->findChildByName("text")->getContent(); [2008-11-06 00:22:21] although, you would likely do it on more than one line [2008-11-06 00:22:25] and, add error checking [2008-11-06 00:22:36] and, use the real function names [2008-11-06 00:27:00] hmm [2008-11-06 00:27:36] oh, and since libXML is a C library, it would look more like [2008-11-06 00:28:21] getContent(findChildByName(findChildByName(findChildByName(getRootNode(doc), "textboxes", "textbox", "text"); [2008-11-06 00:28:35] missing brackets [2008-11-06 00:28:35] *getContent(findChildByName(findChildByName(findChildByName(getRootNode(doc), "textboxes"), "textbox"), "text"); [2008-11-06 00:29:24] oh, and the Really Efficient was supposed to refer to speed [2008-11-06 00:29:30] not filesize [2008-11-06 00:30:25] sounds a heck of a lot slower than the current format [2008-11-06 00:30:36] but much faster than XML [2008-11-06 00:30:53] speed doesn't matter too much [2008-11-06 00:31:05] the only time that it is a problem is when upgrading [2008-11-06 00:31:08] I mostly added it into the acronym since the alternative was VLOAD, for Variable ___ [2008-11-06 00:32:43] so.. RELOAD wouldn't require being compiled to a final binary format, right [2008-11-06 00:33:08] no [2008-11-06 00:33:15] it would be the binary format [2008-11-06 00:33:26] and there would be no XML! [2008-11-06 00:33:35] I'm beginning to like this idea [2008-11-06 00:33:56] oh, the main reason in favour of using strings for tag names is to make it readily transformable to and from XML [2008-11-06 00:34:16] using strings doesn't help [2008-11-06 00:34:30] it does, since RELOAD is generic [2008-11-06 00:34:33] or, supposed to be [2008-11-06 00:34:44] the idea is that you can take any document and binarize it [2008-11-06 00:35:02] so create a string table [2008-11-06 00:35:14] right, that's still using strings [2008-11-06 00:35:26] as opposed to just using numbers [2008-11-06 00:35:29] actually, I suggest that the string table not be stored in thebinary lump [2008-11-06 00:35:42] it could be used only by editedit infact [2008-11-06 00:35:42] where wouldst thou put it? [2008-11-06 00:35:50] in the lump description [2008-11-06 00:35:53] er [2008-11-06 00:36:03] that defeats the purpose of a string table [2008-11-06 00:36:20] there are more stings than just the tag names [2008-11-06 00:36:29] potentially. [2008-11-06 00:36:36] huh [2008-11-06 00:36:40] including data? [2008-11-06 00:37:03] well, I was thinking of doing something like this [2008-11-06 00:37:15] while editing the data, all strings go into the table [2008-11-06 00:37:21] along with a usage could [2008-11-06 00:37:23] *count [2008-11-06 00:37:37] when serializing the data, any that are used more than once are kept [2008-11-06 00:37:41] and, the rest are inlined [2008-11-06 00:40:16] complicated [2008-11-06 00:40:26] not particularly [2008-11-06 00:40:41] it's almost trivial at runtime [2008-11-06 00:41:12] I bit different from what I was imagining [2008-11-06 00:41:26] what was your idea? [2008-11-06 00:41:28] I was just suggesting using numbers instead of strings for field ids [2008-11-06 00:41:45] you're suggesting keeping the strings, but only storign each unique string once [2008-11-06 00:41:51] yes [2008-11-06 00:41:59] since, as I said, *loop to top* [2008-11-06 00:42:01] you're hoping that many enemies will have the same name? [2008-11-06 00:42:21] shops? [2008-11-06 00:42:28] items? [2008-11-06 00:42:30] I'm not hoping anything [2008-11-06 00:42:39] if a string is used once, it's cheaper to inline it [2008-11-06 00:42:54] if it *does* happen to be used more than once, well, there you go [2008-11-06 00:42:59] we already have a system in place [2008-11-06 00:43:15] I think element names, if stored as strings, are the only thing worth trying to store once [2008-11-06 00:44:00] again, I don't see any real reason why not to try and optimize it fully [2008-11-06 00:44:03] incidentally, I never checked my associative array into util.bas [2008-11-06 00:44:14] I mean, we're already traversing the whole tree to look at tag names [2008-11-06 00:44:26] it's simple to also look at the data, if it applies [2008-11-06 00:44:28] not if you replace names with ids >.> [2008-11-06 00:44:35] sigh [2008-11-06 00:44:36] break; [2008-11-06 00:44:41] this is tiresome [2008-11-06 00:44:48] ok [2008-11-06 00:44:49] oh, the main reason in favour of using strings for tag names is to make it readily transformable to and from XML [2008-11-06 00:44:56] we cant [2008-11-06 00:45:13] the textual equivalent could be stored elsewhere [2008-11-06 00:45:21] *we can't pick ids at compile time, since we don't know exactly what we are going to get [2008-11-06 00:45:21] complaint: [2008-11-06 00:45:28] oh wait [2008-11-06 00:45:47] we currently store stuff like each map's general settings in a separate file [2008-11-06 00:45:56] would you keep that or condense them? [2008-11-06 00:46:03] mmm... [2008-11-06 00:46:09] each lump would end up with its own duplicate table [2008-11-06 00:46:18] I think I would condense them [2008-11-06 00:46:23] the map data itself would remain separate [2008-11-06 00:46:30] but, I would clump them together [2008-11-06 00:46:31] on the other hand... map state saving [2008-11-06 00:46:36] er, the map [2008-11-06 00:46:42] well! [2008-11-06 00:46:54] map state saving is easy! [2008-11-06 00:47:03] you create a separate RELOAD file for the states [2008-11-06 00:47:08] and, clone the data into it [2008-11-06 00:47:20] or, whatever [2008-11-06 00:47:33] I guess you wouldn't get to clone it [2008-11-06 00:47:39] since, the data is generated at play time [2008-11-06 00:47:47] but, the idea remains [2008-11-06 00:48:08] the map states are just records in a file [2008-11-06 00:48:58] trivia: [2008-11-06 00:49:11] I suppose [2008-11-06 00:49:23] my first thought was to store the elements as nodes, like the plotscripting format [2008-11-06 00:49:32] yuck [2008-11-06 00:49:36] so, we could optimize data further [2008-11-06 00:49:43] then, I realized that would be needlessly complicated [2008-11-06 00:49:56] (however, it would take care of the string problem neatly!) [2008-11-06 00:51:41] ok, unrelated thing done, time to start writing! [2008-11-06 00:52:58] so [2008-11-06 00:53:16] would you mind me rewriting the textbox format as was planned a while back [2008-11-06 00:53:23] problem is, I'm really [2008-11-06 00:53:35] busy, I have way too many projects [2008-11-06 00:53:55] so it won't happen until after bitmapped fonts [2008-11-06 00:54:06] er, aren't they already bitmapped? [2008-11-06 00:54:14] I mean 16/256 colours [2008-11-06 00:54:32] also, would this rewrite involve condensing the line array to a single chunk of text? [2008-11-06 00:54:52] preferably 256, but that requires a Plan to be worked out [2008-11-06 00:54:57] yes, that's the one [2008-11-06 00:55:07] yay! [2008-11-06 00:55:11] I wouldn't mind [2008-11-06 00:55:26] I think I already wrote a word wrapping function [2008-11-06 00:55:38] yes, I did [2008-11-06 00:55:44] funny, me too [2008-11-06 00:55:52] you know what? I thought you did too [2008-11-06 00:55:55] but, I couldn't find it [2008-11-06 00:56:03] I never committed my changes [2008-11-06 00:56:04] so, I rolled my own [2008-11-06 00:56:05] oh [2008-11-06 00:56:14] it was referenced in a test file [2008-11-06 00:56:16] somewhere [2008-11-06 00:56:18] they're still in my working copy 3-4 months later [2008-11-06 00:56:21] mm [2008-11-06 00:56:23] test file? [2008-11-06 00:56:53] wraptest.bas [2008-11-06 00:57:03] never heard of it [2008-11-06 00:57:17] I haven't been following SVN for several months [2008-11-06 00:57:33] ... that's odd [2008-11-06 00:57:42] wraptest.bas is not in the repository... [2008-11-06 00:57:47] but, I don't recall creating it. [2008-11-06 00:57:48] haha [2008-11-06 00:57:53] umm what [2008-11-06 00:58:01] I modified it to test my own wordwrap function [2008-11-06 00:58:04] but... what. [2008-11-06 00:58:14] ... [2008-11-06 00:59:00] I... yeah. [2008-11-06 00:59:02] I dunno [2008-11-06 00:59:19] since it's not tracked, I can't trace its history... [2008-11-06 00:59:25] maybe, I did create it [2008-11-06 00:59:32] you must have [2008-11-06 00:59:36] but, not in recent history [2008-11-06 00:59:50] you know what also? [2008-11-06 01:00:02] I created the function to match the commented out function call [2008-11-06 01:00:18] and, it had a mystery parameter [2008-11-06 01:00:21] so, I made it a dummy [2008-11-06 01:00:39] ... [2008-11-06 01:01:22] hahahah [2008-11-06 01:01:38] hmm, it was created Feb 07 [2008-11-06 01:01:51] Imma going archive diving [2008-11-06 01:04:08] archive diving... reminds me of yet another thing I haven't done [2008-11-06 01:05:24] I suppose I should avoid NUL's in the string format [2008-11-06 01:05:46] ah [2008-11-06 01:05:51] and, we come to a full circle [2008-11-06 01:05:51] http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/2007-February/004002.html [2008-11-06 01:07:37] anyway [2008-11-06 01:07:44] wow, how do I not remember that [2008-11-06 01:08:04] ah, history [2008-11-06 01:08:12] I suppose I could still salvage that commit [2008-11-06 01:08:30] now that I know what number it was [2008-11-06 01:09:47] Feb 2007... wasn't that in the dead period of the drawnout Ubersetzung development [2008-11-06 01:09:59] I think so [2008-11-06 01:10:53] what happened to that commit [2008-11-06 01:11:01] it was backed out [2008-11-06 01:11:28] hmm [2008-11-06 01:11:39] soon after? [2008-11-06 01:12:14] 12 hours later [2008-11-06 01:12:16] I was thinking that (at least some of) the special codes handling should be in the textbox drawing code rather than printstr [2008-11-06 01:12:31] for example, for things like pauses [2008-11-06 01:12:51] and, interestingly, it was so ubersetzung could be finalized [2008-11-06 01:13:00] oh ho [2008-11-06 01:13:17] (to be fair, the feature freeze was announced AFTER my commit!) [2008-11-06 01:13:29] anyway, I can't remember if it WAS checked back in [2008-11-06 01:13:31] also, I was thinking that as well as \n for hard line breaks, we should have a soft line break for the ends of lines in current textboxes [2008-11-06 01:13:46] was that the feature freeze that lasted a year? [2008-11-06 01:13:54] quite possibly [2008-11-06 01:13:59] no, it was more like 6 months [2008-11-06 01:14:20] ah! http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/2007-February/004038.html [2008-11-06 01:14:28] here's where I talk about word wrapping! [2008-11-06 01:15:25] ah, I did reply to that commit [2008-11-06 01:16:00] "How large is the screen on the phones you're using?" [2008-11-06 01:16:06] maybe I wasn't paying attention [2008-11-06 01:16:47] no wonder it was never checked "back in after Ubersetzung" [2008-11-06 01:17:25] "After Ubersetzung, I'm going to be rewriting large parts of the OHR." [2008-11-06 01:17:26] hahahah [2008-11-06 01:17:41] who was that? [2008-11-06 01:17:47] you [2008-11-06 01:17:52] :P [2008-11-06 01:18:03] ah, I was so young and naieve [2008-11-06 01:19:31] I suppose putting support for things like colour changing codes in printstr is useful [2008-11-06 01:19:43] it could be used elsewhere [2008-11-06 01:19:50] font changing codes too [2008-11-06 01:20:11] and then other codes would be interpreted by the textbox drawing code [2008-11-06 01:20:20] right [2008-11-06 01:20:25] that was the idea I was working with [2008-11-06 01:20:33] so I suppose that your commit could go back in mostly as it was [2008-11-06 01:20:44] but with the codes changed maybe [2008-11-06 01:20:47] maybe [2008-11-06 01:20:54] I'm not really motivated to do that, though [2008-11-06 01:20:58] not right now, anyway [2008-11-06 01:21:01] huh? [2008-11-06 01:21:04] I'll do it [2008-11-06 01:21:15] ok, go nuts [2008-11-06 01:21:22] but... no time soon [2008-11-06 01:21:25] ... [2008-11-06 01:21:39] Second verse, same as the first... [2008-11-06 01:22:59] right now I'm too busy with, firstly, exams, secondly, novel critique for Pepsi, thirdly Eldardeen with Bena, fourthly MIW with deveah, fifthly the new script interpreter, and sixth the C++ wrappers for FB types [2008-11-06 01:24:04] don't wait around for me to do anything [2008-11-06 01:24:17] well, obviously not [2008-11-06 01:24:30] I've really overloaded myself with projects [2008-11-06 01:26:34] but, working on the new interpreter is really fun [2008-11-06 01:27:14] I'm going to need some agreement on how strings and arrays will work soon [2008-11-06 01:27:26] though I've already implemented dynamic typing [2008-11-06 01:27:55] have you implemented any sort of string or array code? [2008-11-06 01:28:06] string yes, haven't started on arrays [2008-11-06 01:28:13] mm [2008-11-06 01:28:45] certain string functions (like copystring) will probably be translated to opcodes, replacing the builtin functions [2008-11-06 01:28:52] http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/RELOAD [2008-11-06 01:29:15] (currently in progress) [2008-11-06 01:30:52] children aren't mentioned yet [2008-11-06 01:31:05] so it's looking to be around 10 times the size of a flat binary [2008-11-06 01:31:11] I'm working on it [2008-11-06 01:31:13] roughly [2008-11-06 01:31:28] well [2008-11-06 01:31:37] assuming no ommitted data fields of course [2008-11-06 01:31:38] let's say we're dealing with a 4-byte int [2008-11-06 01:31:40] and no strings [2008-11-06 01:31:53] in RELOAD, it will be expressed in 13 bytes [2008-11-06 01:31:59] plain, 4 bytes [2008-11-06 01:32:21] assuming the tag name is in the table [2008-11-06 01:32:36] also, children: [2008-11-06 01:32:43] the child count is only relavent if there is children [2008-11-06 01:32:47] so, it's in the data section [2008-11-06 01:33:08] I don't know of a single 4-byte int anywhere though [2008-11-06 01:33:17] well, we don't have any [2008-11-06 01:33:27] but, there are places we should [2008-11-06 01:33:32] so, it's 13 bytes for a 2 byte payload [2008-11-06 01:33:36] no [2008-11-06 01:33:37] 11 [2008-11-06 01:33:43] well, I guess 13 [2008-11-06 01:33:47] opps, that's what I meant [2008-11-06 01:33:54] I could add a SHORT type [2008-11-06 01:33:57] but, why bother [2008-11-06 01:33:58] anyway [2008-11-06 01:34:04] it's 9 bytes of overhead, before the data [2008-11-06 01:34:08] plus any data for children [2008-11-06 01:34:11] right [2008-11-06 01:34:18] number of children might be a short [2008-11-06 01:34:28] no [2008-11-06 01:34:31] it'll be an INT [2008-11-06 01:34:35] though it could be dependent on the type [2008-11-06 01:34:51] let me finish typing up the spec [2008-11-06 01:34:56] fine [2008-11-06 01:35:11] the string table, however, will only be SHORT [2008-11-06 01:35:18] unsigned [2008-11-06 01:35:20] that is [2008-11-06 01:36:57] anyway, the children must be an INT so that we can have more than 32767 of everything, like we're limited to now [2008-11-06 01:37:18] 65535 [2008-11-06 01:37:27] signed shorts [2008-11-06 01:37:39] negatives impossible [2008-11-06 01:37:50] they're still signed [2008-11-06 01:38:06] interesting aside: [2008-11-06 01:38:50]