| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Because the coordinates and transparent color previously used were tuned for the default System file, the coordinates were changed to be more forgiving and the color is picked from the last pixel of the first row from the graphic.
Also, for some reason, every file in source control has been marked as modified, even though most haven't been. Don't know why this happened.
|
| |
|
|
|
|
|
|
| |
Also implemented opposite(), left() and right() functions for Direction which return the opposite, counterclockwise and clockwise directions respectively. I don't exactly like the current Direction implementation as it's not very elegant. Hopefully there is a way to make this prettier.
Also added a setter to PossibleEvent that allows LayerEvent to notify it when it starts or stops moving. This is necessary because the TurnLeft and TurnRight AnimationTypes constantly attempt to rotate the Event and if the Direction of the Event is changed while it is moving, it will move to a different space and animation will look strange. Thus, setDirection() has been modified so it will disallow direction change if the Event is moving.
Also fixed a small encapsulation bug in AbstractEvent. PossibleEvent's notification of movement was made possible through the overriding of the setMoving() function, which is used by AbstractEvent to set if the Event is currently moving. However, while it used setMoving() to turn on moving, previously it did not use it to turn off moving, it simply modified the field. This has been fixed.
|
| |
|
|
|
|
|
|
| |
Also fixed two bugs:
1. In the condition where a StepMoveEvent is called upon an Event whose animation type does not allow them to turn in the desired direction, they will move in the direction they are already in and walk off the screen while doing so. This was fixed by checking (after the event's direction has been set during the startMoving() process) that the event was able to face in the correct direction.
2. If a StepMoveEvent was enacted on an event that was already moving, it would be skipped. This has been fixed by waiting for the desired event to complete moving at the start of MoveEventThread.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
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.
|
| |
|
|
| |
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.
|
