| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
| |
Previously, heroLoc wasn't a defensive copy of HeroEvent.getLocation(), it was HeroEvent.getLocation(). As of such, the condition that they were inequal always failed. However, a typo in the condition (leaving out the exclamation point) led us to believe it was working fine when in fact, AutomaticViewpoint was recalculating the viewpoint every tick instead of everytime the hero moves. Now it only refreshes when the hero moves or is moving.
Also cleared up an ambiguous comment in SpecialEvent's PanViewpoint's JavaDoc.
|
| |
|
|
| |
Implemented FixViewpoint(), PanViewpoint() and ResetViewpoint()
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Now, maps can be larger than (20,15) and the map will scroll as the hero walks across the middle. However, Southward and Eastward middle-traversing appears to warp reality just a little and there are a few kinks that need to be straightened out.
Map layer caching has also been added because the lower and upper layers of a map never change, so they are cached after the first rendering.
|
| |
|
|
| |
Replaced said condition with an instanceof check to see if toDraw.getGraphic() is an instance of BlankEventGraphic. The previous way requires BlankEventGraphic() to be instantated many times for no reason, thus wasting resources and causing other problems.
|
| |
|
|
| |
Replaced said condition with an instanceof check to see if toDraw.getGraphic() is an instance of BlankEventGraphic. The previous way did not, in fact, work because an EventGraphic never be equal to a String. This previous way only existed because HeroEvent's graphic used to be stored as a filename/offset combo instead of as an EventGraphic.
|
| |
|
|
| |
If an Event is adjacent to a Map boundary, then it could accidentally walk off the screen during the following circumstance: When a MoveEvent() action tells said Event to move off-screen while the Event is already moving, collision checking will be bypassed and the Event will proceed to walk off the screen, after which an Exception will be thrown when said Event attempts to move again. This bug has been fixed.
|
| |
|
|
| |
EventHandler controls when they are executed and allows MapViewGameState to poll it to see if it is currently managing any action threads. If it is, MapViewGameState should be able to prevent certain actions from occuring (unless the action thread is ParallelProcess) such as keyboard input.
|
| |
|
|
| |
As direction itself is always the same as moveDirection when moveDirection is needed, it will do fine without having to complicated access modifiers.
|
| |
|
|
| |
StepMoveEvent has an issue where an event could walk off the screen under its influence because it preformed no collision checking, due to the fact that the parent map had to be accessable to preform collision checking. Now, both event styles (unified with an AbstractEvent class that handles functions common to both styles) carries information about its parent map, provided by EventList which is in turn provided by the parent map itself.
|
| |
|
|
| |
startMoving() wasn't exactly a fit enough name for the method, so it was changed to nextMovement()
|
| |
|
|
| |
Previously, GameCharacter (HeroEvent's backend) stored it's graphic as a graphic/offset combination. However, the EventGraphic class is the correct way to store it.
|
| |
|
|
| |
Previously, Map's checkForCollision did not properly check collision and would allow an event to initiate movement to a location another event was already moving to (but wasn't at yet).
|
| | |
|
| | |
|
| | |
|
| |
|
