| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Identified by FindBugs. http://findbugs.sourceforge.net/
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Previously, MoveEventThread used a CountDownLatch to power it's moveAll() function. However, because CountDownLatch can only count down and not back up, every time a MoveEventThread was spawned, it's static moveEventWait (which was a CountDownLatch) would be re-instantated. If a thread was already waiting on the CountDownLatch, it would be disrupted.
This meant that if the first MoveEventThread spawned completed before the rest, the entire program would grind to a halt.
This has been fixed by replacing the CountDownLatch with a Semaphore (not exactly what Semaphore is supposed to be used for, but it works). Every time a MoveEventThread is spawned, it acquires a permit from the Semaphone and releases it when it completes. moveAll() then attempts to acquire 100 permits (the Semaphore is initalized to only allow 100 permits), which blocks until all MoveEventThreads have completed. The downside of this is that only 100 MoveEventThreads can execute at once, but it is exceptionally unlikely that such an event will occur. Also, if this does occur, the other MoveEventThreads will simply wait for another to complete and then acquire a permit.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
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).
|
| | |
|
| | |
|
| |
|
