#pentagram@irc.freenode.net logs for 17 Feb 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:47:49] --> DarkeZzz has joined #pentagram
[02:46:39] <-- Dark-Star has left #pentagram ()
[03:31:17] <-- DarkeZzz has left IRC ("Inficio-Infeci-Infectum")
[04:05:46] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[04:09:16] --> Kirben has joined #pentagram
[04:09:16] --- ChanServ gives channel operator status to Kirben
[04:51:41] --> Darke has joined #pentagram
[04:51:41] --- ChanServ gives channel operator status to Darke
[10:38:30] --> wjp has joined #pentagram
[10:38:30] --- ChanServ gives channel operator status to wjp
[10:38:35] <wjp> hi
[10:48:17] --> Cashman has joined #pentagram
[10:57:25] <Darke> Hi.
[11:02:20] --> Dark-Star has joined #pentagram
[11:08:13] --> Colourless has joined #Pentagram
[11:08:14] --- ChanServ gives channel operator status to Colourless
[11:10:22] <Cashman> Hi people - 12:09 am here in NZ and I'm kinda tired.
[11:10:30] <Cashman> hows life
[11:10:59] <Darke> Not too bad. It's only 9pm here and I'm also kinda tired. *grin*
[11:11:21] <wjp> 12:11pm here, and I'm kinda tired too :-)
[11:11:50] <wjp> (work-induced tiredness... *yawn*... *bored* :-) )
[11:12:14] * Darke envies being bored at work. *grin*
[11:12:19] <Cashman> drake? hmmm AUS?
[11:12:33] <Cashman> i cant remember the diff between nz and aus
[11:12:36] <Cashman> are you aus?
[11:12:43] <wjp> s/drake/darke/ :-)
[11:12:47] <wjp> he's .au
[11:13:37] <Cashman> funny that - everyones kinda tired at the moment, must be that news about war after the good start to the year
[11:13:54] <wjp> nah, I think it's a lack of sleep
[11:13:56] <wjp> :-)
[11:14:30] <Colourless> au is the only place to be
[11:14:44] <Cashman> oh - well strange for me but I've actually been keeping up on sleep at the moment (at late), strange but true.
[11:15:22] <Colourless> i come on, i set myself away....
[11:15:25] --- Colourless is now known as Cless|Away
[11:16:02] <wjp> see you later :-)
[11:16:45] * Darke snickers. Bye!
[11:17:04] <Cashman> gonna go now zzzzzzzzzZZZ.
[11:17:08] <-- Cashman has left IRC ()
[11:49:54] --- Cless|Away is now known as Colourless
[11:50:14] <Colourless> i am back
[12:17:03] <wjp> wb
[12:17:45] <Colourless> :-)
[12:18:06] <wjp> I was away for lunch, in case that was 30 minutes late :-)
[12:18:52] <wjp> oh, only 27 minutes, I see :-)
[13:29:35] <Colourless> oh wjp, my plans aren't to actually use the crusader shape format, but a slight modification of it. differences are mostly just to remove unknowns, and a slight change to the line offset table (make all values reletive to the start of the RLE data i think)
[13:29:55] <Colourless> the shapeconverter already supports this format if i'm not mistaken
[13:34:23] <Colourless> of course the line offset changes may 'not' be implemented yet
[13:36:32] <-- Kirben has left IRC ("System Meltdown")
[13:47:19] <-- Colourless has left IRC ("brb")
[13:53:56] --> Colourless has joined #Pentagram
[13:53:57] --- ChanServ gives channel operator status to Colourless
[14:18:59] * Darke blinkblinks. He's got ./fold depending upon ./disasm, and ./suc depending upon ./fold, but ./suc does not depend upon ./disasm.
[14:19:27] <Colourless> broken make i guess
[14:19:34] <Colourless> should be automatic from my experience
[14:19:53] <Colourless> now, don't mind me asking, but what's suc?
[14:19:53] <Darke> Nope. That's my code. And technically how it should work. *grin*
[14:20:04] <Darke> Simple Usecode Compiler. *grin*
[14:20:25] <Colourless> :-)
[14:20:37] <Colourless> does suc suck?
[14:21:19] * Darke is using the same core output for the compiler that the disassembler uses. So he's got this odd intertwining of classes between the decompiler and compiler, which makes sense, but requires one project to be effectively compiled into the other. *grin*
[14:21:30] <Darke> Currently, yes, rather successfully. *grin*
[14:23:28] <Colourless> i've been off and on thinking about writing an unliker, linker and assembler.... but it sort of hasn't happened yet
[14:26:35] <Darke> I've been wanting to write an unlinker/linker too, what's been stopping me really is having to flesh out the FileSys classes rather significantly to do so. *grin* Haven't checked it lately though so I don't know if anyone's committed anything.
[14:27:42] <Colourless> the stupid thing about the unliker is it would really become 'n-times' easier to write if it used your 'cooked' usecode format
[14:28:36] <Colourless> because you need to unresolve all the class numbers, function offsets and process offsets
[14:42:22] * Darke noddles.
[14:46:53] <Colourless> i still think that runtime linking in pentagram is the 'right' way of doing things
[14:47:24] <Darke> Agreed.
[14:47:40] <Colourless> now, with the globals, i was thinking they are what you'd probably call static variables in the classes
[14:48:18] <Colourless> which made me think of something else.... usecode doesn't actually support member variables
[14:48:45] <Colourless> of course it would be 'really' hard to manage to actually implement it
[14:48:54] <Colourless> (member variables that is)
[14:50:42] <Darke> Member variables? I wouldn't have thought it would be particularly hard, storing the data when saving/loading might be an interesting challenge. Would have to store a checksum of the object file when you were saving it, to make sure someone hasn't changed it between the save and load, and thus potentially invalidated it.
[14:52:08] <Colourless> well, the problem is, when do you initialize the member vars. should they be shared by all processes for a particular object? should each process have it's own initialized member vars (which would make them almost pointless). additionally how does overloading work
[14:52:29] <Colourless> s/overloading/inheritance/
[14:54:12] <Colourless> i have no idea how C++ multiple inheritance actually works. All I know it does, and I don't like it much :-)
[15:08:29] <Darke> AFAIK usecode classes aren't 'initialised' at the moment, and the most logical place to initialise them is when you first start the game (on 'new game'), or with dynamic loading, whenever the class is first loaded in the game. Just like the current globals work.
[15:08:56] <Colourless> ah, but i'm not talking about globals :-)
[15:09:07] <Darke> Again, at the moment it's just the case that all classes work as if declared 'static'.
[15:09:34] <Darke> You're talking about data stored locally in a class aren't you?
[15:09:45] <Colourless> yes
[15:12:16] <Darke> That's how I was planning to implement globals then. *grin* Since technically there's only one instance of each 'usecode class' in a game, but multiple instances of objects that reference said class. Local data attached to an object is already handled through quality and such, so you only need to handle data attached to each class, which is going to be as if the data members are declared 'static', since that's how currently things work.
[15:12:46] <Colourless> that, In my most humble of opinions, is cheating :-)
[15:13:21] <Colourless> this is similar to saving games :-)
[15:13:44] <Colourless> i propose that we do not support cheats of any kind in pentagram, this includes no save game support, since it can be abused :-)
[15:13:51] <Darke> Unless you're talking about adding more attributes to each instantiated object in the game. That is more complicated and would require a bit of effort somehow adding a 'variables' structure to each instantiated object.
[15:14:14] <Colourless> exactly, i can't figure out how that would work
[15:14:25] <Colourless> i don't really even want to think about it
[15:14:41] * Darke knows how it would work, however it's a bit of a pain to describe. *Grin*
[15:15:57] <Darke> Actually, if we're going to that length, there's really not much point in compliling the code into binary before hand, you're better off doing a run-time compile like the perl interpreter does. But that's rather... complicated. *Grin*
[15:16:22] <Colourless> i don't think we need it :-)
[15:20:01] <Darke> Anyway, before I sleep (work tommorrow, yay!) I'll explain how to implement dynamically created non-static member variables. *grin*
[15:20:13] <Colourless> uh oh
[15:22:47] <Colourless> funny: i got a letter today from a company i sent a job application to over a year ago saying, that if things go to plan, they want to interview me for a job... it was a most unexpected letter :-)
[15:23:46] <Darke> Basically, the principal is the same as how the usecode allocates free space on the stack for local variables. You have a data field in the header of the class-source description, and in the struct holding the object, you have a 'char *variable_extensions' field. When you detail the data members in the class source, you (again like local variables) note offets and maximum size (which is used for the previous value). Then whenever you wish to
[15:23:47] <Darke> access the special new variables, you make an intrinsic call with the offset pushed onto the stack, and it returns the variable you wish. You do the reverse (with data+offset) intrinsic call (setMemberVar or whatever), and store the data in there.
[15:24:14] * Darke thinks that didn't make much sense though. *Grin*
[15:24:20] * Darke snickers. Cool!
[15:24:49] <Colourless> i understood it well enough, and it is pretty much the only solution i could think of myself
[15:24:57] <Darke> (data field in the header of the class-source file) This details the maximimum size of the potential data. Forgot to add that. *grin*
[15:25:04] <Colourless> you'd really want a 'constructor' overloaded function as well
[15:25:16] <Darke> Cool. And y'know what? That really is the only solution. *grin*
[15:25:21] <Darke> Yep. That would be good.
[15:26:04] * Darke wonders if he's mentioned that he *really* likes the design of u8's usecode language? *grin*
[15:26:11] <Colourless> constructor would probably be 'On Creation'
[15:26:28] * Darke nods.
[15:26:42] <Colourless> so when the object is created in the world (i.e. loaded from disk) the constructor is called, if one exists
[15:27:11] <Darke> Yep.
[15:27:19] <Colourless> in other places, similar things would happen. example gump is created that has some usecode functions, it would call the constructor and so on
[15:27:32] <Darke> It'd work nicely into the current basic function calling scheme too.
[15:28:09] * Darke nods. Setting widgets to default variables, or loading 'environment' variables for them.
[15:29:29] <Colourless> so what's the language called again?
[15:29:53] <Darke> LLC, I think from 'Looks Like C'. *grin*
[15:30:32] <Colourless> so member vars and constructors are part of the LLC-2003 specs :-)
[15:30:35] <Darke> And of course the disassembled binary usecode files are named 'file.lla' for 'Looks Like Assembler'. *grin*
[15:31:14] <Darke> I'm tempted to call the object files 'llo', for... 'Looks Like Objects', but that would be... err... predictable. *grin*
[15:31:29] * Darke cackles!
[15:32:44] <Colourless> i guess we are going to get together every 10 years or so and update the specifications. LLC-1993 was the original specifications for Ulimta 8. LLC-2003 is the Pentagram specifications :-)
[15:33:29] <Colourless> you do know, that the compiler 'should' output valid LLC-1993 binaries :-)
[15:33:32] <Darke> Anyway, must sleep, I need to be up again in a bit over 5 hours. *grin* Evil plotting must wait 'til tommorrow, or emails.
[15:33:34] * Darke snickers.
[15:33:53] <Darke> It... err... actually does at the moment. At least the decompiler does. *grin*
[15:34:40] <Colourless> :-)
[15:34:40] <Darke> That's why I wanted the 'unlinker' actually, so I could diff the object files as an automated means of testing it. *grin*
[15:34:41] <Colourless> cya
[15:34:48] <Darke> Night!
[15:35:25] <Colourless> i think we need ANSI-LLC at somestage too :-)
[16:01:55] <-- wjp has left IRC ("bbl")
[16:04:16] <-- Colourless has left IRC ("casts invisibility")
[16:32:19] --> wjp has joined #pentagram
[16:32:19] --- ChanServ gives channel operator status to wjp
[22:12:49] <-- wjp has left IRC ("Zzzz...")