summary refs log tree commit diff stats
path: root/src/com/fourisland
Commit message (Collapse)AuthorAgeFilesLines
* Engine: Refactored retieval of FontMetricsStarla Insigna2009-02-143-16/+27
|
* Engine: Compacted MessageWindowStarla Insigna2009-02-142-13/+22
| | | | | | MessageWindow is now shorter, and more compact. The font size has also been decreased to allow for more text. Closes #5
* Engine: Added basic FaceSet supportStarla Insigna2009-02-143-10/+97
| | | | Refs #5
* Engine: Added chipset data to RTPStarla Insigna2009-02-143-14/+4833
|
* Engine: Fixed arrow delay bugStarla Insigna2009-02-131-1/+1
| | | | The arrow used to take a while to appear (in MessageWindow) because the message window iterated over all the text, instead of just the visible text.
* Engine: Compacted ChoiceWindowStarla Insigna2009-02-121-2/+0
|
* Engine: Fixed up JavaDocStarla Insigna2009-02-128-52/+48
|
* Engine: Wrote Message SystemStarla Insigna2009-02-128-56/+203
| | | | | | | | MessageWindow now has a static method run by SpecialEvent that triggers the message box. This method blocks until the message is complete and renders via Display's new feature. The message box also now features the "next" arrow and the letters gradually appear. Display has also been re-worked to have a list of a new interface called Renderable, which is any object that can be rendered. Such objects (such as MessageWindow) can register to Display, which will render them onto the game frame after the GameState has been rendered. Closes #5.
* Engine: Rewrote IntervalStarla Insigna2009-02-122-7/+7
| | | | | | Interval previously used milliseconds, but now it uses nanoseconds (which, according to System, is more accurate). Fixes #11
* Engine: Rewrote Map abstractionStarla Insigna2009-02-124-41/+60
| | | | Instead of requiring users to extend Map, all that is required now is the creation of a Map object, which should then be configured and added to the Database via Database.addMap()
* Engine: Optimized ObjectLoaderStarla Insigna2009-02-111-22/+22
| | | | Split ObjectLoader's objectCache into three caches: imageCache (BufferedImage), musicCache (Sequence) and soundCache (Clip). This way, each resource type has its own section and no time-consuming casting is necessary.
* Engine: Added global fontStarla Insigna2009-02-118-53/+71
| | | | | | | | Converted RM2K's RMG2000.fon to a TrueType font using some long and difficult processes (involving first converting to a .bdf, then to a .ttf). With this standard font included in the package, there will be no worry of strange fonts, as TrueType is a standard. Also, probably because of the size of the new font, the white-tail bug has disappeared. This seems rickety, but because this is the only font that should be used, it should be ok. And if the problem ever arises again, the ticket can be reopened. Fixes #6 and #1.
* Engine: Changed default TitleScreenStarla Insigna2009-02-103-4/+7
| | | | Replaced default TitleScreen (which was the TPOAHT Title Screen for testing reasons) with a FourPuzzle Title Screen. Also moved the Title Menu to the bottom-left corner.
* Engine: Added some control to MusicStarla Insigna2009-02-105-9/+93
| | | | MapViewGameState now plays music depending on the variables of its Map, which can tell it to either stop the music, keep the previous music playing or start playing a specified music.
* Engine: Removed Music starting delayStarla Insigna2009-02-103-0/+91
| | | | | | This annoying bug was finally removed by creating a seperate MidiParser class that takes a Sequence and parses out the non-emitting messages. This is run in ObjectLoader so the result is cached. Fixes #3
* Engine: Tweaked Window background positioningStarla Insigna2009-02-102-4/+9
| | | | Refs #5
* Engine: Refactored SystemGraphic transparencyStarla Insigna2009-02-104-24/+65
| | | | | | Previously, every time a transparent section of SystemGraphic had to be rendered, it would be to be fed through Toolkit, FilteredImageSource, TransparentImageFilter and converted from a BufferedImage to an Image to a BufferedImage again. This has been replaced (and optimized) by preforming this when the SystemGraphic is loaded into memory, instead of every time it is used. Refs #5
* Re-implemented DatabaseStarla Insigna2009-02-0915-118/+316
| | | | See #8
* Added Decision2 soundStarla Insigna2009-02-083-1/+3
| | | | This sound should be played when the player selects something from the TitleScreen, opens the Menu and other choice sounding places.
* Added an RTPStarla Insigna2009-02-089-24/+27
|
* Started MessageWindowStarla Insigna2009-02-084-2/+153
| | | | Currently, MessageWindow splits a string into four lines and displays it when necessary. However, there is currently no way to close the window, it does not animate upon opening and more.
* Tweaked Window graphic valuesStarla Insigna2009-02-082-8/+7
|
* Fixed Window Selector background alignmentStarla Insigna2009-02-082-2/+3
| | | | In ChoiceWindow, the background picture for the Selector windows wasn't positioned correctly.
* Added flickering to Selector windowStarla Insigna2009-02-081-6/+27
|
* Add choice choosing to ChoiceWindowStarla Insigna2009-02-086-110/+253
| | | | ChoiceWindow has also been modified around to rely on a Window class which makes the process more elegant (not elegant, just more so than before). TitleScreenGameState has also been modified to close the game when "End" is selected.
* Added Sound Effect supportStarla Insigna2009-02-082-0/+80
|
* Added support for other System filesStarla Insigna2009-02-0870-16/+38
| | | | | | 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.
* Added text centering to ChoiceWindowStarla Insigna2009-02-082-4/+11
|
* Implemented a basic ChoiceWindowStarla Insigna2009-02-086-0/+260
| | | | This window should be used when there are a few choices available (such as in TitleScreenGameState and MenuGameState) and one needs to be chosen. The implementation currently is bad, the code is messy and it could be optimized. Plus, there are a few bugs in it and no choice can currently be made, only the rendering has been done.
* Added TurnLeft and TurnRight AnimationTypesStarla Insigna2009-02-076-26/+133
| | | | | | | | 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.
* Added tick-processing to AnimationTypeStarla Insigna2009-02-077-51/+88
| | | | AnimationType is designed to assert some control over a PossibleEvent's Direction and AnimationStep. Previously, it could only allow or disallow the changing of one or both of those fields. Now, certain AnimationTypes (specifically CommonWithStepping, TurnLeft and TurnRight) can modify those fields as well every tick.
* Removed unnessecary functions from PossibleEventStarla Insigna2009-02-071-38/+8
|
* Protected PossibleEventStarla Insigna2009-02-073-55/+124
| | | | Package-privated most functions (except for addPrecondition() which should be used by clients) because clients shouldn't have access to them. Also implemented the Builder pattern so clients can create PossibleEvents, but not modify them, making PossibleEvent effectively immutable (to clients), though it actually isn't because it can be modified by classes within the package.
* Implemented all AnimationTypesStarla Insigna2009-02-075-41/+92
|
* Fixed Event layer rendering glitchStarla Insigna2009-02-071-2/+14
|
* Fixed transparent image in ObjectLoaderStarla Insigna2009-02-073-64/+4
|
* Fixed a transition problemStarla Insigna2009-02-074-4/+17
|
* Started DatabaseStarla Insigna2009-02-0711-13/+142
|
* 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.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-22 08:34:01 +0000