The previous bugfix just hid the problem by removing an assert, but it might demonstrate
itself in another way later. This is a proper bugfix.
svn-id: r48460
I have tested that this could only possibly happen when the game has been
loaded with last location being the map. Then pressing Escape calls
enterNewRoom() and this superfluous optimization takes place. It is harmless
to simply reload the map. After having removed it, enterNewRoom() needs not
return any return value, because the test at the tail can be done by the
caller. I have then restructured the code a little to make it cleaner.
svn-id: r46098
(otherwise we could have in our hands an unreachable object). This works
thanks to moving clearing _currentItem into putItem(), which gets called
in inventoryReload().
svn-id: r46096
Verified that we really do not need object animations even if they are in
a different location, and clearing them thus regardless of their location.
Although the game was not crashing due to previous work-arounds at this
moment, this cleanup obliterates the most horrible hack and makes sure
animations will never get stale.
svn-id: r46095
With the previous code, the position of the animation was doubled (due to
counting the position twice, the second time being a relative shift), which
put it mostly outside the screen. This is because one-time hero animations
are actually stored using absolute coordinates.
svn-id: r46057
This simplifies a lot of code calling run(). Also, scripts called from the
inventory are now called with disabled mouse and title, as desired.
svn-id: r45848
Putting items back to the inventory into clipped coordinates, and exiting
running GPL2 programs when the game engine it to be interrupted.
svn-id: r45822
Replaced IDs of objects by pointers, which saves many lookups, each of which
is horribly ineffective. Moved a lot of code into methods of structs now
turned into objects.
Tested the new code a lot and seems to work as well as the old code.
svn-id: r45799
This fixes the previous bugfix, which causes that I could not re-run the same
program (e.g., by repeatedly clicking on the hollow tree) if the hero did not
move at least one pixel.
svn-id: r45747
Adjusting to the edge is done such that it respects slight sideways movements of the dragon.
Fixed rounding issues in the whole game. Improved debug messages. Made sure that the dragon
does not turn like crazy around when clicking on the same pixel: the final point is always the
clicked one although the middle points made by shifted to make the animations smooth, and
preserve the dragons direction if he has not walked.
There is a bug with running turning animations as they seem to disappear for 1 frame and have
incorrect Z coordinate. Will investigate it next.
svn-id: r45742
In these animations, each sprite can specify a relative shift with respect
to the previous sprite. Moving animations (such as walking of the dragon)
are easily described in this framework. I have sort of hacked their support
and it seems to work.
The current walking code does not interact with the new code yet, but it will
be easy to do.
svn-id: r45712
- SIGSEGV by not stopping walking when changing rooms
- reset of the mouse cursor and object title during gate scripts
- updating the previous animation phase, also when starting new animation
- swapped up and down animations
svn-id: r45690
The hero does not walk yet (it still teleports to the target immediately),
but that is just because the actual walking algorithm is left trivial first.
However, the main game loop, callbacks, and waiting all already work with
the general framework.
svn-id: r45648
