#pentagram@irc.freenode.net logs for 5 Jul 2005 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[00:36:24] <-- sbx has left IRC ()
[01:06:44] <servus> `cvs status`
[01:06:58] <servus> You know, so you don't forget cvs adds and that sort of thing :P
[01:12:08] --> sbx has joined #pentagram
[01:35:02] --> EsBee-Eks has joined #pentagram
[01:51:09] <-- sbx has left IRC (Read error: 110 (Connection timed out))
[02:53:17] --- EsBee-Eks is now known as sbx
[03:01:13] <megawatt> well, I've been holding onto this changes a bit too long now. Think I'll commit soon
[03:10:02] <megawatt> hmmm.. or not... conflicts are the price I pay I guess.
[03:16:31] --- ChanServ gives channel operator status to megawatt
[03:21:37] <Colourless> :-)
[03:21:43] <Colourless> always the way
[03:24:55] <megawatt> I see pentagram is now much more than an engine, but a game itself :-)
[03:25:55] <megawatt> + GAME_PENTAGRAM_MENU
[03:26:01] <Colourless> a technicality :-)
[03:26:32] <megawatt> so, how does one tell it to not start u8 again?
[03:26:50] <Colourless> put defaultgame=pentagram in the 'pentagram' section of the ini
[03:27:58] <Colourless> or run pentagram with "pentagram --game pentagram"
[03:28:34] <megawatt> compiling seems to take some time nowadays.
[03:30:06] <megawatt> ahh done.
[03:30:37] <megawatt> I dig the red cursor
[03:31:16] <Colourless> HIDBindings tend to crash pentagram at the moment :-)
[03:31:36] <megawatt> errr... hmmm. really?
[03:31:47] <Colourless> yeah
[03:31:51] <Colourless> i haven't 'fixed' them yet :-)
[03:32:12] <Colourless> they assume certain things about the engines state
[03:32:34] <Colourless> like that u8gumps.flx is loaded for example :-)
[03:33:17] <megawatt> ah... are any of the breaking ones in stdbindings.cpp?
[03:34:04] <sbx> didn't you change --game pentagram to just pentagram?
[03:34:27] <Colourless> i didn't change that yet
[03:34:36] <Colourless> i don't know
[03:34:39] <Colourless> i haven't looked
[03:34:55] <megawatt> ah... quit binding breaks things....
[03:35:15] <Colourless> yes
[03:37:09] <Colourless> avatarInStasis, engineStats (purely because it gets 'world' and world doesn't exist with no real game running), quickLoad, quickSave, quickMove*
[03:37:32] <Colourless> and quit
[03:37:43] <Colourless> which is like most of the bindings :-)
[03:38:09] <megawatt> wow... hmmmm... that could be difficult..
[03:40:16] <Colourless> i'll fix it up at some stage
[03:40:23] <sbx> are you removing the dependence on U8 to prepare to support Crusader, perhaps?!
[03:40:43] <Colourless> partially
[03:40:50] <sbx> :S
[03:40:56] <Colourless> i need to do this so we can have pentagram menu working
[03:41:05] <sbx> ah
[03:41:05] <Colourless> pentagram is supposed to be able to run without any games defined
[03:41:12] <Colourless> and then you will use the GUI to add games
[03:41:57] <sbx> yeah it sounds good to get that capability in at this point
[03:42:22] <sbx> I hope the Pentagram menu and setup is fullscreen, not the small size of the U8 menu.
[03:42:56] <sbx> but maybe when I played the U8 menu was just unscaled
[03:43:29] <Colourless> actually pentagram menu will probably be initially windowed
[03:43:58] <Colourless> but it wont be 320x200 :-)
[03:44:07] <megawatt> I think we can at least assume we can do a unscaled 640x400
[03:46:23] <sbx> is it possible to have Crusader's funky controls?
[03:46:50] <megawatt> I hope sometime.
[03:47:24] <megawatt> I think I wanted to get joystick fully working first.... ugh, I've been lazy.
[03:49:58] <megawatt> I want to have normal u8 movement, absolute movement (left for left, right for right) , relative movement (left to turn counter-clockwise), and pathfinding movement (click to walk)
[03:50:11] <megawatt> but I'm not holding my breath.
[04:00:05] <megawatt> ok... bombs away.
[04:17:39] <megawatt> think I'll try to pool Shape and its subclasses too.
[04:23:42] <megawatt> does not appear to affect much... blah... I need a good count of the class types I've pooled.... or perferrably the base type in this case...
[04:27:33] <sbx> is the memory management like the frags that crusader uses
[04:27:54] <sbx> when you press ctrl-v it says "Memory allocation: FRAG1... FRAG2..."
[04:28:10] <megawatt> oh? No, I don't think so.
[04:28:59] <sbx> I guess that's fragment.
[04:29:13] <megawatt> but I might look into that.... the allocation method we use is a little umm... wasteful.
[04:29:17] <sbx> a block of memory
[04:29:22] <megawatt> yes.
[04:29:37] <sbx> didn't you switch to the current method so it wouldn't be as wasteful? :)
[04:29:56] <megawatt> of system resources.
[04:30:11] <megawatt> I probably still is on a number of systems.
[04:30:22] <megawatt> *it
[04:31:51] <megawatt> It is definitely faster now, but I couldn't say whether it actually uses less or more memory than normal allocation.
[10:18:46] --- sbx is now known as sbx|away
[10:23:41] <-- Colourless has left IRC ("casts improved invisibility")
[11:37:43] --> Dark-Star has joined #pentagram
[11:38:17] <Dark-Star> hi
[11:39:25] <Dark-Star> SF.net's ViewCVS seems to be still lacking behind commits *sigh*
[11:40:05] <Dark-Star> I browsed through the commit mails today and saw what might be a typo/bug, but I'm not sure...
[11:42:02] <Dark-Star> anyway, in misc/pent_include.cpp, a namespace was added with the memory allocator function pointers...
[11:42:52] <Dark-Star> From the diff it looks like the namespace was put inside the "#ifndef DONT_DEFINE_C_EMPTY_STRING", someone should check if it's supposed to be there or rather outside (my guess)
[11:43:28] <megawatt> whoops.
[11:58:49] <megawatt> and a typo in an include.... compiling
[12:07:40] <megawatt> commited
[12:09:34] <megawatt> new font remi
[12:10:03] <megawatt> new font reminds me of another game's console font... can't remember which
[12:10:18] <megawatt> it's nice
[12:16:37] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[12:19:03] --> Kirben has joined #pentagram
[12:19:03] --- ChanServ gives channel operator status to Kirben
[13:09:52] <-- Kirben has left IRC ("System Meltdown")
[13:10:24] <wjp> servus: there are too many unversioned files in my working copy, unfortunately...
[13:10:29] <wjp> maybe I should clean up sometime :-)
[13:10:49] <wjp> French keyboards are interesting :-)
[13:11:01] <wjp> after trying for a day I gave up and set the keyboard layout to US
[13:11:16] <wjp> so now I just have to avoid looking at the keyboard :-)
[15:14:20] --> watt has joined #pentagram
[15:14:34] --- ChanServ gives channel operator status to watt
[15:15:54] <watt> wjp: In France? Why.. or better yet.. why at a keyboard in France?
[15:16:52] <watt> I'd imagine you're there for a reason other than learning to use French keyboards :-)
[16:24:41] <-- Naryan has left IRC ("Trillian (http://www.ceruleanstudios.com")
[19:01:21] <watt> yuk... I still think no compiler should ever allow "char buf[len+1];" to compile. I guess it is easy to interpret and fix with a good compiler, but it is still poor coding practice.
[19:48:01] --- sbx|away is now known as sbx
[19:55:03] <sbx> watt: i don't get it
[19:55:32] <sbx> because you're making the buffer 1 byte too large?
[19:56:01] <sbx> (confusing the meaning of 'len')
[19:56:12] <watt> len is a variable.
[19:56:43] <sbx> hmm
[19:56:50] <sbx> that won't compile in ansi-c will it?
[19:57:13] <watt> meaning if the compiler manages to compile it... it is actually dynamically allocating it
[19:57:21] <watt> don't think it will
[19:57:46] <sbx> thanks for reminding me
[19:58:38] <sbx> i can't see myself doing that, i just didn't see any errors at first glance
[19:59:22] <watt> it may be wordy but I still prefer "char *buf = (char *) malloc(sizeof(char) * (len + 1)" and a free later.
[19:59:40] <watt> opps... "(len + 1));
[20:00:41] <watt> although with all warnings I think that still would complain about declaration and initialization on the same line
[20:02:04] <sbx> I've never seen it unless len is constant. (like a #define)
[20:02:17] <watt> c99 might not care.
[20:03:13] <sbx> I mean I don't remember.
[20:03:20] <watt> oh.. well the previous line was "int len = [aClassName cStringLength];" aClassName being an NSString (Objective-C GNUstep runtime)
[20:03:58] <sbx> I imagined len would be passed as an argument to the function.
[20:04:06] <sbx> What's the [ ] do?
[20:04:51] <sbx> looks like a variable name missing... i don't know objC
[20:04:54] <watt> calls the "selector" on the class
[20:05:27] <sbx> hmm ok
[20:05:30] <watt> aClassName.cStringLength() is roughly a equivilent syntax
[20:06:18] <watt> std::string::c_str() --- C++
[20:06:32] <watt> err... make than len()
[20:06:44] <watt> or length()... I forget
[20:12:15] <watt> hmmm... looks like variable length arrays are allowed in c99.... that's a shame IMO
[20:15:20] <watt> If I was never force to learn to use new and delete (learned C++ first) for that exact reason... it might have taken a lot longer for me to catch onto to it.
[20:15:37] <sbx> maybe that's why I missed it :)
[20:15:57] <sbx> Does it automatically free the array memory when the function is left?
[20:16:29] <sbx> I know how it would work for a normal array but if it's dynamic I'm not sure.
[20:17:18] <sbx> There really aren't any "arrays" in C, but you know what I mean.
[20:17:56] <Dark-Star> what's so bad about variable-length arrays in C99? I mean if it compiles then it's probably nothing more than an alloca()
[20:18:23] <sbx> Is that right? Then it would free automatically.
[20:19:02] <sbx> though I never use alloca() myself
[20:20:22] <Dark-Star> I can see only one problem with it, that is if len is very big (stack overflow). But if you take care that this doesn't happen then it might be quite handy to have automatically-allocated arrays
[20:23:15] <watt> my problem is that it would cause people who have not learned alloc to go out of their way to avoid it and not understand the difference. Maybe I've become too old-fashioned, but it doesn't seem very C-like
[20:25:48] <watt> I also feel the same about variable declaration at the top of a function or in braces. C99 works like C++ in that reguardl; It allows declaration anywhere in the function. Makes things messy sometimes.
[20:27:57] <Dark-Star> true. But I don't think using variable-length arrays makes code more messy or less readable. It's just a shortcut ("syntactic sugar" as my prof would have called it)
[20:30:01] <Dark-Star> anyway, I don't need this feature. one thing I'd rather like to see is support for "char foo[0];" but that is only a gcc-specific extension
[20:30:12] <sbx> i never see variables declared anywhere in a function
[20:30:23] <sbx> is that the same as char *foo; ?
[20:30:37] <Dark-Star> no, it's an array with 0 bytes length
[20:30:43] <sbx> char foo; ?
[20:30:57] <Dark-Star> it's quite useful for example if you want to pack variable-length data in a network-packet for example
[20:31:04] <watt> well... the first time I see "int len = 1; char buf[len];.... return buf;
[20:31:12] <watt> I think I'll kill something
[20:31:23] <Dark-Star> like "struct foo { int length; char payload[0]; }"
[20:31:42] * sbx gives watt a stressball. :)
[20:32:03] <watt> although "char buf[10]; ... return buf;" is just as bad
[20:32:29] <sbx> If "char foo[0];" isn't supported, what is the alternative?
[20:32:32] <Dark-Star> watt: well, this should be caught by the compiler, of course
[20:32:35] <sbx> that's what I was asking
[20:32:46] <watt> good point
[20:33:39] <sbx> or what is the c99 equivalent
[20:34:04] <sbx> just using dynamic memory?
[20:34:27] <Dark-Star> sbx: I suppose char[1]; would be a possible workaround, although this might allocate 1 byte too much (or 4 bytes, depending on alignment) which might cause other problems (i.e. packing these structs after each other wouldn't work anymore)
[20:34:41] <Dark-Star> s/might allocate/allocates/
[20:35:25] <sbx> ah, ok
[20:35:52] <sbx> wouldn't the payload be 1 byte then?
[20:36:53] <sbx> "The alloca function is machine and compiler dependent. On many systems its implementation is buggy. Its use is discouraged."
[20:37:03] <Dark-Star> yes, you'd have to use the .length field for all size calculations and not rely on the length of the array (this is the same for char foo[0])
[20:37:23] <sbx> oh that's right
[20:37:40] <Dark-Star> one more reason for not using alloca :)
[21:54:18] <watt> ok... this bug is a complete nightmare trainwreck from hell.
[21:57:05] <-- Dark-Star has left IRC ()
[21:57:38] <watt> all the code looks good. It bombs in a dll. The test program doing the same thing works, and copying the source from the function it calls into the code work (which is presumably the source used to compile the exact version of the dll)
[21:57:58] <watt> I'm going far more insanse than I already was.
[21:58:04] <watt> -- quote
[21:58:34] <watt> blah... I'm going home.
[21:58:36] <-- watt has left #pentagram ()
[22:13:10] <sbx> :\
[22:17:13] <-- sbx has left IRC ("casts gate travel")
[22:54:45] --> sbx has joined #pentagram
[23:10:39] --> Colourless has joined #Pentagram
[23:10:39] --- ChanServ gives channel operator status to Colourless
[23:12:35] <sbx> Hi Colourless
[23:15:51] <Colourless> hi
[23:23:59] --> Kirben has joined #pentagram
[23:23:59] --- ChanServ gives channel operator status to Kirben
[23:30:17] --- sbx is now known as SB-X
[23:33:43] <megawatt> I really really do like that font
[23:39:00] <Colourless> which font?
[23:40:02] <megawatt> the new console font
[23:40:19] <Colourless> ah. :-)
[23:40:54] <Colourless> thought we could do with something a bit bigger and more interesting
[23:41:58] <megawatt> just need a transparent background, a three way switch on the console toggling, and a keyrepeat (for backspace) and I'd be extremely happy
[23:42:42] <megawatt> guess I just said one of the easy fixes I could do right now.... keyrepeat.
[23:45:09] <megawatt> can I use PaintThis on gumps as a good idle loop or does it only get called as needed?
[23:45:29] <Colourless> PaintThis will get called every frame
[23:46:27] <megawatt> ok to do key repeating in there then, or should I do the more "elegant" solution of a separate process
[23:48:03] <Colourless> i wouldn't use a process for it. I'd probably just modify GUIApp::run()
[23:48:59] <Colourless> but a process could probably work
[23:49:07] <SB-X> what other games does that font remind you of?
[23:49:21] <megawatt> can't remember.
[23:49:26] <Colourless> thing about key repeat... it now seems to be working for me
[23:49:39] <Colourless> as in, keyrepeat from SDL is working
[23:49:58] <megawatt> oh... it is....
[23:50:21] <megawatt> ???
[23:50:26] <Colourless> for me it is
[23:50:51] <Colourless> i think i caused something to change when i started reorganizing things..
[23:50:53] <megawatt> same here.... that wasn't always the case I though
[23:50:55] <megawatt> t
[23:50:57] <SB-X> yeah that just something you have to enable with SDL
[23:51:00] <Colourless> it wasn't
[23:51:25] <megawatt> (good thing I didn't start hacking at it then)
[23:51:45] <Colourless> :-)
[23:56:36] <megawatt> been there since 04/28 looks like ---- wow, way to go about paying attention Matthew! woo
[23:57:26] * megawatt mutters to himself a bit more
[23:58:55] <Colourless> hehe
[23:59:47] <megawatt> oh GUIApp::enterTextMode does it... smart.