| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
svn-id: r55818
|
|
svn-id: r54385
|
|
svn-id: r53738
|
|
svn-id: r50519
|
|
svn-id: r50409
|
|
svn-id: r50408
|
|
slash: switch between the last held item and normal mouse
comma, period: replace the currently held item with the previous/next item in the inventory
Also, commented a bit better what happens when ESCAPE is present with respect to map
programs and cut-scenes.
svn-id: r50407
|
|
This is the behavior of the original player. It is not necessary to click on
the hero.
svn-id: r50361
|
|
svn-id: r48722
|
|
svn-id: r48615
|
|
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
|
|
Inventory".
This patch corrects the valgrind fault, but may not be the ultimate fix.
This should be reviewed before backport to v1.1.0 branch.
svn-id: r48434
|
|
svn-id: r47541
|
|
svn-id: r47215
|
|
svn-id: r46326
|
|
svn-id: r46320
|
|
without it (at least with Symbian OS GCCE 3.4.3 and CW 2)
svn-id: r46213
|
|
It seems that the mouse was simply on the below line and triggered the switch
to the map without the user realizing.
svn-id: r46171
|
|
Last commit moved it below, but that cancelled GPL2 programs run right
after loading the game.
svn-id: r46099
|
|
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
|
|
Now only a long-term (complete rewrite) TODO is left in the code, but nothing
urgent to solve.
svn-id: r46097
|
|
(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
|
|
Now the game seems fully playable with crazy loading all the time, even
though it is a hacky solution. Updated the TODOs
svn-id: r46094
|
|
svn-id: r46070
|
|
I have thoroughly documented why this hack is needed and added ideas how to
fix it properly.
svn-id: r46068
|
|
(otherwise the relative animation would repeat itself unhandled until the
hero disappears from the screen.)
svn-id: r46058
|
|
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
|
|
svn-id: r46044
|
|
svn-id: r45876
|
|
svn-id: r45872
|
|
svn-id: r45855
|
|
svn-id: r45851
|
|
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
|
|
The old comments were completely misleading although the algorithm was good.
svn-id: r45824
|
|
svn-id: r45823
|
|
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
|
|
svn-id: r45764
|
|
Also, named correctly GPL2 parameter types.
This fixes all FIXMEs
svn-id: r45762
|
