Grum Report post Posted May 30, 2005 Well, I have to admit that I haven't tried the patch, but I'm pretty certain that those ants won't start moving. I;m guessing that in in floodfill() , the line while(r != 0) { should be while(r == 0) { I'll try it out tomorrow. After I find out how to change the height value Share this post Link to post Share on other sites
mikeman Report post Posted May 30, 2005 (edited) Better ideas on how to detect which object is under the mouse are more than welcome Clear the depth buffer with 1.0, render the object and read the depth value of that pixel. If it's less than 1.0, then there is an object rendered there. In every "collision" evaluation re-select a new object only if the zvalue is less than the previous "selected" one. That way if 2 objects cover the same area you will select the visible one. Edited May 30, 2005 by mikeman Share this post Link to post Share on other sites
crusadingknight Report post Posted May 30, 2005 (edited) Well, I have to admit that I haven't tried the patch, but I'm pretty certain that those ants won't start moving. I;m guessing that in in floodfill() , the line while(r != 0) { should be while(r == 0) { I'll try it out tomorrow. After I find out how to change the height value 166084[/snapback] Yep, you got it. I just fixed that, tried tp upload immediately... but my @#*$ ISP has been down ever since. Anyway, in that time, I fixed up some stuff, mixed that logic error, and most importantly, removed two iterations and functional duplication. Unfortunately, even now, it's still a bit slow, especially in 256x256 tiles; I figure we should maybe popup an immovable window before we start running the floodfill? -- EDIT: What do you mean, change the height value? Edited May 30, 2005 by crusadingknight Share this post Link to post Share on other sites
Grum Report post Posted May 31, 2005 Clear the depth buffer with 1.0, render the object and read the depth value of that pixel. If it's less than 1.0, then there is an object rendered there. In every "collision" evaluation re-select a new object only if the zvalue is less than the previous "selected" one. That way if 2 objects cover the same area you will select the visible one. 166090[/snapback] Something tells me I should've thought of that Thanks for the tip, it worked fine in my tests. So unless I messed something else up, the black body problem is fixed EDIT: What do you mean, change the height value? Since I never use the map editor, I have no clue what its commands are, so I always have to read the manual before testing Anyway, found it out, stairs icon, new object ... Unfortunately, even now, it's still a bit slow, Here's a simple idea, of which I have no clue if it would be any faster, but it just might work: sort all tiles with the old height into clusters using the Hoshen-Kopelman algorithm. Then fill the right cluster with the new height. Though this would require two passes over the whole map (IIRC), you don't spend any time testing if tiles are occupied or allocating new ants. Share this post Link to post Share on other sites
Grum Report post Posted May 31, 2005 Okay, I tried your patch, and it is indeed slow also noticed that you fill diagonally, so that if we have something like: | | | |xxx | xx | x +-------- and you start filling in the corner, the part outside the box will also be filled. Is that intentional? Two comments: * The time for flood filling can be reduced by a factor of two if you would do it only once instead of twice In events.c, the first call to map_floodfill() should be removed. By the looks of it, this part of the code deals with dragging the mouse, and in fact should only be called when left_mouse > 1, and not when left_mouse != 0. * My cluster idea seems to work. It's 6 to 8 times faster than flood filling a complete map, but it does not fill diagonally like your patch does, and the difference is smaller when filling smaller areas. I'll send you the routine so that you can try if it works as it should. Share this post Link to post Share on other sites
crusadingknight Report post Posted June 1, 2005 (edited) Ungh, I'll look at that tomorrow... have to finish a bunch of reports today. :\ As for the diagonal, that's there because, this way, we fill walkable paths for the character, since we can walk on diagonals. Edited June 1, 2005 by crusadingknight Share this post Link to post Share on other sites
Grum Report post Posted June 1, 2005 As for the diagonal, that's there because, this way, we fill walkable paths for the character, since we can walk on diagonals. 166368[/snapback] Ah yes, that makes sense. How about the close-to-most naive implementation: void floodfill2 (unsigned char new_height, int x, int y) { int size = tile_map_size_x * 6; unsigned char old_height = height_map[y*size+x]; int i, imin, imax; for (i = x; i >= 0 && height_map[y*size+i] == old_height; i--) height_map[y*size+i] = new_height; imin = i > 0 ? i : 0; for (i = x+1; i < size && height_map[y*size+i] == old_height; i++) height_map[y*size+i] = new_height; imax = i < size-1 ? i : size-1; if (y > 0) { for (i = x; i >= imin; i--) if (height_map[(y-1)*size+i] == old_height) floodfill2 (new_height, i, y-1); for (i = x+1; i <= imax; i++) if (height_map[(y-1)*size+i] == old_height) floodfill2 (new_height, i, y-1); } if (y < size-1) { for (i = x; i >= imin; i--) if (height_map[(y+1)*size+i] == old_height) floodfill2 (new_height, i, y+1); for (i = x+1; i <= imax; i++) if (height_map[(y+1)*size+i] == old_height) floodfill2 (new_height, i, y+1); } } I don't think you'd easily run into stack problems with this, and it's fast. Share this post Link to post Share on other sites
crusadingknight Report post Posted June 1, 2005 (edited) Nice In a related note, there should be no more full-file patches due to newlines, because I just installed and configured Code::Blocks as my new IDE... And compiled EL with it. Edited June 1, 2005 by crusadingknight Share this post Link to post Share on other sites
Lachesis Report post Posted June 3, 2005 I don't think you'd easily run into stack problems with this, and it's fast. 166503[/snapback] Try to fill such an area with your function: :twisted: .[b dQQQb dQQQb dQQQb dQQQb dQQQb dQQQb d] . H H H H H H H H H H H H H H .dP Yb dP Yb dP Yb dP Yb dP Yb dP Yb dP Yb .H H H H H H H H H H H H H H .Yb dP Yb dP Yb dP Yb dP Yb dP Yb dP Yb dP . H H H H H H H H H H H H H H .dP Yb dP Yb dP Yb dP Yb dP Yb dP Yb dP Yb .H H H H H H H H H H H H H H .Yb dP Yb dP Yb dP Yb dP Yb dP Yb dP Yb dP . H H H H H H H H H H H H H H .dP Yb dP Yb dP Yb dP Yb dP Yb dP Yb dP Yb .H H H H H H H H H H H H H H .YQQQP YQQQP YQQQP YQQQP YQQQP YQQQP YQQQP The first hit on google when searching for "flood fill algorithm" leads to a guided derivation of a both faster* and iterative (non-recursive) variant of the above algorithm, can we use that one maybe? Not much faster in the above example, of course. But even in that evil case it's at least non-recursive. And please add something like if (new_height == old_height) return; somewhere It doesn't cost much computation and makes the alogrithm terminate under all circumstances. Share this post Link to post Share on other sites
Roja Report post Posted June 17, 2005 hahaha! I just found a big huge smegging bug When you delete an object, it doesn't delete it..it makes it blended! But, if you make an object blended, and do not modify the RGB, it becomes invisible, so you THINK you delete it As a side note: We might have a bunch of maps with these "deleted" objects. Would it be possible to run the maps through a script that deletes all blended objects with values of 0,0,0 ? Share this post Link to post Share on other sites
Wytter Report post Posted June 17, 2005 Actually that bug is already fixed. Update your sources Share this post Link to post Share on other sites
Sistema Report post Posted June 17, 2005 yes, I've just realised! thnx! Share this post Link to post Share on other sites
Roja Report post Posted June 17, 2005 already fixed???? You might want to tell me about these things sooner, since it was a big bug.... Share this post Link to post Share on other sites
Roja Report post Posted June 17, 2005 Ok, tested it out. Luckily the thing compiled for me Seems like that bug is fixed, but the already existing objects that were blended and not deleted are stuck..i can't remove them/pick them up. the only way i know they are there is becuase they show up on the global map view. In fact, these are black 3d tiles..maybe it has something to do with the black object bug too? Share this post Link to post Share on other sites
Daxon Report post Posted June 18, 2005 Well, the 'blended' objects for my map only make it look tacky in minimap mode. Otherwise, I can't see them causing a problem. Share this post Link to post Share on other sites
Wytter Report post Posted June 18, 2005 The "blended" 3d objects does not exist and will not be shown in-game. Adding a new 3d object will get rid of them, since they'll take over that position. So you should not see them - I'll fix the error with them showing up in the minimap mode. Share this post Link to post Share on other sites
Roja Report post Posted June 18, 2005 Ok Can you please let me know when you fix it though? Share this post Link to post Share on other sites
Roja Report post Posted June 27, 2005 Ok, now it seems like the particle editor is broken? No matter what I do I don't get any different preview of the particle, and if i try to save it, and open it, nothing will appear. Share this post Link to post Share on other sites
Roja Report post Posted June 30, 2005 ok i think that that wasn't a bug after alll...it's not happening anymore..hm. anyway, i did find another bug, when trying to save over a particle file, it will not save(this was a past bug)..looks like it's back? Share this post Link to post Share on other sites
