#pentagram@irc.freenode.net logs for 24 Feb 2009 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[01:43:53] <-- pupnik has left IRC (Remote closed the connection)
[01:57:02] --> Fingolfin has joined #pentagram
[01:57:02] --- ChanServ gives channel operator status to Fingolfin
[02:04:57] --> ShadwChsr has joined #Pentagram
[02:05:00] <ShadwChsr> Hey
[02:19:41] <ShadwChsr> Anyone alive?
[03:12:08] --> watt has joined #pentagram
[03:12:08] --- ChanServ gives channel operator status to watt
[03:13:33] <-- watt has left IRC (Client Quit)
[03:50:06] <ShadwChsr> Gah, missed him :P Just the person I needed to talk to, lol
[03:50:43] * ShadwChsr ponders whether lua could be hooked up to the various intrinsic functions
[04:21:30] --> watt has joined #pentagram
[04:21:30] --- ChanServ gives channel operator status to watt
[04:27:07] --> watt__ has joined #pentagram
[04:32:30] <-- watt has left IRC (Read error: 60 (Operation timed out))
[05:13:14] --> watt has joined #pentagram
[05:13:14] --- ChanServ gives channel operator status to watt
[05:16:27] <-- watt has left IRC (Client Quit)
[05:30:22] <-- watt__ has left IRC (Read error: 110 (Connection timed out))
[05:34:42] <-- Fingolfin has left IRC ()
[06:51:03] <-- ShadwChsr has left #Pentagram ()
[09:17:36] <-- Colourless has left IRC ("casts improved invisibility")
[10:23:37] --> pupnik has joined #pentagram
[10:45:48] --> Colourless has joined #Pentagram
[13:10:21] <-- Kirben has left IRC (Read error: 110 (Connection timed out))
[13:46:02] <-- Mrrrr has left IRC (Remote closed the connection)
[13:46:36] --> Mrrrr has joined #pentagram
[16:49:39] <-- Mrrrr has left IRC (Read error: 113 (No route to host))
[16:51:28] --> Mrrrr has joined #pentagram
[17:33:41] <-- Mrrrr has left IRC (Read error: 113 (No route to host))
[18:53:09] --> Mrrrr has joined #pentagram
[19:27:00] --> Mrrrrz0r has joined #pentagram
[19:32:57] <-- Mrrrr has left IRC (Read error: 110 (Connection timed out))
[20:11:42] --> ShadwChsr has joined #Pentagram
[20:11:48] <ShadwChsr> Hey :)
[20:13:05] <wjp> hi
[20:17:07] <ShadwChsr> I've been mucking a bit with the Pentagram engine and usecode ;)
[20:17:39] <ShadwChsr> One thing I couldn't figure out through the code and SVN logs is the memory manager - it wraps a few classes (kernel? world?) but I'm not sure what it's true purpose is.
[20:19:05] <ShadwChsr> I've been isolating the intrinsics into their own classes to reduce coupling in the "main" game code - might try hooking up LUA and using it as an engine and mapping the bytecode to it :D
[20:19:06] <ShadwChsr> hehehe
[20:19:57] <wjp> do you mean kernel/MemoryManager.h/cpp ? That's just a pooled memory allocator hoping to be a bit more efficient at allocating large numbers of the same object than the default new
[20:20:01] * ShadwChsr nods
[20:20:08] <ShadwChsr> Ahhhhhhh
[20:20:35] <ShadwChsr> The one thing that threw me off was that changeMap calls some sort of freeResources method - I wasn't sure if that meant it had a lightweight garbage collector or something.
[20:21:13] <ShadwChsr> The objects allocated with MemoryManager are still guarunteed to be deleted normally, right? ie/ I can rip & replace the memory manager with something entirely different and have no impact other than perf?
[20:23:31] <wjp> (without looking at the code) the freeResources probably just frees completely empty pages
[20:23:49] * ShadwChsr nods
[20:24:15] <wjp> yes, you can just remove it if you want. It has no special features we depend on
[20:24:41] <ShadwChsr> I'm just mucking around in parallel right now - I'm on the west cost of Canada so it's tough syncing up with the rest of you ;)
[20:25:13] <ShadwChsr> Right now I just want to reduce class coupling and experiment with other script engines
[20:25:26] <ShadwChsr> I think I may have found a slight bug in the render sorter as well
[20:25:43] <ShadwChsr> Copy & paste bug
[20:27:09] <wjp> the one on the tracker? yes, thanks for that :-)
[20:27:27] <ShadwChsr> Ahhhh, no problem :) Wasn't sure if it was a bug or not - the rendering code is pretty complex :D
[20:27:56] <ShadwChsr> Is the long term goal to cache the results of the sorter, or just recalc each frame?
[20:28:19] <pupnik> nice ShadwChsr
[20:31:34] <ShadwChsr> I also noticed in usecode there are two intrinsics that allocate strings in a table - I think one of them is for the Avatar's name
[20:32:25] <ShadwChsr> Looked like it was incomplete, and that a new string was allocated on each call. Any idea how it was meant to work? Maybe some sort of special heap-based string variable that was deallocated when the stack unwound?
[20:33:26] <ShadwChsr> I suppose for that one you could preallocate it and return the id to the string table, but I'm not sure what to do about the "number to string" instrinsic (cant remember the function name off the top of my head)
[20:39:09] <wjp> hm, I think usecode frees strings
[20:39:48] <wjp> there is a list/string memory leak, though
[20:40:19] <wjp> but I _think_ that's only when UCProcesses are terminated
[20:40:45] <wjp> (instead of returning normally, so their clean up instructions at the end don't get executed)
[20:40:53] <ShadwChsr> USMachine defines an intrinsic for I_getName, which returns the avatar's name - it seemed strange to have a dependency from UCMachine to MainActor, so I dug deeper
[20:41:20] --> Fingolfin has joined #pentagram
[20:41:20] --- ChanServ gives channel operator status to Fingolfin
[20:41:28] <wjp> the current I_getName is marked "// temp" in u8intrinsics.h
[20:41:29] <ShadwChsr> I think the code is there because UCMachine defines "assignString" as private
[20:41:38] <wjp> quite likely
[20:41:43] <ShadwChsr> Exactly - thats why I wasn't sure if the deallocations were happening or not
[20:41:54] <wjp> yes, but they need to be done by usecode explicitly
[20:41:58] <ShadwChsr> If it was half done or just needed a cleaner public method to move the avatar name stuff out
[20:42:03] <wjp> to fix the memory leak I mentioned we need to keep track of this
[20:42:27] <ShadwChsr> Ahhhhhhh, interesting. Have you found the source of it yet?
[20:42:47] <wjp> processes getting terminated so their clean up instructions at the end are not getting run, as I mentioned above :-)
[20:43:01] <ShadwChsr> Oops, sorry ;)
[20:43:21] <ShadwChsr> Is there any documentation for usecode asside from what's in the code and /docs?
[20:43:30] <ShadwChsr> Or just winging it as everyone learns more during dev?
[20:43:44] <wjp> that's all
[20:43:48] * ShadwChsr nods
[20:43:50] <ShadwChsr> The wikipedia article implies it has threading and other scaryness, hehe ;)
[20:44:09] <wjp> u8's usecode is multithreaded, yes
[20:44:25] <wjp> (cooperatively, so processes manually suspend themselves)
[20:44:44] <ShadwChsr> Ahhhhh - and then the intrinsic calls run in the main thread?
[20:44:57] <ShadwChsr> I had wondered about the lack of synchronization :) Makes sense for a dos based game
[20:45:07] <ShadwChsr> You can't exactly spin up a new thread ;0
[20:45:08] <ShadwChsr> ;)
[20:45:51] <ShadwChsr> Would you guys be interested in the work I'm doing on the intrinsics? I've basically taken all of them and moved them into /Usecode/Intrinsics/
[20:45:51] <wjp> there is synchronization
[20:46:07] <ShadwChsr> ie/ ItemIntrinsics.cpp, PlayerIntrinsics.cpp
[20:46:24] <wjp> (synchronization: see the 'implies' opcode 0x54)
[20:46:28] <ShadwChsr> Thanks
[20:46:30] <ShadwChsr> Only required a few mods, almost all of the dependencies were on public methods
[20:46:33] <wjp> um, why?
[20:46:44] <ShadwChsr> It reduces coupling in the "core" game objects
[20:47:17] <wjp> at the cost of conceptual locality
[20:47:57] <ShadwChsr> True, but it adds a nice layered approach to the design as well - the instrinsics act as a wrapper around the code design
[20:48:22] <ShadwChsr> And things like the Camera don't need to have weird dependencies on other classes that don't make sense from a design perspective.
[20:48:37] <ShadwChsr> Isolates all the usecode "weirdness" from the core app.
[20:49:51] <ShadwChsr> Like you said - it's not localized which is definitely a downside, but it forces cleaner class designs.
[20:50:04] <ShadwChsr> The intrinsics are really just a duplicate wrapper around other functions anyhow
[20:51:41] <wjp> I don't quite see how it forces anything on class design
[20:52:05] <wjp> nor how CameraProcess depends on other classes (unless you mean the includes?)
[21:02:28] <ShadwChsr> Mainly the includes
[21:03:58] <ShadwChsr> Still, the static code lives in CameraProcess and has dependencies on other types
[21:04:20] <ShadwChsr> From a code analysis point of view, it makes the overall framework design more of a mesh than layered - but solely due to the intrinsics
[21:04:34] <ShadwChsr> *shrug* :)
[21:05:19] <ShadwChsr> I guess I was just thinking of having the intrisincs as a Facade around the core engine
[21:06:18] <wjp> they are...
[21:06:40] <ShadwChsr> Not if they're in the same class :)
[21:06:57] <ShadwChsr> At least, not as an architectural pattern
[21:06:59] <wjp> conceptually it's a facade
[21:08:37] <ShadwChsr> I guess it matters more in my experiments since the intrinsics are just one interface into the game
[21:08:42] <ShadwChsr> I want to experiment with others ;)
[21:08:59] <wjp> that kind of changes things :-)
[21:11:05] <ShadwChsr> ;)
[21:36:25] --> Kirben has joined #pentagram
[21:36:25] --- ChanServ gives channel operator status to Kirben
[23:26:02] <-- Fingolfin has left IRC ()