#pentagram@irc.freenode.net logs for 26 Jan 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[00:40:33] --> Kirben has joined #pentagram
[00:40:35] --- ChanServ gives channel operator status to Kirben
[00:50:00] <-- wjp has left IRC ("Zzzz...")
[04:50:10] --- DarkeZzz is now known as Darke
[13:10:00] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[13:18:18] --> wjp has joined #pentagram
[13:18:18] --- ChanServ gives channel operator status to wjp
[14:22:57] --> Colourless has joined #Pentagram
[14:23:00] --- ChanServ gives channel operator status to Colourless
[14:46:35] <wjp> I had this weird idea that maybe we should start doing some more coding on pentagram soon :-)
[14:46:49] <Colourless> away with you heretic
[14:47:05] <Colourless> yes agreed
[14:47:18] * wjp notices somebody stole the topic while we weren't looking
[14:47:34] <Colourless> oh no! someone must pay
[14:47:37] <Colourless> i'm guessing exultbot stole it
[14:47:58] --- wjp has changed the topic to: Missing: topic of #pentagram. If you have any information regarding the topic, please inform an op ASAP
[14:48:43] <Colourless> i've lately been sort of really really distracted by GlideXP and partly by Freespace 2 which wasn't entirely agreeing with GlideXP
[14:49:04] * wjp has been distracted by reading Wheel of Time
[14:49:22] <wjp> finished the last (released) part last night, though :-)
[14:49:27] <Colourless> also been screwing around with some other OpenGL related GlideXP stuff too
[14:49:50] <wjp> GlideXP was your driver project, right?
[14:50:15] <Colourless> yes
[14:51:37] <wjp> I guess populating the world/ directory would be kind of useful at this stage
[14:51:53] <wjp> (and maybe shape drawing? *hint* ;-) )
[14:52:06] <Colourless> you need to create a basic object class first
[14:52:12] * wjp nods
[14:53:06] <Colourless> the most basic class IMO would be inherited by almost everything that can be passed as an object to a usecode function
[14:53:23] <Colourless> if we are having gumps as objects in usecode functions, then they would inherit that object too
[14:53:38] <Colourless> a/that object/that class
[14:54:02] <Colourless> now, i was actually thinking about something usecode realted
[14:54:04] <Colourless> related
[14:55:19] * wjp wonders how to name that basic object class
[14:55:32] <wjp> 'Object' is a popular name, but maybe a bit too common
[14:56:17] <Colourless> when you have the 'this' pointer which 'points to the object', it is not entirely necessary to have the special usecode pointers for objects. you 'could' push the item number to the stack before the process is created, and get a pointer to that and pass that as the this pointer
[14:56:54] <Colourless> of course this is all fine and dandy, except i've no idea how to handle returning pointers to objects (assuming that the object usecode pointers were removed)
[14:58:23] <Colourless> now thinking about it, returning pointers to objects might be problematic anyway... what happens if the pointer is pointing to a location on the stack...
[15:01:24] * wjp hmms
[15:02:25] <Colourless> now, i really have no idea if any processes/functions actually return pointers
[15:03:58] <wjp> me neither
[15:04:25] <wjp> having a usecode object pointer isn't that much of a problem, though
[15:04:43] <Colourless> it will be a 32 bit return if it's used
[15:04:50] * wjp nods
[15:09:46] <wjp> comments in UCMachine seem to indicate there are no 32 bit function returns
[15:09:53] <wjp> don't know about process returns
[15:10:59] <Colourless> if there isn't ithen don't think it's a conincidence then that there is the scripts for object searching
[15:11:28] <Colourless> it's possible that they didn't actually support 32 bit returns
[15:12:29] <wjp> process results are 32 bit, though
[15:12:39] <wjp> (often, anyway)
[15:13:01] <wjp> hm, or maybe just the 'intrinsic' processes
[15:14:14] <wjp> not having support for lists of 32 bit values could also be the reason for the object search scripts
[15:16:20] <Colourless> hmmm
[15:16:35] <Colourless> just checking through the entire u8 usecode the pattern is always this
[15:16:36] <Colourless> 66F8: 6D push dword process result
[15:16:36] <Colourless> 66F9: 61 dword to word
[15:17:33] <Colourless> pretty strong evidence that they never did return pointers from processes
[15:19:21] * wjp nods
[15:19:44] <wjp> looks like the compiler automatically added the 0x61
[15:19:58] <Colourless> which is damn sensible of them :-)
[15:20:12] <wjp> saved the script writers a lot of work :-)
[15:25:08] <wjp> brb, lunch
[15:56:34] <wjp> b
[15:57:00] <Colourless> WB
[16:12:27] <wjp> hm... so... Object? PentagramObject? PObject?
[16:12:54] <wjp> it should probably be in the kernel/ dir
[16:19:27] <Colourless> i have no real preference
[16:19:44] <wjp> I named it Object for now
[16:20:05] <wjp> should it cause problems we can always rename it
[16:20:36] <wjp> I guess it only needs a uint16 objid member
[16:21:54] <Colourless> well, it just depends on if we want some extra stuff such as x,y coords and shape frame info in it
[16:22:25] <Colourless> (perhaps z coord too)
[16:22:37] <wjp> hm, I was thinking of putting that one level higher
[16:22:49] <wjp> (if this is to be a common baseclass of gumps and items)
[16:23:07] <Colourless> but gumps will have x,y and shape frame too :-)
[16:23:19] <Colourless> you could even theoretically abstract the mouse pointer from that class too
[16:23:49] <wjp> hm, I guess it should belong in graphics/ if we put this info in it
[16:24:24] <wjp> I don't see much of an advantage to making the mouse pointer one
[16:25:05] <Colourless> neither do i
[16:25:25] <Colourless> unless you wanted to be able to write a usecode class for the mouse, but i don't think that is a good idea, and i see no point to it
[16:28:16] <wjp> hm, I don't think I'll put x/y/shape info in Object
[16:28:35] <wjp> (x,y) coords of a gump are sufficiently different from those of an item
[16:28:43] <wjp> and I don't want to force gumps into using a shape
[16:31:03] <wjp> (x,y,z) coords are signed ints, right?
[16:34:01] <wjp> any ideas on how exactly to store the shape/frame?
[16:36:03] <Colourless> for simplicity make them ALL sint32
[16:36:13] <Colourless> (even x and y)
[16:37:15] <Colourless> the reason is we don't want to lock ourselves into using 16 bit formats if sometime in the future it may be decided that 32 bit is better
[16:37:49] <Colourless> exult is a nice example. expanding the world size is difficult because so much of the engine assumes the coords are always 16 bit
[16:38:27] <wjp> we'll be limited by a max object count of 64K, probably
[16:38:44] <Colourless> yeah
[16:38:52] <Colourless> not much we can really do about that
[16:38:58] <wjp> and that'll be really tricky to get around
[16:40:03] <Colourless> it is generally unwise to have huge numbers of items though
[16:40:18] <Colourless> what we need to consider is how exactly do we store the items in the world
[16:40:51] <wjp> I think Jason Ely described the U8 way on usenet somewhere
[16:41:04] <Colourless> yes and I think we should do something silmiar
[16:41:17] <Colourless> the world was split along the glob borders
[16:41:48] <Colourless> they are 512x512 aren't they?
[16:41:58] <wjp> in U8, yes
[16:42:20] <wjp> 1024x1024 in Crusader
[16:42:42] <wjp> hm, did Crusader use a higher res?
[16:42:48] <Colourless> actually i'm pretty sure it's 512x512 in crusader too
[16:43:12] <Colourless> i multiple all the coords by 2 to get the projection (to the higher res) to work correctly
[16:43:13] <wjp> hm, we snap crusader globs to a 0x400 grid
[16:43:30] <wjp> ah, ok
[16:59:27] <wjp> right, so we want a Map/TheWorld class, with a 2d 'grid' of object lists
[17:00:09] <wjp> additionally containers have lists of their contents
[17:17:34] <Colourless> yes
[17:18:24] <Colourless> going noe
[17:18:27] <Colourless> going now
[17:18:29] <-- Colourless has left IRC ("casts invisibility")