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

Archive Today Yesterday Tomorrow
Pentagram homepage

[00:27:08] <-- Dark-Star has left IRC ("ZZZzzz...")
[00:36:20] --> Kirben has joined #pentagram
[00:36:20] --- ChanServ gives channel operator status to Kirben
[08:31:12] --> wjp has joined #pentagram
[08:31:13] --- ChanServ gives channel operator status to wjp
[08:32:41] <DarkeZzz> Hi.
[08:32:47] <wjp> hi
[08:33:01] * DarkeZzz is talking in his sleep again. Don't mind him. *grin*
[08:35:56] <wjp> about opcode 0x6C...
[08:36:19] <wjp> if we need to keep a string/list's pid anyway, we don't need to copy things on 0x6C
[08:36:46] <wjp> just change the associated pid, and don't allow freeing strings/lists belonging to other processes
[08:38:17] <DarkeZzz> Makes sense.
[08:41:40] --> Dark-Star has joined #pentagram
[08:45:48] <wjp> this could of course be abused by the caller, but it looks like the usecode compiler from the original always frees things when calling processes that use 0x6C
[08:48:17] <DarkeZzz> Yup.
[10:29:31] <DarkeZzz> Just for reference, you probably *shouldn't* be able to fish when unconscious... *grin*
[10:30:30] <wjp> details details :-)
[10:30:48] <wjp> but that's just because we don't run FIRST at the beginning
[10:30:59] <wjp> that should set avatarInStasis
[10:31:13] * DarkeZzz grins.
[10:32:38] <wjp> the camera movement and linear interpolation together cause a rather weird effect :-)
[10:33:37] <wjp> I wonder if it would look better if we keep the camera on an object's lerped coords instead of on its real coords
[10:34:12] <wjp> hm, actually, we should probably disable lerping teleports
[10:37:13] * DarkeZzz , for some reason, sees 'lerping' as the movement of a semi-spherical jelly-mould as it bounce-rolls after you as it chases you...
[10:37:21] --- DarkeZzz is now known as Darke
[10:38:43] <Darke> Kind of like a *slurp* *leap!* *sploosh-rollbouncerollbounceroll..* *slurp* *leap!*... etc.
[10:39:21] <wjp> :-)
[10:39:26] <wjp> it is a rather weird 'word', yes :-)
[10:42:29] * Darke wants a pet jelly-mould now. It'd look way ky00t!
[10:42:54] * Darke decides he's spent too much time coding and not enough time existing in reality.
[10:43:10] <wjp> no you haven't; now get back to coding ;-)
[10:47:27] * Darke has spent a large chunk of the day coding, surprisingly enough. He managed to scavange quite a bit of time hiding in the back room where he has his 'lunch' and coded away. *grin*
[10:47:38] <wjp> hm, speaking of lunch...
[10:47:41] <wjp> bbl :-)
[11:16:00] <Darke> Hmm... at some point in time we probably want to support the creation of two 'pentagram' executables, with one build command. One containing nothing but the core "play a game of u8" stuff, and the other containing the other bits, like the compiler/editor/disassembler/etc built in. Just to make snapshots and such easier so people who just want to play the game use 'pentagram', and people who want to edit things and have trace gumps and stuff p
[11:16:00] <Darke> oping up when they're debugging scripts and stuff using 'pentagram-dbg' or something.
[11:17:04] <Darke> I 'shouldn't' in theory, be too difficult, since I'm going to have to half-support doing that sort of thing anyway by splitting up Application and creating a seperate regression tester for the compiler, along with the stand alone tools, etc.
[11:17:09] <Darke> s/I/It/
[11:28:27] --> CashZzz has joined #pentagram
[11:33:57] --- CashZzz is now known as Cashman
[11:44:32] <Darke> Hmm... the Application::application singleton stuff is going to be... interesting to handle with multiple derived classes, all derived from an Application base class.
[11:46:27] <Darke> Presuming we've got a class heirachy looking something like Pentagram : GraphicsApp : ConsoleApp : Application, the constructor of each is going to have to test if Application::application is *not* NULL and only if it is, assign it's *this to it. Or else you'll end up with a pointer to the base Application class only on it.
[11:57:17] <wjp> since the bottom constructor is run first, that'll give the wrong result, won't it?
[12:00:11] <Cashman> OBJ/Compile.o(.text+0x930):Compile.cpp: undefined reference to `llcFlexLexer::llcFlexLexer(std::istream*, std::ostream*)'
[12:00:16] <Cashman> eh this problem
[12:00:25] <Cashman> Darkes work I guess??
[12:00:43] <wjp> did you run flex?
[12:00:54] <Cashman> eh?
[12:00:56] * Darke blinks. Eh? That works fine on my sytem. Did you run flex and include llcLexer.cpp it produces?
[12:01:03] <Cashman> wait
[12:01:21] <Darke> wjp: *pointpoint* See? This is why I was wondering if we should include the .cpp file. *grin*
[12:01:43] <wjp> it's bad policy to include generated files in CVS :-)
[12:01:49] <Cashman> yeah I havnt been around for a couple of days so this is the first time I've seen Darkes new work
[12:01:56] <wjp> (no matter if it would be convenient occasionally for some people)
[12:02:07] <Darke> wjp: I know. *grin*
[12:02:38] <Darke> Cashman: Do you have all the relevant binutils installed with mingw? There should be an executable called 'flex' that comes with it.
[12:03:53] <Darke> You need to set in your makefile (or however that ide of your's does it), to execute the following command in your /pentagram/ root dir.
[12:04:09] <Darke> flex -+ -otools/compile/llcLexer.cpp tools/compile/llcLexer.l
[12:04:26] <Darke> That'll generate the .cpp file that contains the symbol you're missing above. *grin*
[12:04:45] <Cashman> ok I need to download what ever flex is contained in?!
[12:05:01] <Darke> Check if it wasn't already installed with your installation of mingw first.
[12:05:29] <Darke> It'll likely be a stand alone 'flex' package if it isn't already installed.
[12:06:07] <Cashman> hmm /bin no files called flex
[12:06:47] <Cashman> ok
[12:16:26] <Darke> wjp: Hmm... do you know any way of getting the autoconf/makefile system to 'easily' not include compile/link object files into an executable by an --enable command? It might be worth just disabling things like the compiler in a default build, at least for the next few months, since they aren't going to be *usable* for ages.
[12:18:34] <Cashman> http://gnuwin32.sourceforge.net/packages.html notes that he needs to remember this website
[12:20:37] * Cashman hmm
[12:45:42] <Cashman> hehe eeew
[12:46:34] <Cashman> umm flex was spewing when I added it to the dev projects makefile, while for the meantime so I tried a commandline compile
[12:47:02] <Cashman> commandline compile I used the same example as you pointed out above darke except I changed paths
[12:47:08] <Cashman> it appeared to be ok
[12:47:09] <Cashman> but
[12:47:19] <Cashman> when compiling the cpp file eeew
[12:47:22] --> Colourless has joined #Pentagram
[12:47:22] --- ChanServ gives channel operator status to Colourless
[12:47:46] <Colourless> hello
[12:48:19] <Darke> Cashman: You'll get a few thousand warnings but it should produce a .o file though.
[12:48:23] <Darke> Hi Colourless!
[12:50:06] <wjp> hi
[12:50:43] <wjp> Colourless: I think lerping should be disabled when teleporting objects/npcs around
[12:50:54] <wjp> not exactly sure how to do that, though
[12:50:57] <Colourless> yes, lerping does have 'issues' in places :-)
[12:51:16] <wjp> maybe automatically disable it when the distance is too great?
[12:51:35] <Colourless> perhaps, or it could be set with a EXT flag for a single frame, if teleport is used
[12:51:38] <wjp> (although 'too great' might depend on the situation)
[12:52:30] <wjp> I wonder if it's possible to automatically determine from each usecode-called move if it's supposed to be a teleport or not
[12:52:46] <wjp> for instance, the rolling head in the execution scene isn't supposed to teleport
[12:53:04] <wjp> other move() calls are supposed to teleport
[12:53:45] <Colourless> some of the const stuff is preventing things from working that would otherwise be ok. Such as doing const char * const * const argv. Doing that prevents you from incrementing argv, which can be useful (for example to remove first arg you can do argv++; argc--)
[12:55:08] <Cashman> hmm could me version of that flex prog be screwy! I think so
[12:55:43] <Darke> Colourless: Feel free to remove them. I've just never found any use to do something 'fancy' like that to them before. *grin*
[12:55:49] <Darke> Cashman: What version?
[12:55:53] <Cashman> colourless what version of the flex prog should I be using!!
[12:56:12] <Colourless> Cashman: hell if i know
[12:56:17] <Cashman> 2.5
[12:56:26] <Cashman> that sounds kinda old
[12:56:27] <Cashman> ?
[12:56:40] <Darke> My flex --version tells me I'm using 2.5.4.
[12:56:54] <Cashman> is there a commandline switch or readme?!
[12:57:00] <Colourless> all i know is this, darkes code simply wont compile
[12:57:00] <Cashman> I'm using a ported ver anyways
[12:57:11] <Darke> So it should work. What *errors* are you getting?
[12:57:29] <Colourless> i've got 2.5.4
[12:57:56] <wjp> why does 2.5 sound "kinda old"? :-)
[12:58:10] <Darke> In which case it 'should' just work. I'm not doing anything remotely fancy with flex. *grin* Obviously it isn't though, what are the errors?
[12:58:18] <Cashman> sorry
[12:58:20] <Colourless> \Pentagram\tools\compile\Compile.cpp(77) : error C2027: use of undefined type 'CompileUnit'
[12:58:33] <Colourless> commenting out the
[12:58:34] <Colourless> class CompileUnit;
[12:58:41] <Cashman> about the ver souding old I dont know what I'm talking about
[12:58:46] <Cashman> I'll get some errors
[12:58:52] <Colourless> gets rid of that error and 'n' others of the same thing
[12:59:50] <Colourless> but then i get
[12:59:51] <Colourless> \Pentagram\tools\compile\Compile.cpp(71) : error C2061: syntax error : identifier 'CompileUnit'
[13:00:24] <Cashman> I got the right ver
[13:00:36] * Cashman looks at some stuf
[13:00:40] <Darke> That's weird. I wouldn't have thought a forward declaration of a class *after* the class is already declared would screw up a compiler. Even removing that class line produces no errors here. *puzzlement*
[13:01:00] <Colourless> that is just the thing, i've never seen it cause problem either
[13:01:24] * Darke pokes around his files to see if he's doing anything silly.
[13:03:33] <Cashman> you included the right flexlexer.h file right? just called it somthing else
[13:03:49] * Darke knows why he had it there, was important 'til he rearranged things.
[13:04:22] <Cashman> thats ok file right! my port only comes with .exe
[13:04:25] <Colourless> compileprocess compiles fine
[13:04:40] <Colourless> Compile though causes much pain
[13:04:40] <Cashman> same here
[13:04:58] <Cashman> mine compiles!
[13:05:11] <Colourless> grrr
[13:05:19] <Colourless> Darke, you broke the GOLDEN rule!
[13:05:25] <Colourless> #include "pent_include.h"
[13:05:27] <Colourless> MUST be first!
[13:05:54] <Colourless> now it compiles fine
[13:06:19] <Colourless> now to setup flex to work with msvc :-)
[13:06:53] * Darke ahhs! He's still not sure *why* it only broke under msvc though. *grin*
[13:07:06] <Cashman> c:\nick\pentagram\pentagram\tools\compile\llclexer.cpp: In member function
[13:07:06] <Cashman> `virtual int llcFlexLexer::yylex()':
[13:07:06] <Cashman> c:\nick\pentagram\pentagram\tools\compile\llclexer.cpp:951: `cin' undeclared
[13:07:06] <Cashman> (first use this function)
[13:07:06] <Cashman> c:\nick\pentagram\pentagram\tools\compile\llclexer.cpp:951: (Each undeclared
[13:07:07] <Cashman> identifier is reported only once for each function it appears in.)
[13:07:09] <Cashman> c:\nick\pentagram\pentagram\tools\compile\llclexer.cpp:954: `cout' undeclared
[13:07:11] <Cashman> (first use this function)
[13:07:13] <Cashman> c:\nick\pentagram\pentagram\tools\compile\llclexer.cpp:1051: `cerr' undeclared
[13:07:15] <Cashman> (first use this function)
[13:07:15] <Colourless> i don't know why it broke either
[13:07:17] <Cashman> c:\nick\pentagram\pentagram\tools\compile\llclexer.cpp:1683: cannot convert `
[13:07:19] <Cashman> std::istream*' to `istream*' in assignment
[13:07:21] <Cashman> c:\nick\pentagram\pentagram\tools\compile\llclexer.cpp: At global scope:
[13:07:23] <Cashman> c:\nick\pentagram\pentagram\tools\compile\llclexer.cpp:1791: type specifier
[13:07:25] <Cashman> omitted for parameter `ostream'
[13:07:27] <Cashman> c:\nick\pentagram\pentagram\tools\compile\llclexer.cpp:1791: parse error before
[13:07:29] <Cashman> `*' token
[13:07:31] <Cashman> c:\nick\pentagram\pentagram\tools\compile\llclexer.cpp:1794: ISO C++ forbids
[13:07:33] <Cashman> declaration of `yyout' with no type
[13:07:35] <Cashman> oooops
[13:07:37] <Cashman> sorry!!!
[13:07:39] <Colourless> that is enough Cashman
[13:07:39] * Cashman hides
[13:07:41] <Cashman> stuff
[13:07:43] <Cashman> I made a batchfile to compile the .l
[13:08:30] <Cashman> hmm whats flex++, same thing?
[13:08:48] <Darke> Shouldn't make any difference.
[13:08:56] <Darke> Yes, it's essentially the same thing.
[13:08:59] <Cashman> heh same size
[13:09:01] <Cashman> yeah
[13:09:35] <Darke> Open up llcLexer.cpp and check there's a 'using namespace std;' around line 28.
[13:10:58] <Cashman> hmm no
[13:11:52] <Darke> Is there one anywhere in the entire file? (Just search for 'namespace')
[13:12:29] <Cashman> no!
[13:13:35] <Colourless> what is the exact command line that should be used?
[13:13:40] <Darke> What does `flex --version` tell you?
[13:14:04] <Cashman> flex -+ -opath for cpp path to .l file
[13:14:09] <Cashman> I did that from batch
[13:14:25] <Cashman> I have the correct ver 2.5.4
[13:14:58] <Darke> Try using flex++, instead of flex, though it shouldn't make any difference.
[13:15:05] <Cashman> no diff
[13:15:41] <Cashman> I got heaps of undeclared
[13:16:26] <Cashman> I renamed that .h to flexlexer.h
[13:16:46] <Cashman> I needed that right but yeah heaps of undeclared
[13:16:49] <Darke> Erm... what .h?
[13:18:55] <Darke> Cashman: Open the `llcLexer.l` file and insert `using namespace std;` just below the `#include "llcTokens.h"` line, should be about line 3 or so.
[13:18:59] <Cashman> I have that flexlexer.h included correctly now but somehow I get more undeclared's
[13:19:49] <Cashman> wait
[13:19:50] <Darke> Then rerun your llcLexer.cpp generation script
[13:22:25] <Cashman> llclexer.cpp:1683: cannot convert `
[13:22:25] <Cashman> std::istream*' to `istream*' in assignment
[13:22:38] <Cashman> yy_current_buffer->yy_input_file = yyin;
[13:22:42] <Cashman> is that line for example!!
[13:22:55] <Colourless> the stream stuff will be an issue
[13:24:24] <Darke> Umm... huh? *blink* I think I need to get this windows flex to see what precicely is wrong with it. That's not even a sane error message.
[13:24:45] <Cashman> oh wait
[13:25:26] * Cashman opens a log in notepad
[13:26:15] <Cashman> llclexer.cpp:1791: parse error before
[13:26:16] <Cashman> `*' token
[13:26:28] <Cashman> yyFlexLexer::yyFlexLexer( istream* arg_yyin, ostream* arg_yyout )
[13:27:18] <Cashman> llclexer.cpp:1818: parse error before
[13:27:18] <Cashman> `}' token
[13:28:01] <Cashman> and a syntax error ooo
[13:28:12] <Cashman> llclexer.cpp:2176: syntax error
[13:28:12] <Cashman> before `{' token
[13:28:32] <Colourless> adding #include "pent_include.h"
[13:28:42] <Colourless> to the top of lex.llc.cc made it compile
[13:30:14] <Colourless> problem though, wont link
[13:31:26] <Darke> The additional problem is I can't see any reason to *include* pent_include.h. I use nothing out of that, not even a uint32! *grin*
[13:32:05] <Colourless> it's the rules
[13:32:22] <wjp> it includes whatever platform-specific stuff you might need
[13:32:40] <Darke> In any event, the .cpp file that the windows flex is producing is incorrect, bordering on brane damaged. It doesn't even work on my machine.
[13:32:59] <Darke> Fair enough.
[13:33:18] <Cashman> hehe thanks! I dont need to burn anymore brain cells thanks
[13:33:24] <Cashman> I thought it was just me
[13:33:35] <Colourless> E:\Program Files\Microsoft Visual Studio .NET\Vc7\include\useoldio.h(29): warning C4995: '_OLD_IOSTREAMS_ARE_DEPRECATED': name was marked as #pragma deprecated
[13:34:48] <Colourless> the problem i'm getting is this. lex.llc.cc wants to use the 'old' iostreams while pentagram uses the standard ones
[13:34:54] <Darke> That windows compile of flex hasn't been updated to understand putting 'using namespace std;' in the file.
[13:35:18] * Colourless checks the gnuwin32 download page
[13:35:25] <Cashman> well mines 2.5.4
[13:35:27] <Darke> Just a sec, I'll put my llcLexer.cpp into my webspace, try that and we'll see if it works.
[13:35:43] * Cashman awaits results
[13:36:28] <Darke> Erf. I don't have that anymore, changed isps.
[13:36:41] <Cashman> ooo
[13:36:43] <Colourless> 2.5.4a
[13:36:47] <Cashman> yeah
[13:37:57] <Cashman> technically I should end up with the same sorta .cpp?! as under linux
[13:38:35] <Cashman> ? hmm
[13:39:15] <Cashman> u trying somthing Darke...
[13:39:52] --- wjp is now known as wjp|work
[13:40:00] --- Cashman is now known as CashZzz
[13:40:03] <CashZzz> have to go nite nite soon
[13:40:10] <Darke> No you won't. Mine's been patched to fix some problems as I've just noticed...
[13:40:39] <CashZzz> ? explain
[13:41:03] <Darke> Comment from the flex build script: # Some Redhat patches to fix various problems
[13:41:21] <CashZzz> so the win32 port ain't updated! right!!
[13:41:25] <Darke> Followed by four patches to fix problems w/ gcc3 and gcc3.1.
[13:42:03] * CashZzz loads Roach to look for dev c++ gcc/mingw32 updates
[13:43:22] <CashZzz> hmm nothing important
[13:43:52] <CashZzz> hehe I wonder when well get updated ports
[13:44:43] * CashZzz wonders what exactally Darkes new stuff is for since hes been away for a while
[13:45:39] <-- CashZzz has left #pentagram ()
[13:45:43] --> CashZzz has joined #pentagram
[13:46:01] <Darke> Considering flex2.5.4 was released Sept 1996, and until recently no-one's bothered to maintain it (there's a small group of people updating it to 'newer' versions, but they haven't released one yet...), I'm surprised the mingw port wasn't manually patched.
[13:46:47] <CashZzz> hmm yeah - hehe dev c++ distrubtion of mingw32 doesnt even have the flex tool
[13:48:13] <CashZzz> can this problem be fixed Darke?! this aint my sorta thing but should the win32/linux convert compile compatible code!
[13:49:14] <CashZzz> so could you upload to a secret cvs location ur copy or would it not work with me
[13:49:19] <CashZzz> ?? confused...
[13:49:26] <CashZzz> hehe have to sleep in a second
[13:49:57] * Darke is messing around at the moment trying to fix it.
[13:55:47] * CashZzz updates dev with critical updates ooo
[13:56:46] <CashZzz> Darke good luck with fixing the probs!! I have to go
[13:56:47] <CashZzz> l8erzs
[13:57:16] <-- CashZzz has left IRC ()
[14:38:32] <Kirben> What files shold the compiler need ?
[14:39:50] <Darke> I've 'fixed' the problem (just committed the file to cvs). These are the three relevant objects: tools/compile/CompileProcess.o tools/compile/Compile.o tools/compile/llcLexer.o
[14:40:43] <Darke> Currently, at least until we find a compiled flex that works with gcc3+windows, there's no reason to run flex.
[14:41:15] <Kirben> I tried with just those few but seems to keep wanting more and more files.
[14:41:56] <Darke> I'll just make sure the llcLexer.cpp file is up to date whenever I commit changes to the llcLexer.l. Not that I expect to make regular changes or anything, I expect it'll be a while before I even get the stuff working that's detailed in the current lexer! *grin*
[14:42:26] <Darke> Ahh. Are you just adding the files as objects to the main pentagram .exe? It's integrated within the main executable at the moment.
[14:42:52] <Kirben> ah, was trying to compile it on its own.
[14:43:48] <Darke> Yeah. I'm going to try and get one that does that in the future, but it requires quite a bit of splitting up the monolithic Application class. So currently within pentagram it goes! *grin*
[14:52:26] * Darke is thankful he's had his one and only break severely code on another platform experience for this development project now. *grin*
[14:55:12] * Darke slips off to sleep before he finds out that he really *hasn't* fixed the problem, only delayed the inevitable. *grin* Night!
[14:55:28] --- Darke is now known as DarkeZzz
[14:57:08] <Colourless> wjp, i've just committed a change that gets rid of the 'wierd' lerping effect that you noticed
[15:00:07] <Colourless> the bug was simple, the camera thought the object was somewhere, where it wasn;t
[15:01:01] * DarkeZzz read that as 'wired' lerping and started wondering why you were dragging jelly-moulds around on puppet strings for... yeah, sleep. Right.
[15:01:30] <Colourless> you made a comment about slurping... well there is such as thing as slerping :-)
[15:02:03] <Colourless> lerp = linear interpolation, slerp = spherical linear interpolation :-)
[15:02:27] <DarkeZzz> Hmm... don't think it was me that made the comment, might have been wjp. *grin*
[15:02:54] * DarkeZzz thinks the acronyms sound cooler, if you don't know what they mean anyway. *grin*
[15:02:55] <Colourless> [10:38:43] <Darke> Kind of like a *slurp* *leap!* *sploosh-rollbouncerollbounceroll..* *slurp* *leap!*... etc.
[15:03:00] <Colourless> hmm, yes it must have been wjp :-)
[15:03:51] <Kirben> I still get a warning:
[15:03:52] <Kirben> In file included from c:/mingw/include/c++/3.2.3/backward/iostream.h:31,
[15:03:53] <Kirben> from c:/mingw/include/FlexLexer.h:47,
[15:03:53] <Kirben> from tools/compile/llcLexer.cpp:247:
[15:03:53] <Kirben> c:/mingw/include/c++/3.2.3/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated.
[15:03:55] <DarkeZzz> That was an accident. I have a weird memory of someone commenting about pity there isn't 'slerping' or something at one point in time. That I know wasn't me. *grin*
[15:04:21] <DarkeZzz> Erm... just a sec.
[15:05:01] <Colourless> works fine here
[15:05:15] <DarkeZzz> Ick. I see.
[15:05:17] <Colourless> the problem is with FLexLexer.h
[15:05:29] <Colourless> you need the new version of it too
[15:05:40] <DarkeZzz> You'll have to patch your installed copy of FlexLexer.h.
[15:06:26] <DarkeZzz> I think the 'easiest' method is to just copy pentagram/tools/compile/llcLexer.h to c:\mingw\include\FlexLexer.h the only difference should be llcLexer.h has been fixed.
[15:08:24] * DarkeZzz grumbles. All his efforts to minimse the need to have an install of flex that vaguely worked are eliminated because of a stupidly placed include. I wonder if the newer versions have removed that sillyness.
[15:08:35] <DarkeZzz> Anyway, hopefully will work now. I should sleep. *grin*
[15:09:11] <Kirben> would that break other flex using compiles though ? like ucc for exult
[15:09:24] <Colourless> kirben it might
[15:09:25] <Colourless> [10:38:43] <Darke> Kind of like a *slurp* *leap!* *sploosh-rollbouncerollbounceroll..* *slurp* *leap!*... etc.
[15:09:35] <Colourless> darke, you 'could' just modify the file
[15:09:53] <Colourless> so it doesn't include the FlexLexer
[15:10:59] <DarkeZzz> Yeah. Would have to include a sed script or something to strip it out when I compile. Would work.
[15:11:35] <DarkeZzz> According to my patches, the only difference to the file is removal of <iostream.h>, replacing it with <iostream> and adding appropriate std::'s.
[15:12:21] <wjp|work> Colourless: looks much better now (moving, that is)
[15:12:45] <DarkeZzz> It 'technically' shouldn't hurt anything and should actually make your copy of flex work for C++ programs...
[15:13:03] <DarkeZzz> I don't think normal C versions of .l files require the FlexLexer.h.
[15:13:11] <Colourless> it doesn't
[15:13:26] <DarkeZzz> Which is why you haven't tripped over the problem before most likely. *grin*
[15:13:51] * DarkeZzz blames all these problems on his urge to do it the 'proper' way, rather then the easy way. *grin*
[15:14:05] <Colourless> you had to go the c++ way :-)
[15:14:35] <DarkeZzz> Well we're using C++ right? Object orientated? All those buzzwords? *grin*
[15:14:59] <wjp|work> time to go home
[15:14:59] <wjp|work> bbl
[15:15:03] <-- wjp|work has left IRC ("bbl")
[15:16:03] * DarkeZzz really sleeps!
[15:24:06] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[15:37:45] --> wjp has joined #pentagram
[15:37:45] --- ChanServ gives channel operator status to wjp
[15:38:03] <wjp> back
[15:38:18] <Colourless> wb
[15:42:28] <Colourless> the head falling off the dock does look rather strange
[15:42:38] <Colourless> i
[15:42:46] <wjp> i?
[15:43:01] * wjp updates and builds
[15:43:08] <Colourless> i'm almost thinking that it might only be animating once for every 2 frames
[15:43:52] <Colourless> of course it just might look 'strange' because i'm doing a linear interpolation when a head falling would want a quadratic interpolation (gravity and all)
[15:46:40] <Colourless> when we have 'gravity' implemented, we might want to have a quadratic interpolator for falling/thrown objects
[15:47:42] <wjp> hm, the walking animations of some characters look to slow
[15:48:12] <wjp> I wonder if some npcs should have a different multiplier than others
[15:48:38] <Colourless> i think i'll look at the originals execution scene
[15:52:31] <Colourless> ok, this is how it's supposed to go
[15:53:12] <Colourless> mordea walks off, salkind follows. darion waits, then walks across, walks up, followed finally by shaana
[15:53:25] <Colourless> now, the animation rate for each character is different
[15:53:36] <Colourless> darions animation is much slower than shaana's
[15:54:06] <Colourless> shaana is quite possibly doing 2 animations for each of darion's 1
[15:55:45] <wjp> there are a lot of anim flags we don't know yet
[15:57:14] <wjp> the entire frame sequence header is unknown, it seems :-)
[15:57:20] <wjp> (except for the length byte)
[15:59:28] <-- Colourless has left IRC (Read error: 104 (Connection reset by peer))
[16:00:28] --> Colourless has joined #Pentagram
[16:00:28] --- ChanServ gives channel operator status to Colourless
[16:02:55] <wjp> data for Shaana: 05 01 00
[16:03:01] <wjp> data for Darion: 05 03 00
[16:03:13] <Colourless> hmm, interesting
[16:03:16] <wjp> data for Salkind: 05 02 00
[16:03:24] <Colourless> what about salkind?
[16:03:32] <wjp> beat you to it ;-P
[16:03:52] <Colourless> mordea? i'm guessing
[16:03:53] <Colourless> 2
[16:03:53] <wjp> the second byte might be repeat count
[16:03:57] <wjp> bingo
[16:04:01] <wjp> Mordea: 05 02 00
[16:04:20] <Colourless> want to 'hack' that in? :-)
[16:04:25] <wjp> widow: 05 02 00
[16:04:26] <Colourless> is avatar 1?
[16:04:33] <wjp> yes
[16:04:36] <wjp> 05 01 00
[16:05:18] <wjp> I think the widow moves too far forward if we double the distances, though
[16:05:31] <wjp> (that's what it was originally, and she walked almost into Darion)
[16:05:52] <Colourless> in order for it to look as good as possible, if that is frame len or repeats, then we should divide the distance for each of the repeated frame (smoother animation)
[16:06:15] <Colourless> i might try hacking it into animdisp
[16:06:18] <wjp> hm, only walk the distance once?
[16:06:25] <wjp> right, that would fix the distance issue
[16:06:29] <Colourless> yes but take 'n' frames to do it
[16:06:36] <wjp> Shaana would still look like she's walking in place, though
[16:07:02] <Colourless> it's not going to make any difference for her
[16:07:15] <wjp> oh, right, she's 01
[16:07:48] <wjp> I wonder if I should try adding that *2 back to the distance then
[16:07:55] <wjp> time to experiment :-)
[16:09:29] <Colourless> this animdisp code is a nightmare to look at
[16:09:45] <wjp> 'evolved' code? :-)
[16:09:50] <Colourless> yes
[16:10:02] <Colourless> evolved and then hacked up code :-)
[16:11:00] <Colourless> so, which byte do we want?
[16:11:26] <wjp> I'll commit my changes to animdisp
[16:11:33] <Colourless> ok thanks
[16:11:47] * Colourless looks at ActorAnim code and his brain almost melts
[16:11:58] <wjp> it's not _that_ bad :-)
[16:12:48] <wjp> uh oh
[16:12:53] <wjp> lots of uncommitted stuff there
[16:13:13] <Colourless> same thing here
[16:13:27] <Colourless> old contains lots of modifications :-)
[16:13:29] <wjp> good, my latest changes are independent of the rest
[16:14:15] <wjp> committed
[16:14:21] <wjp> you want the 'action->repeat' byte
[16:14:27] <Colourless> ok
[16:19:14] <Colourless> yes, that looks much better
[16:19:16] <wjp> is Shaana supposed to pass Darion?
[16:19:24] <Colourless> no
[16:19:30] <wjp> guess what :-)
[16:19:57] <Colourless> animations are starting too early
[16:20:11] <wjp> hm, any missing intrinsics which would cause that?
[16:20:19] <Colourless> no idea
[16:22:07] <wjp> weird
[16:22:32] <wjp> the animations look much better when I multiply 'deltadir' by 4 (instead of the current *2), but that makes people walk too far
[16:22:46] <wjp> (widow walks into Darion; Darion and Shaana walk right off the docks, etc...)
[16:23:37] <wjp> I'd try *3, but that's not a nice number :-)
[16:26:23] <Colourless> Npc::isBusy?
[16:26:32] <Colourless> no idea what that means
[16:38:35] <wjp> bbl, dinner
[16:39:18] <Colourless> i don't know if anim lock is being implimenting properly. currently we've got it being set for all animations, but it may have required explicit setting in the original
[16:52:22] <wjp> it could be affected by one of the frame flags
[16:53:01] <Colourless> true
[16:54:58] <wjp> our comment for byte 5, bit 1 as "interruptable? on the ground?"
[16:55:06] <wjp> that could be interpreted as the inverse of animlock
[16:55:09] <wjp> but I'm not sure
[16:55:54] <wjp> of course when animlock isn't just always set when animating, we'd have to decide how to handle a previous animation
[16:56:03] <wjp> (kill it, most likely)
[16:56:20] <wjp> although that could produce weird transitions
[16:56:30] <Colourless> perhaps
[18:30:18] <Colourless> sigh, yesterday, i actually forgot something :-)
[18:30:33] --> pauli|xchat has joined #pentagram
[18:30:55] <Colourless> if you look at the entries for intrinsics EE and EF you'll noticed they've been commented out. Looks like i forgot to uncomment them after doing test
[18:31:41] <Colourless> and looks like that was a good thing too since i've managed to break those 2 intrinsics :-)
[18:40:50] <wjp> BE, BF?
[18:41:07] <Colourless> ah yeah :-)
[18:41:17] <Colourless> don't know where i got EE and EF from :-)
[18:48:59] <wjp> the unhandled intrinsics called during the execution scene:
[18:49:06] <wjp> 0x44 (Item::hurl)
[18:49:13] <wjp> 0x50 (Item::getMapArray)
[18:49:18] <wjp> 0x52 (Item::setMapArray)
[18:49:32] <wjp> 0x72 (Egg::getEggXRange)
[18:49:41] <wjp> 0x74 (Egg::setEggXRange)
[18:49:55] <wjp> 0x77 (Egg::setEggId)
[18:50:22] <wjp> 0x79 (MonsterEgg::hatch)
[18:50:28] <wjp> 0x7A (MonsterEgg::getMonId)
[18:50:41] <wjp> 0xBB (playMusic)
[18:50:54] <wjp> 0xBE (Camera::setCenterOn)
[18:51:01] <wjp> 0xCF (getAvatarInStasis)
[18:51:11] <wjp> 0xED (playSFX)
[18:51:19] <wjp> 0xEE (playSFX)
[18:51:25] <wjp> 0xF1 (playAmbientSFX)
[18:51:28] <Colourless> getAvatarInStatis... i thought that was unused :-)
[18:51:32] <wjp> 0xF2 (isSFXPlaying)
[18:51:46] <wjp> 0xF5 (stopSFX)
[18:51:54] <wjp> (end of list)
[18:54:08] <wjp> I wonder where it's using Item::hurl
[18:54:37] <wjp> would almost have to be the falling head?
[18:55:07] <Colourless> i wouldn't have a clue
[18:55:19] <Colourless> the egg stuff would be for the 'lurker'
[18:56:59] <wjp> yes, hurl is called in the falling head code
[18:57:22] <Colourless> ok then, why does it still work :-)
[18:57:25] <wjp> at the very end, btw
[18:57:41] <Colourless> probably to splash in the water
[18:57:46] <wjp> that may be why the head doesn't properly disappear
[18:58:18] <Colourless> anything that hits the water is supposed to splash and disappear, execept for 'him' :-)
[18:59:55] <wjp> yes :-)
[19:05:41] <wjp> hm, we don't get unhandled intrinsic warnings from dummyProcesses of course
[19:06:00] <Colourless> no, because it doesn't give any :-)
[19:07:20] <wjp> we're getting a _huge_ amount of f2/ee calls (SFX related)
[19:07:28] <wjp> I guess it's repeating some SFX
[19:07:44] <Colourless> yes, it's a fast area related thing
[19:08:39] <Colourless> so, you might want to uncomment the callUsecode line in inFastArea
[19:14:28] <wjp> yes, much better :-)
[19:18:02] <wjp> hm
[19:18:24] <Colourless> s/uncomment/comment/
[19:18:27] <wjp> any timing issues in the walking away part seem to be caused by getCurrentTimerTick and animations
[19:19:01] <Colourless> ah doesn't surprise me. getCurrentTimerTick will need tweaking
[19:19:14] <wjp> it spawns (in turn) walking away processes for Mordea, Salkind, Darion, Shaana
[19:19:26] <wjp> with calls to FREE::1C19 in between
[19:19:54] <wjp> hm, and some walking animations too
[19:20:20] <wjp> EXCUTION::80 is the 'main' process for the execution (the hatch() event)
[19:20:39] <Colourless> yes, i know :-)
[19:20:45] <wjp> there's more to come :-)
[19:21:59] <wjp> the walking away part starts around 0DDC
[19:22:11] <wjp> where it spawns EXCUTION::10D8 (Mordea)
[19:22:44] <wjp> then Shaana does some animation
[19:22:46] <wjp> Salkind turns
[19:22:58] <wjp> Salkind does some animation
[19:23:13] <wjp> EXCUTION::1141 is spawned (Salkind)
[19:23:21] <wjp> timing call to FREE::1C19
[19:23:27] <wjp> Darion turns
[19:23:47] <wjp> EXCUTION::11F7 is spawned (Darion)
[19:23:57] <wjp> timing call to FREE::1C19
[19:24:14] <wjp> EXCUTION::1326 is spawned (Shaana)
[19:24:32] <wjp> guard walks a bit
[19:24:35] <wjp> timing call
[19:24:45] <wjp> widow walks
[19:24:54] <Colourless> do you want to commit your animation changes. :-)
[19:25:10] <wjp> widow turns, walks, kneels
[19:25:17] <wjp> music
[19:25:20] <wjp> more widow animations
[19:25:31] <wjp> timing call
[19:25:32] <wjp> end
[19:25:41] <wjp> oh, sure, I might as well :-)
[19:25:51] <wjp> I didn't smooth out the repeat animation yet, though
[19:26:44] <wjp> all the spawned processes seem to consist of do { walk() } until (reached some spot); teleport()
[19:28:18] <wjp> hm, lots of changes locally
[19:29:05] <wjp> ugh, now my 'llcLexer.cpp' is constantly flagged as modified
[19:30:05] <wjp> committed
[19:30:24] <Colourless> thx
[19:34:23] <wjp> I'll try having getTimerTick return the 'classic' 18.2Hz timer tick
[19:34:51] <Colourless> you know, that 'may' have actually been the games timing
[19:34:56] <wjp> it was
[19:35:06] <wjp> the kernel was wired into the timer interrupt
[19:35:29] <Colourless> 10 Hz, which what i've set, would be too slow
[19:35:44] <Colourless> now, it's hard for me to tell the speed because here in winxp ultima 8 runs slow
[19:36:16] <Colourless> it runs much faster in dos, and the 10 hz actually seems to be about what i'm getting here runing the original game in winxp
[19:36:32] <wjp> Shaana still passes Darion, though
[19:36:52] <wjp> frames are running at 10Hz, right?
[19:37:00] <Colourless> yes
[19:37:17] <Colourless> the Application constructor is where you can set the ms time for a frame
[19:37:18] <wjp> so framenum * 5.5 should be at 18.2Hz
[19:37:33] <wjp> (18.2Hz = 1/55ms)
[19:38:01] <wjp> hm, actually, no
[19:38:10] <Colourless> that's wrong :-)
[19:38:14] <wjp> I noticed :-)
[19:38:18] <Colourless> 1000/18.2 give you the ms
[19:38:28] <wjp> the ms count is correct
[19:38:48] <Colourless> which would be 55ms a frame approx
[19:38:52] <wjp> yes :-)
[19:38:56] <wjp> so 18.2Hz = 1/55ms
[19:39:17] <Colourless> no :-)
[19:39:37] <wjp> the 'ms' is in the denominator, btw
[19:39:39] <Colourless> why are you dividing 1 by 55?
[19:39:47] <wjp> am I really that sleepy? :-)
[19:41:06] <wjp> anyway, framenum * 100 / 55 should do it
[19:41:30] <wjp> although I'll have to get the right framerate instead of using the 100
[19:42:01] <Colourless> animationRate is ms per frame
[19:42:35] <wjp> ok, so frameNum * animationRate / 55
[19:43:03] <Colourless> yes perhaps
[19:43:15] <Colourless> multiply first, then divide :-)
[19:43:15] <wjp> now let's see what happens
[19:43:20] <wjp> of course :-)
[19:44:09] <Colourless> too slow
[19:44:33] <wjp> Shaana still easily catches up to Darion though
[19:47:10] <wjp> *yawn*.. this scene sure takes a long time with frame limiting :-)
[19:47:12] <-- Colourless has left IRC (Read error: 104 (Connection reset by peer))
[19:47:39] --> Colourless has joined #Pentagram
[19:47:40] --- ChanServ gives channel operator status to Colourless
[19:48:09] <wjp> hm, or maybe Shaana and Darion were off-screen by the time they reach eachother
[19:48:38] <wjp> is it really too slow?
[19:49:48] <Colourless> try first egg
[19:50:13] <Colourless> look how long the avatar is stuck on the ground
[19:50:15] <wjp> waits 3 or 4 seconds
[19:50:27] <Colourless> should be anywhere near that lobg
[19:52:59] <wjp> the wait appears to be 60 'ticks'
[19:55:12] <Colourless> really, we should make it independant of animationRate
[19:55:51] <wjp> it is right now, isn't it?
[19:56:02] <wjp> (framenum * animationRate)/something
[19:56:14] <Colourless> no it isn't
[19:57:04] <Colourless> if animationrate changes, it changes the number of frames that determines one tick
[19:57:16] <Colourless> hey using framenum * 2 seems to produce nice results
[19:57:33] <wjp> I have * 100 / 55 now
[19:57:38] <wjp> that's very close to * 2
[19:57:56] <Colourless> my guess that is probably approx to what it was
[19:58:13] <wjp> "it changes the number of frames that determines one tick" <-- I would call that independant of animationRate
[19:58:26] <Colourless> 182/100 would be better
[19:58:30] <wjp> so you want to have the number of frames per tick constant, or the time per tick?
[19:58:41] <Colourless> frames per tick constant
[19:58:59] <Colourless> so you can change the animationRate and it wont screw up all the timing
[19:59:07] * wjp nods
[20:00:56] <wjp> this does of course keep the avatar on the ground for 3+ seconds
[20:04:58] <Colourless> no, that timing is still not quite right.
[20:05:03] <Colourless> it's a bit too fast still
[20:05:59] <wjp> he's supposed to stay on the ground even longer?
[20:08:08] <Colourless> i'm taking about the walking
[20:08:10] <Colourless> at 320x200
[20:08:18] <wjp> ah :-)
[20:16:55] <Colourless> hm, i really don't kow
[20:18:46] <Colourless> something strange is going on. i up the frame rate silly amounts, and the timing of some things seems to go off
[20:19:09] <Colourless> the head for example becomes really jerky
[20:20:22] <Colourless> might be because it usesI_getCurrentTimerTick
[20:20:30] <wjp> it's not exactly smooth here at 10Hz
[20:21:55] <wjp> the head waits 10 'ticks' between movements
[20:22:37] <wjp> which is over 0.5s at 18.2Hz
[20:23:34] <Colourless> the pauses between darions steps are causing him to slow down and for shaana to catch him
[20:23:43] <wjp> yes
[20:23:54] <wjp> are the pauses noticable in the original?
[20:23:59] <Colourless> nope
[20:24:18] <wjp> the pauses are really long here... multiple frames
[20:24:26] <Colourless> yes, and they shouldn't be
[20:24:44] <Colourless> if anything, only a single frame
[20:24:47] <wjp> EXCUTION::11F7
[20:24:58] <wjp> (darion's walking code)
[20:25:22] <wjp> it waits 1E ticks?
[20:25:45] <wjp> confusing
[20:26:01] <wjp> even longer
[20:26:11] <wjp> the code, roughly:
[20:26:17] <wjp> some initial walking stuff
[20:26:24] <wjp> while (!far enough away)
[20:26:30] <wjp> wait 10 ticks
[20:26:38] <wjp> walk
[20:26:49] <wjp> wait 30 ticks
[20:27:03] <wjp> end while
[20:27:06] <wjp> something like that
[20:27:19] <wjp> hm, no
[20:27:29] <wjp> that second wait is skipped sometimes
[20:29:26] <Colourless> i don't get why it just doesn't seem to work
[20:29:51] <wjp> it could be that one of the conditions there is screwed up
[20:30:13] <wjp> heh, it actually compares the y coord of Darion with that of Salkind :-)
[20:30:24] <wjp> that's what triggers the wait
[20:30:34] <Colourless> speed it up and darion and shaana start moving too early. Slow it down and darion moves too slow
[20:31:07] <wjp> I don't really see which part of this depends on the framerate
[20:31:43] <Colourless> just try changing get tick to framenum*4 and watch them walking.
[20:31:59] <Colourless> darion is just so much smoother
[20:35:09] <wjp> ok, got Darion's usecode figured out
[20:35:32] <wjp> it's basically: walk 14 times with 10 ticks between walks. If too close to Salkind, wait 30 ticks.
[20:36:21] <Colourless> ok then, we 'should be able to work it out
[20:36:27] <Colourless> how long a tick should be
[20:36:42] <Colourless> we know how long darions walk animation is
[20:39:17] <wjp> Salkind's usecode is the almost the same, but it checks distance with Mordea, and doesn't do a 10-tick-wait
[20:39:42] <wjp> Mordea just walks; no waits
[20:40:27] <wjp> Shaana is actually checking distance with Darion
[20:41:29] <wjp> but she just walks by Darion, so something is broken there
[20:46:26] <wjp> hmmm
[20:49:53] <Colourless> yes?
[20:50:07] <wjp> just hmmming to myself a bit :-)
[20:52:41] <Colourless> darion has 8 frames of animation. times that by 3 to get the total time for the animation
[20:52:55] <Colourless> and the usecode waits 10 ticks
[20:53:09] <Colourless> so that would be about 2.4 frames /tick
[20:53:32] <wjp> it waits for the animation to finish separately
[20:53:45] <Colourless> it does?
[20:53:58] <wjp> I think so
[20:54:35] <wjp> yes, it does
[20:57:31] * wjp uhhhhs
[20:57:35] <wjp> apparently 3 != 3 is true
[20:57:35] <Colourless> yes?
[20:57:43] <Colourless> uh oh
[20:58:23] <Colourless> where?
[20:58:42] <wjp> EXCUTION::1461
[20:59:53] <Colourless> == then?
[21:00:20] <wjp> it's just not behaving the way I'm expecting it to
[21:00:32] <wjp> both getMapNum() calls return 3
[21:00:57] <wjp> and somehow the NE is returning true
[21:01:48] <wjp> eh
[21:01:51] <wjp> no, it's returning false properly
[21:01:58] <wjp> but
[21:02:49] <wjp> oh, I was obviously reading arguments in the wrong order... so it wasn't the 'ne' that's wrong, it might be the 'lt'
[21:03:09] <Colourless> wrong direction?
[21:03:15] <wjp> could be
[21:03:48] <Colourless> left is pushed first, so it's poped last
[21:03:57] <wjp> that's how I do things now
[21:04:23] <wjp> si16a = pop(); si16b = pop(); return (si16b < si16a);
[21:06:11] <Colourless> looks correct to me
[21:08:51] <Colourless> does if shaana->getY() < darion->getY() + 60
[21:09:18] <wjp> no, other way around, isn't it?
[21:09:25] <wjp> (the npc numbers, that is)
[21:09:33] <Colourless> uh yes
[21:09:47] <Colourless> that..d oesn't make sense
[21:09:55] <wjp> no...
[21:09:56] <Colourless> unless that doesn't do what we think it does
[21:10:14] <Colourless> it can't possibly make sense actually
[21:10:17] <wjp> positive y is south, right?
[21:10:21] <Colourless> yes
[21:10:59] <Colourless> but then, they are all doing it
[21:11:23] <wjp> and none of them are working? :-)
[21:14:39] <wjp> yes... all it does it make Shaana wait once she gets too far ahead of Darion
[21:14:57] <Colourless> same thing with salkind and mordea
[21:15:05] <Colourless> adds the 60h to salkind's y
[21:15:19] <wjp> which is just silly
[21:15:35] <wjp> unless we need to flip the coordinates somehow
[21:15:41] <wjp> but I don't think so :-)
[21:16:04] <wjp> (at least I hope not)
[21:16:27] <wjp> not likely we have add/sub mixed up either
[21:29:36] <wjp> so, let's call this a usecode bug?
[21:32:15] <Colourless> cya
[21:32:19] <wjp> night
[21:32:20] <-- Colourless has left IRC ("casts invisibility")
[23:04:46] <-- Dark-Star has left IRC ()
[23:34:59] <-- wjp has left IRC ("Zzzz...")
[23:58:45] --> Cashman has joined #pentagram
[23:58:56] * Cashman slaps pauli|xchat around a bit with a large trout
[23:58:58] <-- Cashman has left #pentagram ()
[23:59:02] --> Cashman has joined #pentagram