Age | Commit message (Collapse) | Author | Files | Lines |
|
Their name is a bit more clear with DEBUG prefix rather than MAP
prefix. They're already scoped in the Map class anyway.
MAP_NORMAL was changed to DEBUG_NONE to represent no debug flags.
Acked-by: Bertram
|
|
* Use a symbol, VAR, instead of -1 for variable-length packets.
* Also change it's value to 1, so the length can be properly unsigned.
Note: A packet can't actually have length 1, since packet ID is 2 bytes.
* Use correct type (uint16_t) for packet id and length in more places.
* Avoid reading beyond the length of the array.
* Immediately parse variable length packets with length 4 (i.e. no body)
instead of waiting for another byte to arrive first.
Reviewed-by: Thorbjørn Lindeijer <thorbjorn@lindeijer.nl>
|
|
There was a bug here, which wouldn't surface if the copy was elided.
Fixed by using a move constructor.
Reviewed-by: Thorbjørn Lindeijer <thorbjorn@lindeijer.nl>
|
|
Reviewed-by: Thorbjørn Lindeijer <thorbjorn@lindeijer.nl>
|
|
It has been fixed and be made adapted
to the being movement speed.
Now, for instance, the client sends 3x times less move calls
to the tA server, and roughly 20x times for the Manaserv's one.
Resolves: Mana-Mantis #346.
Reviewed-by: o11c.
|
|
Their name is a bit more clear with DEBUG prefix rather than MAP
prefix. They're already scoped in the Map class anyway.
MAP_NORMAL was changed to DEBUG_NONE to represent no debug flags.
Acked-by: Bertram
|
|
|
|
Trivial.
|
|
This fixes overlay effects that are meant to scale with screen
resolution.
The problem was that the texture coordinates were not calculated
correctly. They were adjusted to the scaled size of the image, and when
scaling both the vertex and the texture coordinates, the image will
simply not appear scaled at all. Now the texture coordinates are
calculated based on the visible part of the original texture.
There was also a problem with the vertex coordinates, which were not
taking into account the visible part of the image.
TMW-Mantis-issue: 1047
|
|
Conflicts:
CMakeLists.txt
src/map.cpp
src/winver.h
|
|
This fixes overlay effects that are meant to scale with screen
resolution.
The problem was that the texture coordinates were not calculated
correctly. They were adjusted to the scaled size of the image, and when
scaling both the vertex and the texture coordinates, the image will
simply not appear scaled at all. Now the texture coordinates are
calculated based on the visible part of the original texture.
There was also a problem with the vertex coordinates, which were not
taking into account the visible part of the image.
TMW-Mantis-issue: 1047
Reviewed-by: Andrei Karas <akaras@inbox.ru>
|
|
The layer rendering code was not prepared to handle tiles that were
wider than the tile width of the map.
This commit also fixes the initialization of the maximum tile height,
which was based on the map height rather than the tile height. This
could slightly reduce overdraw for some maps.
Reviewed-by: Stefan Beller <stefanbeller@googlemail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This means that the order point of the sprites relative to the
particles is no longer the lowest point of the image but
instead a point which is approximately between the feet of
the characters.
The intent of the latest commits to treat sprites as perpendicular to the
ground instead of perpendicular to the view line is retained by this
approach.
I tested this with various particle effects and it results in exactly the
expected behavior. Note that this does NOT fix the current problems on TMW
with the snail slime effect, because the TMW content team accidently placed
this one 10px in the air. Sorry, garbage in, garbage out.
getDrawPixelY was re-renamed to getPixelY to be consistent with getPixelX,
while getPixelY was renamed to getDrawOrder, to make its purpose clear.
Further, particles are no longer drawn when behind other objects. This
is implemented by adding a drawnWhenBehind member function to Actor,
which currently returns true for everything except particles and compound-
sprites with more than one sub-sprites (the later case is consistent with
the previous behavior of them).
An exception are text particles which are excempt from this exception and
whose drawing order is also biased by 16 pixels south instead of north
to make them more visible.
Plus some minor changes from Bertram.
Reviewed-by: Bertram.
Resolves: Mana-Mantis #362.
|
|
This means that the order point of the sprites relative to the
particles is no longer the lowest point of the image but
instead a point which is approximately between the feet of
the characters.
The intent of the latest commits to treat sprites as perpendicular to the
ground instead of perpendicular to the view line is retained by this
approach.
I tested this with various particle effects and it results in exactly the
expected behavior. Note that this does NOT fix the current problems on TMW
with the snail slime effect, because the TMW content team accidently placed
this one 10px in the air. Sorry, garbage in, garbage out.
getDrawPixelY was re-renamed to getPixelY to be consistent with getPixelX,
while getPixelY was renamed to getDrawOrder, to make its purpose clear.
Further, particles are no longer drawn when behind other objects. This
is implemented by adding a drawnWhenBehind member function to Actor,
which currently returns true for everything except particles and compound-
sprites with more than one sub-sprites (the later case is consistent with
the previous behavior of them).
An exception are text particles which are excempt from this exception and
whose drawing order is also biased by 16 pixels south instead of north
to make them more visible.
Plus some minor changes from Bertram.
Reviewed-by: Bertram.
Resolves: Mana-Mantis #362.
|
|
|
|
|
|
A <box> sub tag was added to the <slot> tag with a x and y
parameter to do so.
|
|
I disabled the drop from equipment window since it was more
simple to implement, and because it seemed useless or even bad
for the user experience to me.
|
|
|
|
|
|
|
|
|
|
|
|
Keeping the windows within the visible area is expected behavior, no
matter for how long it has been broken. It makes little sense to warn
about expected behavior.
|
|
Keeping the windows within the visible area is expected behavior, no
matter for how long it has been broken. It makes little sense to warn
about expected behavior.
|
|
Now the itempopup is also telling what equip slot
is under the mouse pointer.
|
|
I also made the number of slots displayed
taken from the equip.xml file for manaserv.
|
|
|
|
|
|
is equipped or not.
It will be used quite soon to visually see the slot names.
|
|
git://gitorious.org/~bertram/mana/mana-equipment-fix into equipment-fix
|
|
|
|
|
|
|
|
This a good example of use for the new graphics and button
functionalities.
|
|
This to avoid cluttering the gui until Crush has the time
to fulfill his issue about those.
|
|
This is not updated once the keys are reassigned but it will
do the trick for now.
|
|
I had to adapt a bit the images given by Poison ivy
to do that.
|
|
And falls back to the text based caption otherwise.
|
|
|
|
I also made the client able to keep the old behaviour,
and i changed the button api to not require the icon frames size
as it could easily guess them.
|
|
I added a use of it to the menu buttons.
|
|
It has been fixed and be made adapted
to the being movement speed.
Now, for instance, the client sends 3x times less move calls
to the tA server, and roughly 20x times for the Manaserv's one.
Resolves: Mana-Mantis #346.
|