| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
There are two bugs left I'll take care about in the near future:
- Items dealing with more than one slot capacity
are only showing on the first equip slot.
- The unequip button doesn't get updated when clicking
on the equipped item.
A client design limitation known:
- The client still don't handle correctly items applied on more
than one item type at equip time.
|
|
The password is salted by a random number sent by server.
Reviewed by Bertram.
|
|
Also documented a TODO.
|
|
I added the //xgettext:no-c-format comment because
gettext was wrongly guessing the no-c type of those strings.
Nicely suggested by Byakushin a lot of time ago.
|
|
|
|
Part of issue #343.
|
|
|
|
|
