#pentagram@irc.freenode.net logs for 11 May 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[02:14:27] --> Kirben has joined #pentagram
[02:14:27] --- ChanServ gives channel operator status to Kirben
[04:19:17] --> Colourless has joined #Pentagram
[04:19:17] --- ChanServ gives channel operator status to Colourless
[04:20:39] <Colourless> checking the original game i noticed that dragging (both items and gumps) stops the world from running. This will simplify things quite a bit if we do the same. It means that we don't need to use globals to hack around dragging. Just pause the engine and call a 'doDrag' function or some such
[04:21:13] <Colourless> or better, the doDrag function would pause the engine
[06:11:04] --> sbx has joined #pentagram
[06:25:18] --- DarkeZzz is now known as Darke
[06:25:36] <Darke> That works nicely.
[06:27:09] <Darke> 'Course if we were planning on adding network support to pentagram (which, thankfully, we aren't *grin*) that would cause problems with synchronisation and stuff.
[06:28:37] <Colourless> :-)
[07:20:33] <Colourless> i have come to the conclusion that using a hardware surface for pentagram might be a very bad idea
[07:20:56] <Colourless> the problem is, transparency with a hardware surface is VERY VERY slow :-)
[07:21:09] <Colourless> we are talking on the order of 10 times slower
[07:22:42] <Darke> Umm... hmm... does that explain the significant slowdown wjp and co. were experiencing with hardware surfaces then? (IIRC)
[07:22:54] <Colourless> no it wouldn't.
[07:23:06] <Colourless> not transparency at the start scene.
[07:23:10] <Colourless> s/not/no/
[07:24:27] <Darke> Weird.
[07:38:47] <-- sbx has left IRC ("X-Chat [1.6.4]")
[08:25:47] <Colourless> i should go
[08:25:53] <-- Colourless has left IRC ("l8tr")
[09:40:50] --> Dark-Star has joined #pentagram
[09:42:32] <Dark-Star> hi
[09:42:46] <Darke> Hi.
[09:43:17] <Dark-Star> anyone know why wjp did the last change in SoftRenderSurface.cpp?
[09:43:49] <Dark-Star> because it breaks MSVC7 compilation :-(
[09:44:45] <Darke> Was that the change that was made because it broke compilation on gcc?
[09:44:52] <Dark-Star> oh, no, wait, I think it's not the last change...
[09:45:24] <Darke> Umm... that last change was just to remove debugging output. If that broke it then VC.NET really sucks. *grin*
[09:45:25] <Dark-Star> line #213
[09:45:39] <Dark-Star> uintX: undeclared identifier
[09:47:58] <Dark-Star> this is strange because that ought to be the "MSVC 16bit version", so why does it use uintX and not uint16?
[09:48:55] <Darke> On line 207, change:
[09:48:59] <Darke> template<> void SoftRenderSurface<uint16>::Fill32(uint32 rgb, sint32 sx, sint32 sy, sint32 w, sint32 h)
[09:49:02] <Darke> to:
[09:49:19] <Darke> template<class uintX> void SoftRenderSurface<uint16>::Fill32(uint32 rgb, sint32 sx, sint32 sy, sint32 w, sint32 h)
[09:49:42] <Darke> And see if it works. (Just add the 'class uintX' bit). Currently trying to eat food so the rest of the help will have to wait til later. *grin*
[09:50:29] <Dark-Star> hmmm I'm currently trying another fix, changing all "uintX" to "uint16" in the body (and to uint32 in the next function)...
[09:53:49] <Dark-Star> anyway, if I do what you suggested then I get a couple of other errors: "Fill32 is not a member of SoftRenderSurface<uintX> with uintX = uint{16,32}" and "Fill32: template function already defined"...
[09:56:21] <Dark-Star> for the logs: my fix seems to work (change uintX to uint32 in the MSVC 32 bit version and uintX to uint16 in the MSVC 16bit version)
[10:04:11] <Darke> Fair enough.
[10:36:22] --> wjp has joined #pentagram
[10:36:22] --- ChanServ gives channel operator status to wjp
[11:57:58] --> Cashman has joined #pentagram
[11:58:34] * Cashman catches up on the logs - promises not to be an asshole!
[11:58:53] * Cashman oohs and aahs at the progress - but hasnt downloaded latest cvs
[11:59:54] <Cashman> yeah I remember playing around with the cheat menu in the origional game - at the time there was a lot and I mean a lot of talk about savegame hacks (hex editing) and the cheat menu
[12:00:10] <Cashman> and its full of features as you might know?!
[12:00:48] <wjp> yeah, I played around with it sometime in the past
[12:00:52] <wjp> long time ago, though
[12:01:25] <Darke> I wonder how they found out about it. Didn't you have to hexedit the .exe file or something to turn it on?
[12:01:51] <Cashman> hmm no I think it was ur saved game if I remember or the main u8 save file
[12:02:32] <Cashman> probably find there is a difference with that same file - with the cheates off and then on!
[12:02:35] <wjp> avatar.dat IIRC
[12:03:03] <Cashman> cant have been that hard to find
[12:03:31] <wjp> it'll work differently in pentagram, though
[12:03:38] <Cashman> I mean there have been heaps of game hacks over the years without really any disassembling of the game
[12:03:44] <wjp> most likely a simple switch in one of our menus
[12:03:52] <Cashman> yeah good idea!
[12:04:13] <Cashman> bb just now - hehe switching computers on dialup modem with no current network!
[12:04:16] <Cashman> oh no
[12:04:53] <-- Cashman has left IRC ()
[12:07:28] <Darke> Hmm... searching for 'pagan' related stuff in google picks up some interesting ads. *grin*
[12:13:39] --> Cashman has joined #pentagram
[12:16:37] <Cashman> geez another trip with captain spock
[13:10:36] <Cashman> ggrr having to fix somthing
[13:11:54] <Cashman> recompiling
[13:12:52] <Cashman> hehe yeah got rid of those unnecessary warnings!
[13:26:14] --> Colourless has joined #Pentagram
[13:26:14] --- ChanServ gives channel operator status to Colourless
[13:26:39] <Colourless> hi
[13:26:50] <wjp> hi
[13:27:05] <Darke> Hi*2!
[13:28:16] <Cashman> recompiling eek hopefully it works
[13:28:32] <wjp> I was wondering... is this how trees looked in the original?
[13:28:47] <wjp> right now the trees near the starting point seem to be made up of three shapes
[13:28:59] <wjp> and only one of them actually displays 'tree' if you Look() at it
[13:30:44] <Colourless> yes they were like that
[13:31:03] <wjp> ok, that's good then :-)
[13:31:12] <Colourless> there is a 'stump' shape and a 'tree' shape. The tree shape is added to the top of the stump to create a tree
[13:32:00] <Colourless> if you turn on wireframes in mapdisp you will see the 2 shapes
[13:32:21] <wjp> mapdisp has a wireframe mode?
[13:32:31] <Colourless> yes :-)
[13:32:32] <Darke> Obviously the problem is then, that the stump shapes, don't display 'stump'! *grin*
[13:32:54] * Darke would fix it, except he couldn't care less. *grin*
[13:33:51] <Colourless> wjp: 'tis toggled with 's' oddly enough
[13:36:31] <Darke> Anyone mind if I break people's current .pentagram.cfg's horribly to conform them to the 'new' structure as discussed previously? No? Good... *grin*
[13:36:47] <wjp> which new structure was that again?
[13:37:07] <Colourless> do what you want :-)
[13:37:25] <Darke> Subdivding into /config/game-name sections.
[13:37:34] <wjp> gah, emerge managed to reset EDITOR to nano again
[13:37:47] <Darke> So you have /config/game-name/path and /config/game-name/data etc.
[13:37:57] <Darke> Heh. *grin*
[13:38:55] <Darke> Should the 'default' it looks for be /config/u8 or /config/pagan ?
[13:39:15] <wjp> either is fine
[13:39:34] * Darke will use 'u8' then, since it's currently how we do it. *grin*
[13:39:36] <Colourless> rand() & 2
[13:39:48] <wjp> & 1?
[13:39:56] <Colourless> uh, yeah
[13:39:57] <Darke> That and it's less characters to type.
[13:40:12] <Colourless> if i used % then it would have been fine :-)
[13:40:13] <Darke> wjp: & 2 if you're using Visual Basic. *cough*
[13:40:39] <wjp> why?
[13:40:39] <Darke> Yup. *grin*
[13:44:53] <Darke> Umm... why what?
[13:45:08] <wjp> why is it "& 2" in VB?
[13:46:02] * Darke was thinking % rather then & when he wrote that. VB's rand() function returns numbers between 1 and whatever, rather then 0 and whatever, IIRC.
[13:47:13] <Darke> Though you specify the max in the call, rather then mod it. Random sleepy confusion that's all. *grin*
[13:50:42] <Colourless> hopefully that commit didn't break anything :-)
[13:52:27] * Darke waits for the world to end. *grin*
[13:53:06] * wjp waits for this compilation to end
[13:53:19] <wjp> whee, you broke memset_32 again :-)
[13:53:25] <Darke> wjp: There's a difference? *grin*
[13:54:59] <wjp> and: misc/memset_n.h:171: `memset_32_aligned' undeclared
[14:00:07] <Colourless> ah geez
[14:00:18] <Colourless> line 39 of memset_n.h make it memset_32_aligned
[14:00:23] <Colourless> instead of memset_32_asm
[14:00:23] <wjp> yeah, I figured
[14:00:31] <wjp> just committed, too
[14:00:39] <wjp> also, that one needs an "int u0, u1, u2;"
[14:00:54] <wjp> (don't ask me why, but it does :-) )
[14:01:25] * Colourless doesn't know how gcc's inline asm works and tries not to
[14:02:25] * Cashman adds information to dev c++ for ucmachine as it turns out it cant find process.h without it
[14:02:38] <Cashman> just path info
[14:02:51] <Cashman> compiling......
[14:03:02] <Colourless> you want to know something, i don't get any noticable speed up using the mmx memset_32 vs the non mmx veresion. My guess is that the function is purely memory bandwith limited
[14:03:04] <Darke> Bit weird. That's the only file?
[14:03:31] <wjp> Colourless: sounds plausible
[14:03:46] <wjp> if a memset doesn't fill up memory bandwidth, what will? :-)
[14:03:56] <Colourless> yeah exactly
[14:04:17] <Cashman> do I need to add any new pentagram.cfg information?? to see the new results?
[14:04:25] <wjp> not yet
[14:04:34] <Cashman> is there a change yet in path structure for the .cfg? or is it the same as usual
[14:04:37] <wjp> maybe after Darke commits :-)
[14:04:43] <Cashman> ok thank
[14:04:50] <Darke> Not yet. Give me another 20 minutes or so and I'll hopefully commit it. *grin*
[14:04:52] <Cashman> got ya
[14:05:34] <Cashman> hehe coolz! just wondering aye - all this new talk in the irc logs
[14:13:07] <Cashman> looks good - I still get like 19 fps - yeah ok
[14:13:44] <Colourless> fps is not likely to go up.... only down from here :-)
[14:13:51] <Cashman> whats this about displaying on screen text for what the item is
[14:14:15] <Colourless> unless of course i actually start working on the new opengl renderer which i don't plan too anytime soon
[14:14:28] <Cashman> did wjp put somthing in as a test like whats in the real game?
[14:14:57] <Colourless> what?
[14:15:11] <Cashman> opengl wouldnt take much to start implementing - because of sdl
[14:15:20] <wjp> hm?
[14:15:39] <wjp> Colourless: fps will go up when resolution goes down :-)
[14:15:51] <wjp> not sure what effect scaling will have, though
[14:15:52] <Cashman> when you click around on globs, shapes - it runs usecode and tells you the id - number
[14:15:52] <Colourless> wjp: ah yes forgot about that
[14:16:05] <Cashman> I thought I read back in the logs that when you clicked on e.g. devon it said devon with text?
[14:16:15] <Colourless> Cashman: you obviously don't know enough about opengl then :-)
[14:16:22] --> Kirben2 has joined #pentagram
[14:16:27] <Cashman> some test?
[14:16:28] <wjp> Cashman: Colourless did that
[14:16:51] <Cashman> nah I'll say I know practically nothing about programming using opengl
[14:17:28] <Cashman> you can use opengl through sdl can't you?
[14:17:44] <wjp> yes, but you still need to use opengl
[14:17:50] <Cashman> oh sorry
[14:17:53] <wjp> meaning you have to handle meshes, textures, etc..
[14:18:00] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[14:18:08] <Cashman> I see
[14:18:23] <wjp> sdl mainly handles setting up everything
[14:18:35] <Cashman> but would it take much effort to start a basic framework in opengl for such an engine as pentagram
[14:18:39] <Colourless> yes it does all the icky os specific stuff to setup opengl
[14:18:50] <Cashman> I wouldn't think so - but then again I dont know anything about it
[14:19:06] <Cashman> hmm ok then I understand as far as setting up hehe
[14:19:08] <Colourless> basic framework: easy
[14:19:15] <Colourless> good framework: difficult
[14:19:33] <Cashman> ok
[14:21:24] <wjp> hm, the startup sequence is rather scary at the moment
[14:21:25] <Cashman> just guessing here but "good frame work" even though pentagram appears 2d would you still be implementing techniques used also in 3d engines
[14:21:31] <wjp> Error mounting virtual path "@data": directory not found: /usr/local/share/pentagram
[14:21:34] <wjp> Illegal file access
[14:21:39] <wjp> @data/pentagram.cfg... Failed
[14:21:41] <Cashman> start sequence??
[14:21:45] <wjp> even while nothing is really wrong
[14:21:51] <wjp> s/while/though/
[14:21:57] <Cashman> oh that
[14:22:13] <Cashman> yeah
[14:22:45] <Colourless> Cashman: sort of but not really. The big headache of pentagram is the amount of texture memory required for all the shapes, and how to properly handle allocating it in the most efficent manner
[14:23:20] <Cashman> ok
[14:24:26] <Cashman> so I guess you cant think its easy and wont require much hardware processing in the way of graphics just because its 2d
[14:24:55] <Cashman> so much hype on 3d engines and gaming thease days
[14:25:11] <wjp> 2d is in a way much harder nowadays, because video cards really only focus on 3d
[14:25:19] <Cashman> everythings 3d 3d 3d
[14:26:01] <Cashman> true! wjp
[14:26:14] <Colourless> people have 'forgotton' how to do fast 2d
[14:27:58] <Cashman> hmm with all this 3d hype - with 3d thease days is it icky to do fast rendering, I mean the way the piplelines work etc.
[14:28:27] <Cashman> hehe I'm getting muddled as I keep thinking about the good old cards we use to have which were good for small 2d apps
[14:28:30] <Colourless> not really. you just need to use a little bit of sanity when writing a 3d engine
[14:29:19] <Colourless> the trick is in reducing state changes
[14:29:45] <Cashman> g cards even having there own gpus bla bla bla these days - good to take the straine off the cpu though and help heavly reduce bottlenecks
[14:30:24] <Cashman> I cant wait for evidence of a 64bit motherboard
[14:30:36] <Cashman> with agp 8x
[14:30:43] <Colourless> 64 bit is more hype than anything else
[14:30:59] <wjp> I doubt it'll do much for desktop pcs
[14:31:49] <Cashman> agp 8x wont be used in ages though - oh yeah its just because of all the hype that there new architectural design will significantly reduce bottle nexts in 3d graphics
[14:32:22] <Cashman> also harddisk transfers etc. well everything really! but its hype -
[14:32:52] <wjp> hm, did we ever discuss a way to categorize output?
[14:33:43] <wjp> 'normal' status reports, errors, debugging info (split up into usecode, kernel, world, ...)
[14:34:30] <wjp> ugh, dinner... at 16:30... ah well, bbl
[14:34:31] <Colourless> can't remember
[14:34:43] <Darke> I don't think so.
[14:35:11] <Cashman> ?? what the
[14:35:26] <Cashman> time?
[14:35:38] <Cashman> time
[14:35:38] <Cashman> ? date
[14:35:38] <Cashman> date
[14:36:02] <Cashman> ggrrr how do you talk to exult bot again
[14:36:13] <Cashman> and anyways If I ask for the date will it give my date or some other set date and time
[14:36:17] <Cashman> date ?
[14:37:16] <Darke> The simplest would be something like prepending a 'status' code before each output. Something like X's (EE) for Error, (WW) for Warning, (II) for Imformative log, etc. So you can quickly grep the relevant bits out.
[14:38:25] <-- Kirben2 has left IRC ("System Meltdown")
[14:39:31] <Darke> Interesting. It also has flags like (**) which tells you the information came from the config file, (--) it got the information from the device (mouse/keyboard/screen/whatever), (==) it's using the default setting, and (++) it got the value from the command line. Probably a little detail overkill for us though. *grin*
[14:41:27] <Cashman> how you doing Darke
[14:41:57] <Colourless> Darke: what are you on about?
[14:42:53] <Darke> Colourless: Catagorising output of logging data. Was just describing how one program does it.
[14:43:27] <Darke> Cashman: System operating within designed parameters.
[14:43:59] <Colourless> are you absolutely sure about that? ;-)
[14:45:08] <Darke> Colourless: *ponder* I'm pretty sure. We've already established I'm completely insane, so I figure that was an inbuilt parameter. *nodnod*
[14:45:57] <Colourless> :-)
[14:53:33] <wjp> ?date
[14:53:33] <exultbot> It is now Sun May 11 14:53:33 2003 (GMT).
[14:53:46] <wjp> Cashman: it even tells you which time/date it is giving
[14:54:20] <wjp> Darke: I meant internally, not externally
[14:54:38] <wjp> to provide some way to select which output you want
[14:54:48] <Cashman> nice
[14:54:51] <Darke> Ahh.
[14:58:30] <wjp> I'd like something a little more fine-grained than Exult's #ifdef DEBUG
[14:58:41] <Darke> Agreed.
[15:02:14] <Colourless> yes\
[15:03:07] <-- Colourless has left IRC ("restarting")
[15:04:31] <wjp> roughly 3 ways to do it I guess: using #ifdef (too limited), using some kind of modifier like pout << debugtype(DT_usecode), or simply using an if around the output statements
[15:05:42] <Darke> Actually, I do remember discussing the pout manipulator debug option.
[15:05:53] <Darke> IIRC, it was in an email or something from a while back. Just a sec.
[15:09:07] <Darke> Hmm... sure it was there, or here, or something. I think the conclusion was that was what made the most sense. *grin*
[15:09:39] <Darke> We would probably want to default back to the original 'debugtype' at the next std::endl call, if that is possible.
[15:10:15] <Darke> Maybe just create a pent::endl and remove all the std:: calls from everywhere. *grin*
[15:10:57] --> Colourless has joined #Pentagram
[15:10:57] --- ChanServ gives channel operator status to Colourless
[15:17:03] <Cashman> bye!
[15:17:05] <-- Cashman has left IRC ()
[15:24:18] <wjp> hm, what would be the way to tie this into pout/perr?
[15:24:54] <wjp> overload operator<<(some_special_type) for the setting of the type, I guess
[15:25:16] <wjp> but what about resetting it on std::endl?
[15:25:30] <Colourless> there is a special unique way that std::endl is handled
[15:26:11] <Colourless> endl is like a function or something strange
[15:27:22] <wjp> Darke: does </> really work or is that just shorthand for in the changelog?
[15:27:33] <wjp> yes, endl is rather special
[15:28:44] <wjp> template<typename _CharT, typename _Traits>
[15:28:44] <wjp> basic_ostream<_CharT, _Traits>&
[15:28:44] <wjp> endl(basic_ostream<_CharT, _Traits>& __os)
[15:28:44] <wjp> { return flush(__os.put(__os.widen('\n'))); }
[15:28:55] <wjp> isn't it pretty? :-)
[15:30:28] <Colourless> but there is still more, that is only half of the fun
[15:30:47] * wjp pokes Darke: you need to commit more files
[15:33:10] <Colourless> _Myt& operator<<(_Myt& (__cdecl *_F)(_Myt&))
[15:33:12] <Colourless> {return ((*_F)(*this)); }
[15:33:16] <Colourless> i think,,,
[15:33:29] <Colourless> of course it's platform dependant (mine has __cedcl)
[15:33:58] <Darke> Yes it does work.
[15:34:00] <wjp> __ostream_type&
[15:34:00] <wjp> operator<<(__ostream_type& (*__pf)(__ostream_type&));
[15:34:11] <Darke> And yes, I know. Slowly trying to commit them. *grin*
[15:34:26] * Darke 's net connection is for unknown reasons rather slow tonight.
[15:36:03] <Colourless> we ourselves could use the same sort of hack
[15:37:08] <Darke> Files should be in.
[15:37:54] <Colourless> we would need to overload endl though, as was mentioned above
[15:41:02] <wjp> I don't know if I'm happy with the way Application is going
[15:41:55] <wjp> the current way anything using it would pull in all of pentagram
[15:43:47] <wjp> a (IMHO) better way would be to subclass Application
[15:44:16] <wjp> maybe into GUIApplication/ConsoleApplication
[15:44:33] <wjp> after that subclass it further into individual apps
[15:47:35] <wjp> the current way also requires all uses of Application to go into the constructor, which doesn't really scale properly
[15:47:54] <Colourless> agreed
[15:55:11] <Darke> The problem is that Disasm isn't an Application, it's a Process. I have no intention to dump everthing into Application, which is why my comments the other day were talking about my 'problems' with argument passing and such with Application having to 'know' all the arguments to all the processes it knows about, and how it's not a good thing. *grin*
[15:56:53] <wjp> aren't you trying to fit an application into a process now? :-)
[15:58:22] <wjp> I mean, a disassembler is an application, IMO
[15:58:40] <wjp> therefore, it would make more sense to have a separate disassembler app.
[15:58:57] <wjp> internally that could then use a disassembler process
[15:59:15] <Darke> By that logic, the ingame shape viewer would be an application too.
[16:00:05] <wjp> well, if we want a front-end for a shape viewer, then yes
[16:00:15] <Colourless> darke's idea is that all applications are part of pentagram.exe
[16:00:29] <Colourless> or whatever name of pentagram on the os of your choice :-(
[16:00:35] <Colourless> s/:-(/:-)/
[16:00:51] <wjp> pentagram.exe is clearer than my local version, I gues :-)
[16:01:43] <Colourless> i 'think' though that the direction things are heading isn't entirely correct
[16:02:26] <Colourless> Application itself shouldn't decide what is needed, something else should
[16:02:56] <Darke> Makes sense.
[16:03:44] * Darke eeps at the time. Given I've got to be up again in a little over 4 hours, I think I probably should sleep now. *grin*
[16:03:54] <Darke> Night!
[16:03:55] <Colourless> basically you work out which application interface you want for the tool you want to run, then create the correct application and add the process
[16:04:03] --- Darke is now known as DarkeZzz
[16:04:03] <Colourless> cya
[16:04:31] * DarkeZzz will have to let you guys work this out unfortunately. *pout* RL is such an inconvenience sometimes.
[16:04:57] <wjp> night
[16:05:24] * wjp has to work again tomorrow too.. *sigh* :/
[16:06:02] <wjp> (I haven't had to work in a month... easter, national holiday, and took two days off :-) )
[16:12:43] * wjp grins at e-mail sig: "I know Kungfu, Karate, and 47 other dangerous words."
[16:16:03] <DarkeZzz> Like 'Hard Work'. That'll get more people running screaming then you'd realise!
[16:16:32] <wjp> heh :-)
[16:17:28] <DarkeZzz> Anyway, sleep now. Zzzz...
[16:17:47] <wjp> still have your computer next to your bed? :-)
[16:19:06] <DarkeZzz> Two. Stop distracting me. I need to turn off this monitor. *grin*
[16:19:30] <DarkeZzz> Gone! Really!
[16:19:36] <wjp> suuuuure :-)
[16:19:53] <Colourless> :-)
[16:20:26] <wjp> anyway... output modifiers
[16:20:39] <wjp> I'm kind of wondering how to do that
[16:21:07] <Colourless> my original idea was to use special classes to do it
[16:21:07] <wjp> AFAICT, the operator<< we use comes straight from basic_ostream
[16:21:18] <Colourless> yes it does
[16:21:37] <Colourless> of course my idea never worked quite as i wanted
[16:21:40] <wjp> so it wouldn't be possible to have output just disappear with the current setup
[16:22:23] <wjp> special classes?
[16:22:43] <Colourless> i was using this;
[16:22:49] <Colourless> class debug_level
[16:22:49] <Colourless> {
[16:22:49] <Colourless> public:
[16:22:49] <Colourless> sint32 level;
[16:22:49] <Colourless> debug_level(sint32 l=0) : level(l) { }
[16:22:50] <Colourless> };
[16:22:52] <Colourless> and
[16:22:54] <Colourless> template<class _E, class _Tr> inline
[16:22:56] <Colourless> std::basic_ostream<_E, _Tr>& __cdecl operator<<(
[16:22:58] <Colourless> std::basic_ostream<_E, _Tr>& _O, debug_level &_X)
[16:23:00] <Colourless> {return _O; }
[16:23:05] <Colourless> of course it didn't actually do anything
[16:23:45] * wjp nods; that's how you'd make it set the level
[16:24:13] <wjp> but how would you use the currently set level?
[16:24:30] <Colourless> problem is you need to cast from basic_ostream to one of the console stream to set the level, or somehing
[16:25:50] <Colourless> i wasn't going to have levels being reset by end;
[16:26:02] * wjp nods; not really necessary
[16:26:03] <Colourless> endl
[16:35:55] <Colourless> i should go
[16:35:59] <-- Colourless has left IRC ("casts invisibility")
[19:18:39] <wjp> I hacked in the Item::Ask intrinsic
[19:18:49] <wjp> it displays a list of strings you can choose from on the console
[19:19:00] <wjp> you can answer by pressing 0-9, A-C (hexadecimal)
[19:19:15] <wjp> also, right-clicking makes you use an item
[19:19:22] <wjp> this means you can talk to Devon now :-)
[19:21:08] <wjp> (Valgrind is showing some invalid memory accesses in UCStack, though)
[19:24:07] <wjp> seems like all cases are on opcodes pushing/popping BP+0Ah
[19:27:14] <wjp> I wonder what that is...
[19:27:32] <wjp> I kind of thought the uint32 at BP+06 was the first thing on the stack
[21:06:23] <wjp> hm, looks like we may have to put arguments to a process before the this pointer
[21:06:30] <wjp> annoying
[21:10:31] --> Dominus has joined #pentagram
[21:11:02] <Dominus> hey ho
[21:11:04] <Dominus> busy guys you are :-)
[21:11:23] <wjp> so, did you talk to Devon yet? :-)
[21:11:25] <wjp> hi
[21:12:23] <Dominus> can someone update makefile.mingw? Where do I add DisasmProcess to?
[21:12:37] * Dominus thinks he has some reading up to do on the logs
[21:12:46] <Dominus> for reference for others:
[21:12:49] <Dominus> ?log
[21:12:49] <exultbot> Logs are available at http://www.math.leidenuniv.nl/~wpalenst/pentagramlog.php
[21:13:00] <wjp> which others? :-)
[21:13:17] <Dominus> who might be reading the logs :-)
[21:13:27] <wjp> right :-)
[21:13:45] <Dominus> not that htey forget where to find the logs :-)
[21:13:57] <wjp> you think? :-)
[21:14:28] <wjp> try it now
[21:14:45] <Dominus> I'm pretty sure :-)
[21:15:09] <Dominus> my gosh, there are still files coming in...
[21:15:30] <wjp> only 32 commit mails today :-)
[21:15:44] <wjp> 49 this weekend
[21:15:54] <wjp> oh, you'll have to change your pentagram.cfg again
[21:16:10] <Dominus> I noticed
[21:16:52] <wjp> *sigh*... I have to change something about spawn/UCProcess that I don't want to change
[21:18:35] <Dominus> huh?
[21:18:57] <wjp> I'm putting the parameters of a spawned process in the wrong place
[21:19:19] <wjp> and the current functions don't allow putting them where I think they should go now
[21:19:55] <Dominus> which would mean major rewrite?
[21:19:58] <wjp> nah
[21:20:05] <wjp> not _that_ bad :-)
[21:20:23] <wjp> only a couple of minutes of work I guess
[21:23:18] <wjp> now let's hope this gets rid of the invalid memory accesses
[21:23:37] <wjp> hm, it rather broke stuff
[21:25:17] <Dominus> hm, there is not much distinction between left and right mouse click :-)
[21:25:26] <wjp> no more invalid memory accesses, but it seems to have removed all conversation options from Devon
[21:25:33] <wjp> you're kidding right?
[21:25:42] <Dominus> so what can you do atm, besides clicking on things
[21:25:45] <wjp> try right clicking on Devon
[21:26:12] <Dominus> oh
[21:26:13] <Dominus> ok
[21:26:16] <wjp> you can pick conversation options by pressing the number in from of him
[21:26:28] <wjp> (focus has to be on the graphics window)
[21:26:56] <Dominus> what I meant is click on a random area part and it says tracing left mouse click...
[21:27:44] <wjp> oh, I probably forgot to change left into right :-)
[21:28:16] <Dominus> oh it crashed when I pressed 1
[21:28:31] <wjp> that would be one of those invalid memory accesses :/
[21:28:36] <Dominus> can't reproduce
[21:28:51] <wjp> it reads a little past the stack; sometimes it's bad, sometimes it doesn't hurt
[21:29:51] <Dominus> ok, reading up on the logs
[21:32:30] <Dominus> hey it's bloodwatch
[21:32:39] * Dominus "oohs"
[21:33:50] <wjp> there's a clock around?
[21:34:01] <Dominus> cheat
[21:34:04] <Dominus> 8
[21:34:18] <wjp> heh, cool :-)
[21:34:22] <wjp> a cheat that actually works :-)
[21:34:35] <Dominus> that's what I thought
[21:34:48] <Dominus> big news on pentagram.sf.net
[21:34:53] <Dominus> the time cheat works
[21:34:57] <Dominus> :-)
[21:35:09] <wjp> we have the cheat menu working before you can even move :-)
[21:35:16] <Dominus> can'T be much longer now to be able to kill yourself
[21:35:35] <wjp> ah, the globals aren't zeroed somehow
[21:35:38] <Dark-Star> hmm.. why do I get an undefined reference to "int userchoice" ??
[21:35:40] <wjp> which means all flags are true
[21:35:55] <wjp> (specifically the pyrosFree and hasHeart flags)
[21:36:08] <Dominus> oops
[21:36:23] <Dominus> we don't want that when you are actually unable to move
[21:36:54] <wjp> Dark-Star: while compiling or while linking?
[21:37:15] <Dark-Star> linking
[21:37:25] <wjp> weird; it's defined in Item.cpp
[21:37:30] <Dark-Star> yes, I found it there...
[21:37:42] * Dark-Star is puzzled
[21:38:35] <Dark-Star> aaaah
[21:38:45] <Dark-Star> seems int ant uint32 are treated differently by MSVC7...
[21:38:51] <Dark-Star> and
[21:38:56] <wjp> oh, oops
[21:39:03] <wjp> I named it uint32 somewhere?
[21:39:07] <Dark-Star> yes, in Item.cpp
[21:39:19] <wjp> that should be int
[21:39:24] <Dominus> warning in gcc : world/Item.cpp: In member function `virtual bool
[21:39:27] <Dominus> UserChoiceProcess::run(unsigned int)':
[21:39:27] <Dominus> world/Item.cpp:209: warning: assignment of negative value `-1' to `uint32'
[21:39:27] <Dominus> world/Item.cpp:209: warning: argument of negative value `-1' to `unsigned int'
[21:39:27] <Dominus> world/Item.cpp: In static member function `static uint32 Item::I_ask(const
[21:39:27] <Dominus> uint8*, unsigned int)':
[21:39:28] <Dominus> world/Item.cpp:232: warning: assignment of negative value `-1' to `uint32'
[21:39:30] <Dominus> world/Item.cpp:232: warning: argument of negative value `-1' to `unsigned int'
[21:39:37] <wjp> yes, same cause
[21:40:00] <wjp> committed
[21:43:48] <Dark-Star> oh oh I think I broke something here ...
[21:45:00] * wjp sighs
[21:45:13] <wjp> I hate it when they push 1 byte things as 2 bytes
[21:48:48] <wjp> ok, that got rid of the problems it seems
[21:48:55] * Dark-Star just screwed his whole pentagram build system and has absolutely _no_ idea why...
[21:49:17] <Dark-Star> I hate it when things like that happen, especially when it's late at night...
[21:50:48] <wjp> what's wrong?
[21:51:36] <wjp> conversation with Devon should work a lot better now
[21:51:57] <wjp> AFAICT, the initial conversation is correct. (except that your name is blank, of course)
[21:53:18] <Dark-Star> I suddenly keep getting MSVC linking errors: "xxxx already defined in LIBC.lib", where xxxx is something like _exit, _fclose or _strncpy ...
[21:53:30] <Dominus> damn the answer gets lost on the screen
[21:53:45] <Dark-Star> the only thing I did was adding tools/disasm to the project and hitting "rebuild all"...
[21:53:47] <wjp> ah, but that's why I have a 80 line terminal :-)
[21:53:59] <wjp> you don't need all of tools/disasm
[21:54:01] <Dominus> he he
[21:54:07] <wjp> just tools/disasm/DisasmProcess.cpp
[21:54:28] <wjp> there's also a separate disasm binary there
[21:54:32] <wjp> that might be causing trouble
[21:55:38] <Dominus> got to go again
[21:55:39] <Dark-Star> yep, I saw that too and removed the file containing main(), but still the same problem...
[21:55:48] <Dominus> good night
[21:55:53] <Dominus> and good fight :-)
[21:56:00] <-- Dominus has left IRC ("enough for now")
[21:56:18] <Dark-Star> I think some option changed by obscure magic or something like that. still investigating the thousand property pages for the project...
[21:57:52] <wjp> hm, Darke said he had to get up in 4 hours... and that was about 5-6 hours ago I think
[21:57:56] * wjp pokes DarkeZzz
[22:01:00] * DarkeZzz yawnyips! Yeah. Slept through the alarm. *grin* Will call work soon (once *other* people arrive) to tell them I'll be in there posthaste. *grin*
[22:01:46] <wjp> DarkeZzzz: conversation with Devon is working :-) (/me happy :-) )
[22:05:51] <Dark-Star> funny, the debug build still works... should make it easy to find the cause, though...
[22:06:31] <wjp> hm, I guess I should go to bed or I'll sleep through my alarm tomorrow morning too :-)
[22:06:40] <wjp> good luck on the debugging :-)
[22:06:57] <Dark-Star> thanks... g'night
[22:07:04] <-- wjp has left IRC ("Zzzz...")
[22:07:35] <DarkeZzz> wjp: Yay. Of course I shouldn't be reading through pentagram logs if I have to rush off to work either. *grin*
[22:07:59] * DarkeZzz hops off to do this workstuff. Bye! *grin*
[22:34:08] <Dark-Star> ok, now MSVC has freaked out totally... pentagram compiles but when I start it, it says "usage: disasm <file> [>function number>|-a] ..."
[22:34:20] <Dark-Star> But I know that tools/disasm/Disasm.cpp (where this msg. comes from) is definitely NOT part of the project...
[22:36:24] <DarkeZzz> Yup. Disasm.cpp is part of the tools. Fold.cpp, and ShapeConv.cpp and a few others shouldn't be included either. I think the only files needed out of the tools/ tree are the DisasmProcess.* files from tools/disasm.
[22:37:46] <Dark-Star> #include "Disasm.cpp" <--- who did THAT?!??
[22:37:54] <Dark-Star> that's PURE EVIL ;-)
[22:39:03] <DarkeZzz> Me. *grin* And thanks for the compliment. It was at the time the simplest method of bootstrapping the decompiler off the ground. *grin* Hopefully it too will become a process or something, once we find out exactly how all this Application stuff is going to work.
[22:45:36] <Dark-Star> ok, seems the "xxxx already defined" stuff is coming from linking with SDLmain.lib. I modified pentagram.cpp here locally to "#undef main" so it worked without SDLmain.lib...
[22:45:52] <Dark-Star> Of course that was reverted when I updated with "-C"...
[22:46:12] * Dark-Star still hasn't got a clue on how to do this properly on windows...
[22:47:20] <Dark-Star> what a crazy way to start one's bithday ;-)
[22:47:58] <Dark-Star> *sigh* "unable to load static/u8pal.pal. Exiting" ...
[22:54:30] <Dark-Star> and the debug-build doesn't let me debug anymore :-(
[23:17:35] <Dark-Star> hehe... silently change the config file syntax did you? that's not enough to fool me *evil grin*
[23:17:54] <Dark-Star> well, at least not enough to fool me for more than ... umm.. about 30 minutes? ;-)
[23:24:31] <Dark-Star> ok, almost 2 hours for getting pentagram to work. I think that's gotta tell me to better go to bed...
[23:24:33] <Dark-Star> bye
[23:24:34] <-- Dark-Star has left #pentagram ()
[23:44:21] --> Cashman has joined #pentagram
[23:46:01] <Cashman> eh empty - oh well for a good reason!
[23:46:29] <Cashman> hmm been reading through logs and hear that you can have conversion now with devon!
[23:46:32] <Cashman> good work wjp
[23:46:50] <Cashman> will have to update cvs tonite
[23:47:01] <Cashman> my copy
[23:47:16] <Cashman> eh and darke added new structure to pentagram.cfg?!
[23:47:16] <Cashman> hmm
[23:47:19] <-- Cashman has left IRC (Client Quit)