| 10-26-2003, 12:51 PM | #31 |
What about this PolarProjectionBJ modification? It returns no handle, but move existing location to new position! When handle is transferred as argument, it stay unchanged, isn't it? So we can use this handle to reffer one object from both 'parent' and 'child' functions: Code:
[color=coral] function PolarProjectionNL takes location source, real dist, real angle returns nothing local real x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD) local real y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD) call MoveLocation(source, x, y) endfunction function CallProjection takes nothing returns nothing local location Loc = Location(0,0) call PolarProjectionNL(Loc, 10, 10)[/color] // Loc in now moved to new position. //....[color=coral] endfunction [/color] Will it work? Seems to be, I haven't tested it yet. |
| 10-26-2003, 06:05 PM | #32 |
EDIT: Sorry, this post slipped before i could finish it: But yeah, I had some serious problems with this, as there is this unit that every 0.01 second calculates polar projections and does something depending on it, and after 4 minutes of gameplay, the game would lag heavily, and it would take ages to exit game. But this function, fixes it ALL, there is NO lag at all and it's clean as hell, it uses a global (you don't need to reference to it anywhere else, as it "returns" the global). You can also throw it into blizzard.j and use a BJ variable. Anyways, this little function saved my ***, and it works great. Code:
function CreateLocation takes location source, real dist, real angle returns location local real x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD) local real y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD) call RemoveLocation(udg_testLoc) set udg_testLoc = Location(udg_PolarX, udg_PolarY) return udg_testLoc endfunction Cubasis btw: thanks to AlphaBeta for this function, he's my saviour |
| 10-26-2003, 07:15 PM | #33 | |
Quote:
This function might require some testing however. I think that if you have it return to a location variable which will still be needed after next time PolarProjection is called, it will cause problems (since that location is removed). It may be easier to just call RemoveLocation(udg_testLoc) in the end of every function that calls PolarProjection instead of inside the function itself. |
| 10-27-2003, 12:02 AM | #34 |
Has anybody considered that some of the 'leaked' memory may be for replays? I really have no idea how the format for replays works (i.e. if it's efficient and just tracks unit movement, etc.) but it occurred to me it's a possibility. Code:
function CreateLocation takes nothing returns location
local location a = Location(0, 0)
call RemoveLocation(a)
set a = null
return a
endfunctionPeppar said this doesn't leak. So why not add: Code:
function RemoveLocationNoLeak takes location whichLoc returns nothing
call RemoveLocation(whichLoc)
set whichLoc = null
endfunction? |
| 10-27-2003, 12:12 AM | #35 |
Data, I actually suspected it was the reply-cahce'ing that was making that map lagging up. Becouse the old theory was such that every time you run a trigger, it loads into memory/cache for the reply, so if you have crazy trigger-maps, then it'll take longer and longer to exit the game, and i really fell for it. But i think i/we know better then that now... that the exit time is becouse it's clearing out "leaked" memory out of the RAM. For example, that map i told about earlyer with that crazy 0.01 second periodic event trigger... It started lagging HEAVILY after an hour of play, and the exit-time was incredible, i instantly suspected the blasted replay-cache, But after reading this thread, alphabeta went on to try creating a different Polar-projection function, using udg/bj global variables (see above). And it amazes me that the exit lag is near to nothing, and the game doesn't leak/lag after some playtime at all. And it is still the same 0.01 trigger (btw, what this trigger does is do some intense polar-projecting and stuff). Cubasis |
| 10-27-2003, 12:59 AM | #36 |
... What do you think about my function? It seems causing no leaks... |
| 10-27-2003, 09:24 AM | #37 |
@dataangel: AFAIK you can't set parameters to other values. For the replay War3 does not need to store trigger stuff. All the trigger stuff is executed again when the replay is run. It mainly needs to store the orders humans give. To an extreme you can see that when you replace an AI script with a different one after you have stored a replay. The game will run totally different but human players will try to do the stuff they have done in the original game (which of course does not work good). I think our main hope is that Blizzard fixes this stupid bug. |
| 10-27-2003, 07:58 PM | #38 | |
Quote:
Why not doing it that way? Code:
function PolarProjectionNL takes location source, real dist, real angle returns nothing call MoveLocation(source, GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD), GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD)) endfunction |
| 10-27-2003, 09:35 PM | #39 | |
Quote:
I'm pretty sure you can. JASS should treat it just like other languages do -- change it for the scope of the function, unless it's a pointer (which I think a loc var is) in which case it genuinely changes it. I just compiled the function shown with no errors. Can someone test to see if it stops leaks? |
| 10-27-2003, 11:45 PM | #40 |
Hmm, Starcraftfreak, that is a interesting function there, i think it may work just perfectly, and be pretty smooth while at it. Cubasis |
| 10-27-2003, 11:57 PM | #41 |
The reason I dismissed the replay theory, is that replays are far, far too small to account for the memory footprint bloat. Even if the replays are stored in ram uncompressed, then compressed on saving I doubt they could take up a fraction of the memory WC3 leaks. |
| 10-28-2003, 04:53 AM | #42 | |
Quote:
|
| 10-28-2003, 08:18 PM | #43 |
Starcraftfreak: 1) My function moves existing location to new location and doesn't create additional handle. 2) Of course, function you have written is much more better. But I just copied original PolarProjectionBJ source to show the difference =) |
| 10-28-2003, 08:53 PM | #44 |
My function does the same as yours. I copied yours and removed the locals and put the code into the call statement (so everything is in one line and no locals which might leak are used). |
| 10-28-2003, 10:18 PM | #45 |
I know our functions are the same :) But yours is more optimized :) I hadn't optimized mine because I want to show exact difference between original and modified functions. Original one uses local 'x' & 'y' declarations! |