summary refs log tree commit diff stats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Implemented SlideTransitionStarla Insigna2009-02-066-3/+159
|
* Fixed SaveFile I/O closing forgetnessStarla Insigna2009-02-051-2/+1
|
* Fixed Transition processingStarla Insigna2009-02-053-19/+50
|
* Added Executor to MoveEventThreadStarla Insigna2009-02-033-16/+21
|
* Started working on new TransitionsStarla Insigna2009-02-0314-154/+299
| | | | The old transition implementation was old and patchy. The new one is planned to be extensible and to work properly with all transitions. Currently this is not so, but with work it hopefully will be.
* Fixed [Gotez06] InterruptedException violationStarla Insigna2009-02-036-38/+18
|
* Fixed MoveEventThread latch breakageStarla Insigna2009-02-031-16/+16
| | | | | | | | 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.
* Added support for OnHeroTouch eventsStarla Insigna2009-02-034-2/+47
| | | | | | | | 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.
* Added JavaDoc to many classesStarla Insigna2009-02-0218-34/+39
|
* Added LoopUntilCollisionMoveEventStarla Insigna2009-02-022-8/+41
| | | | LoopUntilCollisionMoveEvent repeats an array of MoveEvents until the event in question collides with something. This is done by comparing the location of the event before and after the actions. It is a replacement for the deprecated CycleUpDownMovementType and CycleLeftRightMovementType.
* Added tiled ChipSet supportStarla Insigna2009-02-022-25/+106
| | | | Replaced previous chipset management (manual via a Java class) with "tiled" ChipSets. However, this support will be removed once a proper map editor/chipset editor is created for FourPuzzle.
* Fixed AutomaticViewpoint cache issueStarla Insigna2009-01-302-7/+8
| | | | | | 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 viewpoint-related Event actionsStarla Insigna2009-01-307-4/+218
| | | | Implemented FixViewpoint(), PanViewpoint() and ResetViewpoint()
* Created ViewpointStarla Insigna2009-01-304-51/+121
|
* Fixed scrolling issuesStarla Insigna2009-01-301-11/+20
|
* Added viewpoint scrollingStarla Insigna2009-01-305-53/+118
| | | | | | 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.
* Fixed LayerEvent rendering condition bugStarla Insigna2009-01-281-7/+1
| | | | 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.
* Fixed HeroEvent rendering condition bugStarla Insigna2009-01-281-10/+2
| | | | 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.
* Fixed off-screen bugStarla Insigna2009-01-286-11/+28
| | | | 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.
* Created a manager for SpecialEvent action threadsStarla Insigna2009-01-285-6/+95
| | | | 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.
* Removed the moveDirection field from AbstractEventStarla Insigna2009-01-284-54/+45
| | | | As direction itself is always the same as moveDirection when moveDirection is needed, it will do fine without having to complicated access modifiers.
* Added parentMap data to EventStarla Insigna2009-01-277-182/+195
| | | | 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.
* Renamed MovementType's startMoving()Starla Insigna2009-01-275-6/+5
| | | | startMoving() wasn't exactly a fit enough name for the method, so it was changed to nextMovement()
* Converted GameCharacter's graphic store methodStarla Insigna2009-01-272-18/+9
| | | | 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.
* Fixed "walk-thru-me" bugStarla Insigna2009-01-279-43/+133
| | | | 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).
* Replaced checked exceptions with RuntimeExceptionStarla Insigna2009-01-2443-194/+320
|
* Extended GameCharacters from ArrayListStarla Insigna2009-01-244-47/+37
|
* Fixed MoveEvent bugStarla Insigna2009-01-198-48/+147
|
* Imported sourcesStarla Insigna2009-01-1753-0/+3218
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-27 07:59:51 +0000