Understated Ur-Drakon Celtic Minstrel Posted December 17, 2009 Share Posted December 17, 2009 (continued from here) Originally Posted By: Niemand O_0 That was. . . impressive. It's been over ten minutes since I ran that thing, and my system still hasn't fully recovered. I'm so sorry... Originally Posted By: Niemand As best I can tell, what it did when I tried to edit a terrain was that it created a gigantic window, far larger than my screen, and tried to tile it with one of the background textures. It was so large, though, that the space needed to buffer it greatly exceeded the capacity of my video RAM. By the time I was able to get past it scribbling all over my screen and force quit it, it had forced everything else but the OS out of RAM and into swap space. As I recall, the size is not consistent between times; somehow either the variables to hold the size are not being initialized, or the size is being grabbed from out-of-bounds memory (or just the wrong place in general). I think it's the former; I just can't understand how. Originally Posted By: Niemand Anyway, now that I can very much see it malfunctioning, I'll try to get some idea what's going wrong. I suggest that we take this to a thread of its own, as it may require more discussion and it would be nice to cut down on the thread hijacking/rambling in this forum. Good idea. Quote Link to comment Share on other sites More sharing options...
Well-Actually War Trall Niemand Posted December 17, 2009 Share Posted December 17, 2009 Quote: As I recall, the size is not consistent between times; somehow either the variables to hold the size are not being initialized, or the size is being grabbed from out-of-bounds memory (or just the wrong place in general). I think it's the former; I just can't understand how. I'm trying to understand where a window size is supposed to come form in the first place: there appears to be none specified in edit-terrain.xml at all, for example. Is it supposed to be dynamically sized to fit by recalcRect()?EDIT: Yeah, I think that at least one problem is manifesting in recalcRect(). I got sick of stepping through the loop over all of the controls so I just added a print statement for the new bounds values after each iteration: Code: 8cTextMsg "$}.0~.Wtw{hOO$KF!5wz~Wx%MU;/pK @/eQvg+l"r:588 b:3998cTextMsg "$~z0^Sph9Oa[3\U,_7Z+),LZ<UrAO]A"r:588 b:39910cTextField "arena"r:588 b:3999cLedGroup "blockage"r:10047 b:12933 It looks like the size of an LED group is being drastically miscalculated. Aside: What on earth is the reason for generateRandomString()? If you need unique identifiers, why not use sequential numbers?EDIT 2: Code: --- button.cpp (revision 142)+++ button.cpp (working copy)@@ -265,6 +265,7 @@ } void cLedGroup::recalcRect(){+ SetRect(&frame,0,0,0,0); ledIter iter = choices.begin(); while(iter != choices.end()){ if(iter->second->frame.right > frame.right) Quote Link to comment Share on other sites More sharing options...
Understated Ur-Drakon Celtic Minstrel Posted December 17, 2009 Author Share Posted December 17, 2009 Originally Posted By: Niemand Quote: As I recall, the size is not consistent between times; somehow either the variables to hold the size are not being initialized, or the size is being grabbed from out-of-bounds memory (or just the wrong place in general). I think it's the former; I just can't understand how. I'm trying to understand where a window size is supposed to come form in the first place: there appears to be none specified in edit-terrain.xml at all, for example. Is it supposed to be dynamically sized to fit by recalcRect()? Oh right! I forgot about that. Originally Posted By: Niemand It looks like the size of an LED group is being drastically miscalculated. Okay... that shouldn't be too hard to fix... ...oh wait, you're saying that adding a SetRect in cLedGroup::recalcRect() should fix it? Wow. That's a pretty small error. So, does it work now, then? Originally Posted By: Niemand Aside: What on earth is the reason for generateRandomString()? If you need unique identifiers, why not use sequential numbers? Um... I dunno, actually. I guess I just didn't think of that. It's a good idea though. I'm not quite sure if I strictly need unique identifiers for everything, but any control that needs to be accessed later would need a unique identifier. And those all have their identifier specified within the xml file. Quote Link to comment Share on other sites More sharing options...
Well-Actually War Trall Niemand Posted December 17, 2009 Share Posted December 17, 2009 That fix doesn't solve everything, but it does get to the point of displaying a properly sized window with the controls laid out correctly. That window still appears in a bad place, jammed up under the menu bar, and the controls themselves don't draw properly, but it's progress. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.