| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This change addresses the slight stutter and broken animation playback
when walking with the keyboard.
Once the end of the path has been reached but a movement key is still
held, the LocalPlayer now immediately calculates a new path rather than
waiting on the next logic update.
|
|
There was a slight stutter in being movement, since each time a being
reached the next position along its path, it would only continue to the
following position with the next logic tick.
Now the logic has been adjusted to keep moving until all the time for
the current frame was used up, or the path was exhausted.
A slight stutter remains for keyboard movement, as well as broken walk
animation playback, since it will only set a new path once the current
one is finished (see e554d9b2be1ec2fcb15065ae70151302adeef602).
Also simplified some logic in Viewport::draw and removed some obsolete
code in LocalPlayer::startWalking.
|
|
The logic update now uses Time::deltaTimeMs() where needed to make it
framerate-independent. This means there will no longer be multiple logic
calls per frame (as was usually the case with logic ticking at 100 fps
whereas the game would generally run at 60 fps).
At the same time, the game can be more precise at higher framerates and
should now run smoother at 144 Hz, for example. Previously the game would
sometimes skip logic ticks at that rate.
This change affects:
* Updating of animations
* Being movement speed
* More moving of manual time variables to Timer
Notoriously, the particle system still does 100 ticks/second.
|
|
The Timer is efficient because it does not depend on incrementing a
counter to keep track of time, nor does it call SDL_GetTicks every time
its state is checked (this happens once per frame instead).
Along with global functions Time::absoluteTimeMs() and
Time::deltaTimeMs(), this replaces previous globals tick_time, cur_time
and get_elapsed_time().
For now, there is still a fixed 100 times per second logic call rate,
but the new Time::deltaTimeMs() function should allow getting rid of
this.
|
|
Maybe it once had a use, but a change in the "Show own name" setting is
already handled by LocalPlayer::event.
|
|
Made the class and the code in general more readable by removing all
the needless getters and setters.
|
|
* Use default member initializers
* Use range-based for loops
* Avoid needless pointer references for ShopItem::mDuplicates
* Removed type aliases that are only used once or twice
* Removed more unused includes
* Removed some unused functions
* Removed superfluous .c_str()
* Rely on default copy and assignment operators for Vector class
* Use std::unique_ptr in some places
* Removed duplicated mPlayerMoney updating in SellDialog
* Removed duplicated Game::handleInput call
* Removed unused SDLInput::mMouseInWindow
* Removed remnant of manual widget positioning in HelpWindow
* Removed superfluous initialization of static pointers
|
|
|
|
* Use default member initializers
* Use range-based loops
* Don't use 'else' after 'return'
* Removed some unused includes
* Construct empty strings with std::string() instead of ""
* Clear strings with .clear() instead of assigning ""
* Check whether strings are empty with .empty() instead of comparing to ""
* Removed redundant initializations
|
|
Previous code was assuming there would be no gaps in the emote IDs.
Also cleaned up some confusion where the "emote ID" being passed around
in the code was often offset by 1. Now it is only offset in
communication with tmwAthena and when saving the shortcuts.
|
|
* Removing unused includes
* Use member initialization
* Use range-based for loops
* Use nullptr
* Removed no longer used aliases
* Use override
* Don't use else after return
* Use '= delete' to remove implicit members
* Use std::string::empty instead of comparing to ""
|
|
modernize-use-auto
modernize-use-nullptr
modernize-use-override
modernize-use-using
|
|
This was improperly done because of possible differences
in the actual victim position, due to server lag.
Spotted-by: cody
Reviewed-by: Thorbjørn Lindeijer
|
|
- Fixed the player attacking when clicking on a monster,
and then walking near using the keyboard.
- Fixed the walking glitch seen in tile path mode by letting
the character reach its nearest tile path node.
Reviewed-by: Thorbjørn Lindeijer
|
|
Ignore LocalPlayer::setDestination calls in this case, because it relies on the
tile size of the current map.
Reviewed-by: Erik Schilling
|
|
I first removed the keep attacking and pickup targetting unset
statements in the setdestination() function
since it was messing with all the rest of the logic,
and put those targetting logic where they belonged more.
I also changed the gotoTarget function to properly call the setTarget
function which permitted to properly unset the previous target
in that case.
I also finished the logic built around the mGoingToTarget member
(until then actually unused) to make it all work again.
At last, I also removed a now false comment
in the startWalking() function.
Reviewed-by: Erik Schilling
|
|
The direction is updated in those case only when the engine knows
it's the mouse requesting the destination.
Reviewed-by: Erik Schilling
|
|
I also made the range be taken from the server type
as for the pickup and npc talk ranges.
Last but no least, I fixed the parameters sent with
PGMSG_PICKUP to send the (item) position where to pickup at
as described in the manaserv protocol.
The pickup is still not 100% functional due certainly
to two problems:
1. The client item coordinates might not be the exact same as in the server.
2. The client seems to try to pick up the item a bit too soon,
probably for the reason given in 1.
I'll investigate this in another patch.
Reviewed-by: Thorbjørn Lindeijer, Erik Schilling.
|
|
Made the player's character look at where it is going
even when using the keyboard, by setting its direction
after getting the actual destination, and not before.
I also used the lookAt() function to avoid yet another
custom way of setting the direction.
Reviewed-by: Erik Schilling
|
|
The character used to stick to both corners of an obstacle it
encountered when walking diagonally.
Now it simply go back to the straight moving mode when
encountering an obstacle in one of the two direction used.
This also simplifies the function logic.
The character direction bug left is still there,
and will be dealt in a separate patch with.
Reviewed-by: Erik Schilling
|
|
It simply does the same thing, in better.
Reviewed-by: Erik Schilling
|
|
- Renamed mLastTarget to mLastTargetTime, and mLastAction to mLastActionTime
to clarify their use.
- NULL -> 0.
- Removed the unused mLocalWalkTime member.
+ Change requested by bjorn.
Reviewed-by: Thorjørn Lindeijer
|
|
|
|
+ Fixes from Bjorns review.
Reviewed-by: Bjorn.
|
|
The hurt sound volume was being played based on the distance in tiles,
even though Sound::playSfx was expecting pixels. This would cause
hurt sounds of other players to play too loud.
There were also several conversions between pixel and tile coordinates
that could be simplified.
Reviewed-by: Yohann Ferreira
|
|
The patch also takes care of not spamming the different servers,
when the servers are setting the being speed correctly.
The most problems were coming from the keyboard movement functions
handling 1 tile paths. To void the issues seen in #405, #439,
and #440, I simply prevented to set a new path before reaching
the destination of the former one, when using the keyboard.
The mouse path system remains unchanged.
I also made some functions private (or here protected)
to show they shouldn't be called by something else than
the localplayer object.
And I removed the nextTile() function, since it was obsolete,
unused, and replaced by the nextTile(direction) function.
That patch was tested on both servers with mouse/keyboard
mixed use.
Resolves: Mana-Mantis #405, #439, #440.
Reviewed-by: bjorn
|
|
This was an annoyance in long lasting battles.
Resolves: Mana-Mantis #445.
Rewiewed-by: Ablu, bjorn
|
|
Reviewed-by: Ablu
|
|
Conflicts:
src/localplayer.cpp
src/net/manaserv/beinghandler.cpp
src/net/manaserv/charhandler.cpp
|
|
This used to have an associated issue
but I just can't find it anymore.
Reviewed-by: Thorbjorn.
|
|
This also happened when trying to reach a monster.
I didn't fix the pick up once the destination is reached
as the fix will be a little more complex.
|
|
This used to have an issue but i just can't find it anymore.
|
|
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.
|
|
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.
|
|
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.
|
|
- Made the map teleport distance fixed for manaserv.
- Small cleanups.
The branch is considered reviewed by: Cody.
Resolves Mana-Mantis: #74.
|
|
Every files has been checked against the hard coded
32 values except the map.cpp file.
I also added convenience functions in the Game class,
centralized the default item icon size, and removed two
unused defines in being.cpp.
|
|
It already was, but now the the api is clear about it.
Client part of the mana issue: #363.
Reviewed-by: Bjorn.
|
|
Particles were being drawn with wrong positions due to their Z coordinate
being taken into account when sorting actors. Z is now only taken into account
when drawing them.
Reviewed-by: Bertram
|
|
Currently, we actually receive the local player attack speed
in milliseconds for tA.
Yet, we don't support receiving the attack speed for other beings,
so the old behaviour will remain for them until someone adds that.
As for Manaserv, we're only using the default speed atm.
Most urgent part of mana-mantis: #343.
Reviewed-by: Thorbjorn.
|
|
|
|
This is fixng many issues and (hopefully) will make the movement
rendering much smoother.
Merge branch 'master' of gitorious.org:~bertram/mana/mana-movement-code-merge
Conflicts:
src/being.cpp
src/net/manaserv/beinghandler.cpp
Resolves: TMW-Mantis #946.
Reviewed-by: Thorbjorn.
|
|
The new destination wasn't sent correctly since the destination
was centered but checked pixel exact afterward.
Now the destination check has been adapted for tile-wise
implementation, leading to an almost desync free movement.
Hurray!
|
|
1 action per second was annoyingly slow.
Reviewed-by: Thorbjørn Lindeijer
Reviewed-by: Yohann Ferreira
|
|
It's just an annoyance when it's only applied to a few classes. Either
we place everything in this namespace or nothing, and at the moment I
don't see any rationale for placing everything in a Mana namespace.
Acked-by: Jared Adams
|
|
Acked-by: Jared Adams
|
|
Acked-by: Jared Adams
|
|
The character picks up one item at a time (to remain kinda realistic)
and turns to the item picked up.
|
|
The attack range is still hardcoded for Manaserv as long
as generic equipment handling hasn't been implemented.
|
