Kurosu a écrit :
> Matthieu Fertré a écrit :
>
>> So, in my opinion, the detection of duplicated rectangles must be done
>> in Map::OptimizeCache(). Methods Map::ToRedrawOnScreen() and
>> Map::ToRedrawOnMap() should stay silly methods.
>>
>
> I think that on the other hand, as long as Map
Hello,
Kyle a écrit :
> With this known now, I believe it is possible to simply change
> CompareRectangles such that it returns false if the rectangles are
> equal, thus fixing the "weak" part of the requirement. Since it is very
This is worth investiguating indeed. Please refer to my reply to
Hello,
Matthieu Fertré a écrit :
> I'm not sure it's always possible to remove the duplicates. It should be
> possible if on each layer (4 layers: sky, wind particles, ground, all
> other objects), 2 objects of the same size can not be at a same position
> => collisions between all objects of a
Matthieu Fertré wrote:
> So, in my opinion, the detection of duplicated rectangles must be done
> in Map::OptimizeCache(). Methods Map::ToRedrawOnScreen() and
> Map::ToRedrawOnMap() should stay silly methods.
This follows from where I have found the assertions to come from, inside
OptimizeCache
Kurosu a écrit :
> Kurosu a écrit :
>> Maybe this cache is storing twice something.
>
> Yes, this is what happens. I have found at least 3 such risky situations.
>
> I've added something to track duplicated entries in
> Map::ToRedrawOnScreen. It has spotted the following contexts when this
> dupl
Kurosu a écrit :
Maybe this cache is storing twice something.
Yes, this is what happens. I have found at least 3 such risky situations.
I've added something to track duplicated entries in
Map::ToRedrawOnScreen. It has spotted the following contexts when this
duplicate insertion occurs:
1) Ga
Hello,
Kyle a écrit :
> Yay! .8 final is that much closer! These three other problems are big,
Some could just be glitches that someone else may not be able to reproduce.
> any ideas (the asserts are in optimizeCache, whenever it tries to access
> a list, including list.begin(). The actual ass
Julien PUYDT a écrit :
> Kurosu a écrit :
>
>> 1) over the 3 heterogeneous network games I did, a player always landed
>> on a mine; not unplayable, but strangely repetitive
>>
>
> Both player and mine are certainly randomly placed -- I would say the
> random function is broken and either
Kurosu a écrit :
> 1) over the 3 heterogeneous network games I did, a player always landed
> on a mine; not unplayable, but strangely repetitive
Both player and mine are certainly randomly placed -- I would say the
random function is broken and either gives the same position for both,
or gives m
Kurosu wrote:
> Network game is now able to start, but there are a number of bugs making
> it a bit unplayable:
> 1) over the 3 heterogeneous network games I did, a player always landed
> on a mine; not unplayable, but strangely repetitive
> 2) After first shot, end of turn does not seem to be seen
Matthieu Fertré a écrit :
>> One thing I have noticed is that RAND_MAX is defined
>> differently on Windows (MSVC) and Linux. This would affect a lot of
>> things in RandomSync I believe, and might explain some bugs.
>>
>> kyle
>>
>
> Method double RandomSync::GetDouble() must return a numbe
> One thing I have noticed is that RAND_MAX is defined
> differently on Windows (MSVC) and Linux. This would affect a lot of
> things in RandomSync I believe, and might explain some bugs.
>
> kyle
>
Method double RandomSync::GetDouble() must return a number between 0.0
and 1.0, and this me
Matthieu Fertré wrote:
>> 3. Character placement fails because the client is always placing the
>> character in the ground. The only reasons I can see for this happening
>> is if either the random values are messed up or if what is considered
>> ground is messed up. When debugging this, it shows
> 3. Character placement fails because the client is always placing the
> character in the ground. The only reasons I can see for this happening
> is if either the random values are messed up or if what is considered
> ground is messed up. When debugging this, it shows that it is trying
> posi
[EMAIL PROTECTED] a écrit :
> can't attach a patch nor commit right now, so I'll just explain. Action::Push
> has a weird way to do the memcpy, using &tmp instead of tmp. The same was
Fix in svn as of r3002. Not yet tested if it improves anything.
___
W
I'm replying through a webmail, so please bear with me.
Quoting Kyle <[EMAIL PROTECTED]>:
> 1. The Linux host runs fine, the Windows client crashes with an empty
> random table. This is because it is unable to place its characters on
> the map, and uses up all 1024 random numbers in the table tryi
16 matches
Mail list logo
