#pentagram@irc.freenode.net logs for 7 Apr 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:52:10] --> Kirben has joined #pentagram
[00:52:10] --- ChanServ gives channel operator status to Kirben
[03:46:50] --> Dominus has joined #pentagram
[05:19:52] <-- Dominus has left IRC (Read error: 104 (Connection reset by peer))
[07:25:59] --> wjp has joined #pentagram
[07:25:59] --- ChanServ gives channel operator status to wjp
[07:26:17] --- wjp is now known as wjp|work
[12:07:37] --> Colourless has joined #Pentagram
[12:07:37] --- ChanServ gives channel operator status to Colourless
[12:27:21] <wjp|work> Colourless: did you read the object count stuff in the logs?
[12:27:48] <Colourless> yes i did
[12:28:14] <Colourless> i am concerned though that the counts are > 32786
[12:28:18] <wjp|work> yes
[12:28:30] <Colourless> 32768 even
[12:28:34] <wjp|work> :-)
[12:28:45] <wjp|work> we could also delay assigning actual IDs until they're necessary
[12:29:00] <wjp|work> so we do expand all objects into the main object list, but don't assign IDs until usecode needs them for whatever reason
[12:29:23] <wjp|work> (we'll have to think of a way to store the objects in a savegame without saving the IDs, but I think we can manage that ;-) )
[12:29:38] <Colourless> now.. what are the 'theoretical' problem with > 32768 objects
[12:30:15] <Colourless> I know... lets have a disgusting 65536 object array ... almost like the 9128 (not quite the right size) array used by the original :-)
[12:30:54] <wjp|work> I'd prefer not to ;-)
[12:31:14] <Colourless> 0 is a reserved id, 1 is the avatar, 2-255 are the npcs, 256+ should be free
[12:31:22] * wjp|work nods
[12:31:49] * DarkeZzz would accuse Colourless of being sarcastic... except that's the cleanest way he can think of doing it. *grin*
[12:31:52] <Colourless> assigning 64K object id's probably wouldn't be an issue
[12:32:21] <Colourless> seriously, the 'large' array might be the way to do it, by make it resizeable
[12:32:43] <wjp|work> yes, as long as it's somewhat dynamic/resizeable it should be ok
[12:33:28] <Colourless> if i'm not mistaken, the 'issues' of > 32k stuff would have been with processes
[12:33:41] <wjp|work> yes, we only have 32K available processes
[12:33:49] <wjp|work> (because of the way we construct pointers to process stacks)
[12:34:13] <wjp|work> if really necessary we could increase the number, but I don't think we'll need this many :-)
[12:34:41] <Colourless> since usecode pointers are still 32 bits, uint32 UCMachine::objectToPtr(uint16 objID)
[12:34:44] <Colourless> will still work
[12:34:54] <Colourless> also note that it is already uint16 :-)
[12:35:30] <DarkeZzz> I think if we have 32k processes running simultaneously, I think we'll be having more important problems other then hitting the limit of processes. *grin*
[12:36:16] <wjp|work> we'd probably need to start showing "Warning! You are dangerously low on system resources!" dialog boxes somewhere around 30k ;-)
[12:36:41] <wjp|work> ("Oh, and saving your game won't help a bit to fix the problem. Sorry.")
[12:36:55] <DarkeZzz> I think the one-frame-a-minute we'd probably be getting around then would be more then enough of a clue. *grin*
[12:37:21] * DarkeZzz likes the idea of that dialogue box. *grin*
[12:39:09] <Colourless> hehe
[12:39:15] <Colourless> classic
[12:42:52] <wjp|work> I was thinking of adding a GameData class to store all the mainshapes/mainusecode/globs/<any other data file objects> things in
[12:43:13] <Colourless> yes
[12:43:24] <Colourless> no objections there
[13:18:05] <wjp|work> k, committed
[13:32:53] <wjp|work> I've been wondering how to 'properly' handle intrinsics
[13:33:03] <wjp|work> passing arguments will be a bit tricky
[13:33:30] <Colourless> well the number of arg bytes is passed to the opcode
[13:33:46] <Colourless> so, you copy that number of bytes from the stack and put it in a buffer
[13:34:08] <wjp|work> but the intrinsic will have to manually parse that buffer into variables... yuck :-)
[13:34:09] <Colourless> the intrinsic itself then needs to do the work to convert the buffer into values
[13:34:20] <Colourless> not much else we can do
[13:34:23] <wjp|work> yeah
[13:34:35] <Colourless> the process 'could' be automated using a special class/function
[13:34:37] <wjp|work> probably need some functions/macros to get things from the buffer
[13:35:01] <wjp|work> or use a datasource as the buffer to slightly automate things
[13:36:26] <Colourless> it's possible to have va_args based function such as get_args(buffer, &arg0, UC_ARG_UINT16, &arg1, UC_ARG_SINT16, &arg2, UC_ARG_POINTER);
[13:36:28] <Colourless> or some such
[13:36:47] <Colourless> 'or' you could use an array of simple structs with a union
[13:37:09] <Colourless> you then parse the buffer and the array to a function, and the values in the union will be filled
[13:37:57] <Colourless> of course using macros would be fairly simple, obvious and straight forware
[13:38:34] <wjp|work> ARG_UINT16(somevar); ARG_OBJECT(someothervar); ...
[13:39:10] <Colourless> yeah you'd want some sort of counter though so you know what offset to get the arg at
[13:39:18] * wjp|work nods
[13:42:57] <wjp|work> we can just increase the pointer pointing to the buffer
[13:43:40] <Colourless> didn't think of that :-)
[13:43:48] <Colourless> so simple.. so obvious ....
[13:45:26] <wjp|work> then there's the matter of how we actually 'store' the intrinsics
[13:45:41] <wjp|work> I'm not really happy with exult's way (putting them all in the usecode machine class)
[13:46:55] <Colourless> well, the intrinsics in the original game were the actuall C++ functions
[13:46:59] <wjp|work> yes
[13:47:09] <wjp|work> I don't think we should do that ;-)
[13:47:14] <Colourless> of course that isn't an entirely sensible thing to do
[13:47:47] <Colourless> they used a bit of a hack to do it as well, with by using the map file and all
[13:48:16] <Colourless> now, what we could do, is use static member functions in the classes the intrinsic is used for
[13:51:46] <wjp|work> hm, how do pointers to static members work?
[13:51:53] <wjp|work> are they just regular function pointers?
[13:51:58] <Colourless> same as a normal function pointer
[13:52:14] <Colourless> just ClassName::function instead of function
[14:04:56] --- DarkeZzz is now known as DarkeAFK
[14:23:46] * wjp|work nods; I think that would work
[14:24:32] <wjp|work> we also need a huge list of such pointers somewhere, I guess
[14:24:45] <wjp|work> I'd prefer that somewhere not to be in the UCMachine class
[14:24:58] <wjp|work> we could add a special Intrinsics wrapper class for it
[14:24:58] <Colourless> yeah, there are 256 possible functions
[14:25:26] <Colourless> with each game and game version can have different orders
[14:25:29] <Colourless> it looks like all u8 version use the same order
[14:28:43] <wjp|work> ok, that helps :-)
[14:29:05] <Colourless> crusader though, looks like each patch changes thing
[14:29:29] <wjp|work> :/
[14:31:08] <Colourless> thing is, once we have mostly worked out one, it should be 'trivial' to then work out the others
[14:31:09] <Colourless> if you think about it, most usecode functions wont change after the patches are applied, so the intrinsics called will be the same, just with differen numbers
[14:31:32] * wjp|work nods
[14:32:38] <wjp|work> do crusader binaries have debugging symbols like U8?
[14:32:52] <Colourless> nope
[14:33:11] <wjp|work> pity :-)
[14:58:54] <wjp|work> time to go home; bbl
[14:58:58] <-- wjp|work has left IRC ("going home")
[15:23:59] --> wjp has joined #pentagram
[15:23:59] --- ChanServ gives channel operator status to wjp
[15:40:43] <wjp> hm, any thoughts on how to keep the instrinsics tables for the different games/versions somewhat manageable?
[15:42:39] <wjp> just put a bunch of large arrays in some headers?
[15:44:38] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[16:10:32] <Colourless> um, i'm guessing just some large arrays
[16:10:44] <Colourless> i don't see any other way of doing it
[16:11:12] <Colourless> perhaps with a pointer in the ucmachine that will point to the selected array
[16:53:02] * wjp pokes exultbot
[16:53:02] <wjp> monday evening again *sigh*
[16:53:02] <Colourless> Oi! Don't assult exultbot
[16:53:02] <wjp> don't worry, my poke didn't get through to him :-)
[16:53:02] <wjp> (no route to host :-( )
[16:53:02] <Colourless> indeed i can't access the logs
[16:53:02] <wjp> unbelievable... every single monday evening they manage to screw something up
[16:53:02] <wjp> two weeks ago they managed to lose the entire math.leidenuniv.nl domain on half the leidenuniv.nl DNS servers
[16:53:02] <wjp> (and it took them _days_ to fix things)
[16:53:02] <Colourless> so that explains all the dns problems I had some weeks back :-)
[16:53:05] <wjp> the worst part of it is that the group which is responsible for all this is trying to get control of almost all of the uni's network infrastructure
[16:53:13] <wjp> (instead of just the top level)
[16:53:27] <Colourless> back again
[16:53:31] * wjp nods
[16:53:48] <Colourless> [16:53:02] * wjp pokes exultbot
[16:53:49] <Colourless> [16:53:02] <wjp> monday evening again *sigh*
[16:53:49] <Colourless> [16:53:02] <Colourless> Oi! Don't assult exultbot
[16:53:49] <Colourless> [16:53:02] <wjp> don't worry, my poke didn't get through to him :-)
[16:53:49] <Colourless> [16:53:02] <wjp> (no route to host :-( )
[16:53:55] <Colourless> you lied@
[16:54:02] * wjp thinks
[16:54:15] <wjp> ah! because of the delay, my poke arrived _really_ slowly, so it didn't do any damage!
[16:54:37] <wjp> right?
[16:54:38] <Colourless> the data would support that theory
[16:54:46] <exultbot> right! ;-)
[16:56:14] <wjp> hm, down again?
[16:56:33] <Colourless> you noticed that things came back just before your "the worst part of it is that..." comment
[16:57:03] <wjp> yes, that's when I got my CTCP ping reply from exultbot
[16:57:43] <wjp> hm, it's probably just the routes to/from me that are screwed up
[16:58:12] <Colourless> why do you say that?
[16:58:49] <wjp> because I'm still getting timeouts
[16:59:33] <Colourless> but, i could access exultbot, and the logs have a lot of entires for the time [16:53:02]
[16:59:39] <Colourless> s/could/couldn't/
[17:00:56] * Colourless attempting to ping exultbot
[17:00:56] <wjp> ah, that doesn't work anymore now either
[17:00:56] <wjp> it worked when I said "hm, it's probably just the..."
[17:00:56] <wjp> oh, but now I can access the logs again :-)
[17:01:16] <Colourless> [02:31] [exultbot PING reply]: 1min 5secs
[17:01:17] <Colourless> -
[17:01:48] <wjp> a number of 17:00:56 messages this time
[17:02:46] <Colourless> server becoming overloaded? or perhaps just messed up routing tables
[17:03:15] <wjp> since it's monday evening, I would guess somebody's messing with something somewhere
[17:05:04] <Colourless> now the ping is 1 second
[17:05:21] <Colourless> not bad for a signal from australia to the netherlands and back again
[17:05:42] <wjp> I have a 22ms ping to the uni from here (not through IRC)
[17:05:54] <wjp> a CTCP ping to exultbot is about 1/3 second
[17:06:37] <Colourless> Reply from 132.229.229.83: bytes=32 time=517ms TTL=42
[17:07:03] <wjp> around the world in half a second :-)
[17:07:27] <Colourless> Reply from 132.229.229.83: bytes=1024 time=628ms TTL=42
[17:07:32] <wjp> or more :-)
[17:07:45] <Colourless> i increased the packet size with that one
[17:07:51] * wjp nods; I noticed
[17:08:12] <Colourless> problem is modem latency starts to effect things once you start increasing packet size
[17:08:43] <Colourless> Reply from 132.229.229.83: bytes=1 time=506ms TTL=42
[17:08:43] <wjp> 1K for 1/8 second delay sounds about right
[17:09:06] <Colourless> Reply from 132.229.229.83: bytes=2048 time=728ms TTL=42
[17:09:18] <Colourless> about 100 Ms per Kb
[17:09:23] <wjp> the patterns holds :-)
[17:09:35] <Colourless> Reply from 132.229.229.83: bytes=4096 time=928ms TTL=42
[17:09:39] <Colourless> and again :-)
[17:09:50] <wjp> are you sure you didn't cheat on the '28' part? :-)
[17:09:58] <Colourless> Ping statistics for 132.229.229.83:
[17:09:58] <Colourless> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
[17:09:58] <Colourless> Approximate round trip times in milli-seconds:
[17:09:58] <Colourless> Minimum = 919ms, Maximum = 931ms, Average = 926ms
[17:10:40] <Colourless> Ping statistics for 132.229.229.83:
[17:10:41] <Colourless> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
[17:10:41] <Colourless> Approximate round trip times in milli-seconds:
[17:10:41] <Colourless> Minimum = 723ms, Maximum = 728ms, Average = 726ms
[17:10:46] <Colourless> and so on
[17:11:06] <wjp> anyway... shall I put the intrinsic arguments in a 'plain' const uint* buffer?
[17:11:14] <wjp> a datasource probably isn't really necessary, right?
[17:11:21] <Colourless> no, data source not required
[17:11:37] <wjp> time for the pick-a-filename game again :-)
[17:11:49] <Colourless> we can just do that bit shifting to convert to native in the macros
[17:12:26] <wjp> have an intrinsics.h with the basic macro and type stuff; u8intrinsics.h with the actual U8 intrinsic table?
[17:12:41] <Colourless> already have an u8intrinsics.h iirc
[17:12:46] <wjp> UCMachine.h can then include intrinsics.h to avoid pulling in all of the intrinsics tables
[17:12:53] <Colourless> yes
[17:12:56] <wjp> we do? ok, different name then :-)
[17:13:08] <wjp> U8Intrinsics? ;-P
[17:13:16] <Colourless> my yes was in reply to the the include stuff
[17:13:24] * wjp nods
[17:13:41] <wjp> I was pretty sure you wouldn't have said yes to 'U8Intrinsics?' :-)
[17:14:16] <wjp> hm, don't see an u8intrinsics.h
[17:14:26] <Colourless> no we don't have any u8instrincs file. we had an intrinsics.h in old, and I was thinking of ConvertUsecodeU8.h
[17:14:46] <wjp> ah, that's where that list of usecode names was
[17:14:54] <wjp> s/usecode/intrinsic/
[17:16:27] <wjp> yikes, there's a getNext() intrinsic?
[17:16:32] * wjp hopes that one isn't used anywhere
[17:16:53] * wjp greps through disassembly
[17:16:55] <wjp> *phew* :-)
[17:16:59] <Colourless> :-)
[17:17:16] <wjp> (that would've caused some 'minor' difficulties :-) )
[17:17:21] <Colourless> "Item::getNext()", // Unused
[17:17:27] <Colourless> it's unused fool :-)
[17:17:41] <wjp> in my defense: that // unused was outside of the screen :-)
[17:18:01] <Colourless> you were the one to make them unused as well IIRC
[17:18:12] <wjp> really?
[17:18:17] <Colourless> yeah
[17:18:28] <wjp> hm, can't remember doing that
[17:18:32] <Colourless> would have been a long long time ago
[17:18:36] <wjp> ah well, good of me to think of it :-)
[17:19:04] <Colourless> probably the cvs history of intrinsics.h would reveal when
[17:19:17] <Colourless> probably in exults repository thoug
[17:19:18] <Colourless> h
[17:19:52] <wjp> so, we need a function pointer type... (uint32 *Intrinsic)(const char* args, unsigned int argsize) or something?
[17:20:06] <Colourless> const uint8 * args :-)
[17:20:12] <wjp> um, yes
[17:20:31] <Colourless> and you want the this pointer as well... i think
[17:20:43] <Colourless> i can't entirely remember how this pointer with intrinsics was handled
[17:20:54] <Colourless> it 'might' be included in the args
[17:21:16] <wjp> it's included
[17:21:24] <Colourless> intrinsics.h 1.8 10 months colourles * tools/intrinsics.h : Marked all unused intrinsics
[17:21:33] <Colourless> eh, it was me?!?!
[17:21:38] <wjp> (assuming I did my research correctly while writing the comments in the current UCMachine)
[17:21:40] <wjp> heh :-)
[17:22:02] <wjp> good of you to think of it, then ;-)
[17:22:25] <Colourless> i don't know how i did it... it's not like i have grep :-)
[17:24:39] <Colourless> odd i have a file named usedints.txt
[17:26:31] <Colourless> it's from the 11th of may 2002
[17:26:47] <Colourless> the day the option to disassemble the entire usecode was added
[17:27:14] <Colourless> i could swear, i did not generate that file :-)
[17:27:36] * wjp is totally innocent of planting that file! really!
[17:27:42] <wjp> it must've been Darke!
[17:27:56] <Colourless> :-)
[17:28:16] <wjp> gah! Why can't I ever remember that function pointer syntax?!
[17:35:24] <wjp> ah, got it
[17:35:24] <wjp> the uint32 needed to be outside of the ()'s
[17:35:24] <Colourless> yes
[17:35:24] <wjp> the logic of the syntax kind of escapes me
[17:35:24] <Colourless> its return_type (calling_convention * PointerName)(args)
[17:35:24] <Colourless> for typedefs it's
[17:35:24] <wjp> typedef in front and s/PointerName/TypeName/ ?
[17:35:24] <Colourless> the same
[17:35:24] <Colourless> now, casting is the fun one :-)
[17:35:24] <wjp> first typedef, then cast? :-)
[17:35:25] <Colourless> hehe that's cheating
[17:35:25] <Colourless> it's (return_type (calling_convention * )(args)) iirc
[17:35:25] <wjp> makes sense, in a way
[17:35:25] <Colourless> so it you are using the default calling convention with no args it could be (return_type (*)())
[17:36:28] <wjp> I guess that could really confuse people :-)
[17:36:28] <Colourless> nasty cast example:
[17:36:28] <Colourless> grLfbReadRegion = (int (__stdcall *)(long,unsigned long,unsigned long,unsigned long,unsigned long,unsigned long,void *))GetProcAddress_GR(lib_handle, "_grLfbReadRegion@28","grLfbReadRegion");
[17:36:28] * wjp runs off to dinner. ARGH! :-)
[17:36:28] <Colourless> i found longer :-)
[17:36:29] <Colourless> ConvertAndDownloadRle = (void (__stdcall *)(long,unsigned long,long,long,long,long,unsigned long,unsigned char *,long,unsigned long,unsigned long,unsigned long,unsigned long,unsigned long,unsigned long,unsigned short *))GetProcAddress_GR(lib_handle, "_ConvertAndDownloadRle@64","ConvertAndDownloadRle");
[17:36:29] * wjp is gone! I didn't see that!
[17:36:29] <wjp> (anyway, dinner's really ready; bbl :-) )
[17:36:29] <Colourless> :-)
[17:36:29] <Colourless> cya. i'll probably be off now myself
[17:36:29] <wjp> k, night
[17:36:29] <-- Colourless has left IRC ("casts invisibility")
[19:12:27] --> Dark-Star has joined #pentagram
[19:13:06] <-- DarkeAFK has left IRC (sterling.freenode.net irc.freenode.net)
[19:14:35] --> DarkeAFK has joined #pentagram
[21:33:50] <wjp> DarkeAFK: I have running intrinsics! :-)
[21:39:13] --> Dominus has joined #pentagram
[21:45:52] * Dark-Star just noticed there were a few CVS updates to pentagram.... cool!
[21:49:52] <wjp> :-)
[21:51:18] <Dark-Star> pentagram doesn't seem to use exceptions yet... is this only temporary or won't exult use exceptions for error conditions at all?
[21:51:25] <Dark-Star> s/exult/pentagram
[21:51:29] <Dark-Star> obviously :)
[21:53:27] <wjp> no exceptions, I think
[21:53:49] <Dark-Star> why not? I thought exceptions were a Good Thing to do?
[21:54:20] <wjp> pocketpc compiler doesn't support them
[21:55:51] <Dark-Star> hmm this pocket pc compiler seems quite 'beta' to me... no exceptions, no dynamic_cast<>, ... is there no better compiler (gcc) available?
[21:56:14] <wjp> you'll have to ask Colourless
[21:57:05] <Dark-Star> hmmm ok
[22:05:29] <-- Dominus has left IRC ("enough for now")
[22:43:59] <-- wjp has left IRC ("Zzzz...")
[23:03:36] <-- Dark-Star has left IRC ()