#nuvie@irc.freenode.net logs for 23 Feb 2004 (GMT)

Archive Today Yesterday Tomorrow
Nuvie homepage


[04:56:14] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[06:00:55] --> Kirben has joined #nuvie
[07:56:07] --> Yuv422 has joined #nuvie
[08:07:38] <wjp> hi
[08:08:28] <Yuv422> hi wjp
[08:09:26] <Yuv422> looks like I might go back to a c buffer for MsgScroll input. :)
[08:10:04] <wjp> the problem is just that you're returning something that's fairly 'private' to MsgScroll
[08:10:19] <wjp> (a direct reference to it, instead of a copy, that is)
[08:10:39] <Yuv422> yeah
[08:10:43] <wjp> using a char* buffer in MsgScroll and returning a pointer to it would have exactly the same problem
[08:10:57] <wjp> why not simply make get_input return a string?
[08:11:11] <Yuv422> hmm
[08:11:38] <Yuv422> I guess get_input isn't called too often
[08:11:45] <Yuv422> it should be ok to return a string
[08:12:00] <Yuv422> we might have to change a bit of code
[08:12:03] <Yuv422> let me check
[08:13:12] <Yuv422> yeah I think we might do that then
[08:14:26] <Yuv422> alt-314 has been broken since I reworked MsgScroll BTW ;)
[08:15:16] <wjp> I also found a problem with loading the actor schedules in Valgrind
[08:16:12] <wjp> 'schedules' contains 563 schedules, but the last actor that has schedules has index 262 and the next one index 264
[08:16:25] <wjp> meaning that the last schedule for that actor is read past the file
[08:17:46] <Yuv422> Ouch!
[08:17:49] <Yuv422> that's no good
[08:18:39] <Yuv422> there should only be 256 actors
[08:18:59] <wjp> oh, uh, typo, sorry
[08:19:05] <wjp> s/262/562/, s/264/564/
[08:19:41] <wjp> those are the schedule indices, btw
[08:19:49] <Yuv422> ah
[08:20:41] <Yuv422> just out of interest have you run nuvie through the valgrind profiler?
[08:21:02] <wjp> no
[08:21:08] <Yuv422> ah k
[08:21:08] <wjp> just the memory checker
[08:21:22] <Yuv422> I'll get around to profiling it some day
[08:21:33] <Yuv422> I'm sure I'm not going to like what I see though. ;)
[08:23:02] <wjp> oh, and another problem: in MapWindow::drawObj(), the last two ifs appear to be accessing tmp_buf out-of-bounds
[08:23:28] <Yuv422> that's no good
[08:23:37] <wjp> (unless I'm misinterpreting the ranges of x and y)
[08:24:31] <wjp> http://www.math.leidenuniv.nl/~wpalenst/valgrind_nuvie2 has the two errors near the end
[08:24:53] * Yuv422 looks
[08:25:57] <wjp> I already fixed two of the error in there, btw: the mismatched delete/delete[], and the uninitialized value in MsgScroll::add_new_line(); I just didn't make a new trace afterwards
[08:26:27] <Yuv422> ok
[08:26:30] <Yuv422> thanks
[08:28:03] <Yuv422> when it says something like this
[08:28:05] <Yuv422> Invalid read of size 2
[08:28:19] <Yuv422> does that mean it has overshot the buffer by 2?
[08:28:38] <wjp> no, that it read 2 bytes from an invalid location
[08:28:45] <Yuv422> right
[08:28:49] <wjp> a few lines later it should say where the location was in relation to valid memory
[08:29:34] <Yuv422> I guess that info isn't much use after the program exits
[08:29:52] <wjp> well, it gives the place the memory was allocated
[08:30:03] <Yuv422> oh you were you talking about this line
[08:30:15] <Yuv422> Address 0x4342A61A is 0 bytes after a block of size 338 alloc'd
[08:30:19] <wjp> yes
[08:30:50] <wjp> MapWindow.cpp referenced two lines lower is the place where tmp_buf is allocated
[08:32:19] <Yuv422> maybe win_width is undefined at that point?
[08:32:47] <Yuv422> or one of the surrounding vars
[08:32:48] <wjp> well, the buffer is (win_width+2)*(win_height+2) uint16s
[08:32:59] <Yuv422> hehe oh yeah
[08:33:29] <Yuv422> cur_x, cur_y?
[08:33:49] <Yuv422> or maybe we are getting a dodgy obj passed in
[08:33:55] <Yuv422> bbl
[08:33:57] <Yuv422> dinner
[08:34:02] <wjp> can x be win_width-1 or y win_height-1 ?
[08:34:39] <wjp> or even higher?
[08:34:57] <wjp> you do check x < 0 || y < 0 near the top of the function, but not if they're too large
[08:35:04] <wjp> (although I'm not sure if that can happen)
[09:37:28] <Yuv422> back
[09:38:07] <Yuv422> maybe if we get a double width/height object
[09:38:16] <Yuv422> on the edge of the mapwindow
[09:38:19] <Yuv422> let me check
[09:38:48] <wjp> drawObjSuperblock seems to return items with x coordinate 'cur_x + win_width'
[09:39:02] <wjp> wouldn't x in drawObj then be win_width?
[09:39:15] <wjp> (which would put x+2 = win_width+2 out-of-bounds?)
[09:40:25] <Yuv422> yes
[09:44:55] <Yuv422> hmm I think there are some other drawing issues here
[09:45:05] <Yuv422> with multitile objects at the window edges
[09:46:33] <Yuv422> actually that looks ok
[09:48:34] <Yuv422> we need to allow x = win_width
[09:48:57] <Yuv422> for the double width objects
[09:57:35] <Yuv422> now I've just got to figure out what I was doing on line 525. ;)
[09:59:11] <Yuv422> ah I remember now
[10:00:08] <Yuv422> removing objects from walls when next to darkness
[10:58:05] <Yuv422> it looks like I might need to add another row and column to that tmp_buf
[11:02:00] <Yuv422> I should probably rename it to something more appropriate too.
[12:05:40] <Yuv422> this might sound like a silly question.. but how do I copy the contents of one string to another if I have two string pointers?
[12:08:01] <Yuv422> at the moment I'm doing this
[12:08:03] <Yuv422> in_str->assign(s->c_str());
[12:15:33] <wjp> in_str = s;
[12:20:04] --> Yuv422_ has joined #nuvie
[12:20:27] <Yuv422_> Argh! I just had a mini power cut. :(
[12:22:30] <Yuv422_> that causes a segfault.
[12:22:37] <Yuv422_> setting in_str = s;
[12:25:23] <wjp> oh, wait, you said string pointers
[12:25:35] <wjp> as in "std::string *in_str, *s" ?
[12:25:39] <Yuv422_> yes
[12:25:40] <wjp> *in_str = *s;
[12:25:48] * wjp never saw string pointers before
[12:25:49] <Yuv422_> right
[12:25:57] <wjp> (never saw them used, that is)
[12:26:14] <Yuv422_> is it bad form to use strig pointers?
[12:26:24] <Yuv422_> string
[12:26:32] <wjp> that would depend on how you want to use them
[12:27:02] <Yuv422_> well I have a method that takes either a string or null
[12:27:22] <Yuv422_> null is the default arg
[12:27:26] <wjp> ah
[12:27:50] <Yuv422_> it's part of SB-X's converse code
[12:27:59] <Yuv422_> so I don't want to change it too much
[12:28:46] <Yuv422_> I've fixed the tmp_buf overrun
[12:28:52] <Yuv422_> I think. ;)
[12:33:32] <Yuv422_> does that mean C++ overloads the *var operator?
[12:37:46] <wjp> why?
[12:38:26] <Yuv422_> wouldn't one string need to invoke a copy method or something?
[12:38:31] <wjp> that's the '='
[12:38:39] <Yuv422_> right
[12:38:41] <wjp> std::string::operator=(std::string& other);
[12:39:31] <Yuv422_> yes that all makes sense now
[12:40:46] <-- Yuv422 has left IRC (Read error: 110 (Connection timed out))
[12:42:26] --- Yuv422_ is now known as Yuv422
[12:42:46] <Yuv422> ok my changes are in cvs now
[12:51:36] <Yuv422> I'm off to bed now
[12:51:38] <Yuv422> cya
[12:51:39] <-- Yuv422 has left IRC ("[BX] With a BitchX here and a BitchX there, here a BitchX there a BitchX everywhere a BitchX")
[14:32:37] --> KtJ_Dragon has joined #nuvie
[14:50:42] <-- Kirben has left IRC ("System Meltdown")
[15:41:53] --> laxdragon has joined #nuvie
[15:44:26] <-- KtJ_Dragon has left IRC (Remote closed the connection)
[16:25:41] --> SB-X has joined #nuvie
[16:54:07] <-- SB-X has left IRC ()
[17:26:59] <-- wjp has left IRC (Read error: 60 (Operation timed out))
[17:51:11] --> wjp has joined #nuvie
[22:01:14] <-- laxdragon has left IRC (kornbluth.freenode.net irc.freenode.net)
[22:01:32] --> laxdragon has joined #nuvie
[23:38:44] --> Kirben has joined #nuvie