weimingtom / gtge Goto Github PK

Many graphics-based objects in the GTGE framework use double precision.  
This is bad, because doubles have many problems for graphics:

1.  Graphics are normally drawn as an array of pixels, using matrix 
notation.  Although some graphics may pretend to let you draw at (double, 
double), usually it just simply casts those doubles to ints, as Sprite's 
render(Graphics2D) method does.  There is no such thing as one half or one 
tenth of a pixel!

2.  Collisions are also using doubles, without a delta.  A delta specifies 
how much precision you don't care about.  But since collisions happen on a 
graphics-context where pixels (whole values) are drawn, doubles don't make 
sense.  Furthermore, without a delta, you may get this:

double firstPosition = 3.0000000001

double secondPosition = 2.999999997

These two would collide in an integer context (they would be equal to 3), 
but since doubles lack precision like that, they end up not registering as 
a collision.  Doubles suffer from precision issues, especially during 
complex calculations (such as the "pixel-perfect" collision calculation).

I recommend anything using doubles that need to be either drawn or 
calculated be switched to ints if it does not make sense to have the 
double values available.  If double values are needed, BigDecimal should 
be used to keep track of precision instead.

As it is currently coded, GameLoader is extremely brittle and the functionality 
it is designed to provide is obscured by the additional functionality it has 
inherited from both AppletMode and Applet.  Once the GameLoader has been 
renamed to AppletGameLoader, and a second GameLoader is created to provide for 
FullScreenMode/WindowedMode loading, the interface that combines both loaders 
should be made clear.  Recode both loaders to implement this documented 
interface.

I finally had some time to browse through the code. I found many 
occurrences of not encapsulated attributes, like

    public BaseGraphics bsGraphics;

in the Game-class. That goes against pretty much everthing I have learned 
about object-oriented design.

I even saw some package-visibilities:

    GameFont fpsFont;


Plus, many attributes are private. That limits the extensibility of the 
library, as inheriting classes cannot access needed fields of the base-
class. I already ran into that problem when I tried to subclass the sprite 
class.

So here is my proposal: let's change that! I would propose to mainly allow 
two sorts of access:

protected - for the vast majority of attributes.
private - for some attributes that are only used for the inner workings of 
the class itself, with no possible need in subclasses.

And only if really needed:
package - for some rare special cases. This should be explained in detail 
in the comments.
public - only for static final attributes.

And of course, we will have to add a ton of getters/setters (all public).

I think I don't have to explain the advantages of encapsulation, so the 
upside of this should be clear. The downside, however, are some API-
changes. Instead of calling game.bsGraphics you should have to call 
game.getBsGraphics().

I am willing to do this, but first I'd like to know what you think.

hey guys,
english isn't my first language and im not a proffesional in java so 
please correct me if im wrong at something.

my problem:
If you have a sprite of type AdvanceSprite with a animationframe which is 
longer than the getImages() array, and you use a subclass of 
PreciseCollisionGroup or lower to check collisions, you will get a 
IndexOutOfBounds exeption in case of a collision.

Found out why: In the isCollided method, the method getImage() is invoked. 
This is the one in AnimatedSprite. It returns the image at the index equal 
to getFrame() in the imagearray so when getFrame() > getImages().length 
the exeption is thrown and getFrame() will be so when you want to repeat a 
image in your animation.

This is a bug because its impossible to repeat images in a animation more 
than 1 time because of it, even while this is the case in the example 
given in the description of isCollided.

i found a work around by chanceing the imagefile I use for the animation 
but you guys might want to check it out. if it mended to be so, please 
explain it to me what im doing wrong.

greetings, peter

ps: uploading .java files of my game on demand if you want.

Cleares txtMessage Box after sending Message

The WindowExitListener class extends from Object currently, and implements 
java.awt.event.WindowListener, but most of the methods in this class are empty. 
 Because it extends Object, this class can be adapted to extend 
java.awt.event.WindowAdapter, which provides the blank methods, and therefore 
the WindowExitListener's functionality will be better exposed by showcasing the 
actual method (windowClosing) it implements.

The FPSCounter class should invoke refresh() upon construction, or simply 
set the lastCount private variable to equal System.currentTimeMillis().

Otherwise, the first call to calculateFPS() will store 1 to be returned as 
the program's FPS for the first counting.  Subsequent calls will be 
accurate.

This may affect games which log the FPS via AOP to use as a debugging 
tool, but this issue is of low priority.

The Background and CollisionRect classes both provide a weakly-accessible x and 
y variable that has at least a getter.  Encapsulate these so that they exist 
only in a single class.  For any new methods, add the final modifier to prevent 
overriding for getters and setters - existing getters and setters must stay 
as-is so that existing code can compile cleanly.

The ImageFont class should simply store a map of characters to images.  The 
height and width of each character will be based on their images.  The GameFont 
interface will be adapted to support checking for the height of a single 
character and of a String.  In this fashion the limit of 256 characters imposed 
by BitmapFont will also be lifted.

Timer Class, revision: r25

As the Timer class uses 'long' internally for the private field 'delay' the
parameter 'delay' in the constructor should be a long, too. 

See also: http://goldenstudios.or.id/forum/showthread.php?tid=2168

Currently, BaseInput contains multiple listeners and uses a queue to store 
input events.

Advanced users, however, may find that they want to code their own listeners 
directly without using BaseInput.

Make this easier to do, by making BaseInput an optional initialized engine, and 
allowing a hook for all Game objects to place any input listeners on the main 
component as appropriate.

Game and GameObject both share similar methods, but are not unified.  In 
reality, the GameObject class is useless, if GameObject had the ability to be 
expressed via an interface.  Implement this interface and attach it to both the 
Game and GameObject class.  This interface may be named Game, GameObject or 
something else.  This interface is what should be referenced inside GTGE itself 
- NOT the Game or GameObject classes.  Once this refactoring is done, the 
GameObject class should be deprecated.  Game itself may need to be renamed to 
BaseGame depending on what the interface is called.

The GameLoader class should not extend the Applet nor the AppletMode class.  
Instead, a new class should be created, in the com.golden.gamedev.loader 
package, called AppletGameLoader that provides this functionality.  When 
complete, GameLoader should be wiped clean of code and extend this class, and 
become deprecated, as it will then be deleted in 0.2.5.

I feel GTGE needs more support for Tile Backgrounds.

Currently it only supports a single layer Tile Background.
Many games require more than this.  For example, platformers like Sonic, RPG's 
like Zelda, or Pokemon.  Because of how many users I've seen in the past year 
or so asking about Tile Backgrounds, I don't believe this is too specific for 
an all purpose 2D game engine.

A multiple layer background backed by arrays would be a good start, but a 
hierarchy of classes related to Tile Backgrounds in good ole' OOP fashion would 
be even nicer.

I propose "AdvancedMultiLayerTileBackground" for the background itself.
"TileLayer" for a wrapper class for each layer.
"Tile" a wrapper for each tile.
"Tileset" a wrapper for arrays of tiles.

The height and width variables in the CollisionRect and Sprite classes need to 
be encapsulated and deprecated - they will not be able to be accessed directly 
after 0.2.4.  Any new accessor or mutator should use the final modifier to 
prevent subclasses from overriding a simple setter or getter.

com.golden.gamedev.engine.BaseIO.class

public URL getURL(String path, int mode) {
...
case WORKING_DIRECTORY:
                    File f = new File(path);
                    if (f.exists()) {
                        url = f.toURL(); //error
                    }
                    break;
...

}

public InputStream getStream(String path, int mode) {
....
case WORKING_DIRECTORY:
                    stream = new File(path).toURL().openStream(); //error
                    break;
....
}

f.toURL(); and 
File(path).toURL().openStream(); depricated in jre 7 and up 

get error in Fedora 16

need to use f.toURI().toURL(); and File(path.)toURI().toURL().openStream();

and there window of size 0 x 0 pixel...

and there is no applet support in fedora 16, should have extended JFrame

When opening an applet game when the browser is on the second monitor, it
crashes and gives me this error.

Game Exception on com.golden.gamedev.GameLoader
-----------------------------------------------
java.lang.IllegalArgumentException: adding a container to a container on a
different GraphicsDevice
    at java.awt.Component.checkGD(Unknown Source)
    at java.awt.Container.addImpl(Unknown Source)
    at java.awt.Container.add(Unknown Source)
    at com.golden.gamedev.engine.graphics.AppletMode.start(Unknown Source)
    at com.golden.gamedev.GameLoader.start(Unknown Source)
    at sun.applet.AppletPanel.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

Game Environment
----------------
Date/Time         : Fri, 18 Jul 2008 at 15:12
Java Version      : 1.6.0_02-b06 Sun Microsystems Inc.
GTGE Version      : 0.2.3
java.lang.StackOverflowError

The current GTGE code has warnings.  Eliminate them.

As described here the JOGL support is completly broken when uing a modern
JOGL version.

http://www.goldenstudios.or.id/forum/showthread.php?tid=1929

The packages are referenced false. I allready tryed fixing that, but as i
progressed correcting imports i noticed that GTGE even accesses classes
that are not exsistant within JOGL anymore. As i don't have much experiance
with JOGL someone experienced should try to fix this issue.

ImageUtil currently does not have a method to easily convert a source image to 
another image with the same colors but a different transparency value.  This 
enhancement request asks that this method be added.

The suggested method signature is as follows:
RenderedImage/WritableRenderedImage* 
createTransparentImage(RenderedImage/WritableRenderedImage* source, short 
transparency);

* It is not known at this time which interface/abstract type can be used here.  
It may be sufficient to have a RenderedImage instance, or perhaps 
WritableRenderedImage must be used.

The use case of this is as follows.  Note that this method shouldn't be 
specific to BufferedImage - more image types not specifically extending 
BufferedImage should be allowed if possible*

BufferedImage source = // .. the source image comes from somewhere.
BufferedImage destination = source;
if(// some condition means we need transparency adjustment) {
     destination = (BufferedImage) ImageUtil.createTransparentImage(source, (short) transparency);
}

Note also that, depending on the interface that is ultimately used, this method 
may have to use a side-effect to alter the image - that is, the source instance 
may be altered as a result of this call.  The exact method of operation of this 
method is unknown at this time.

The WindowExitListener seems to not be needed.  There are four places it 
is used:

public GameSettings(URL splashImage): the removal of the 
this.addWindowListener(WindowExitListener.getInstance()); method does not 
appear to hinder functionality.

Both FullScreenMode and WindowedMode use it, but they will still probably 
terminate if they do not have this listener (I need to verify this, but it 
will probably act like the GameSettings class does and exit the 
application upon close anyways).  

Furthermore, GameLoader removes the listeners set into the FullScreenMode 
and WindowedMode in the setup method.

I would be happy to see some new 2D graphics features in GTGE. Firts of 
all I would like use primitive (circle, rectangles,...) drawing with 
openGL support (LWJGL and JOGL). 
Next missing feature is sprite scaling. I think this is already 
implemented, but still doesn't work on openGL mode. 
There are also a lot of features unimplemented in GTGE add-on in class 
NullGraphics.java. 

The GameEngine class requires a GameObject implementation.  While the 
GameObject implementation is the easiest to use, and should continue to be 
supported in tutorials, etc, creating an interface that the GameEngine 
relies upon (and having the GameObject implement it) will separate this 
out (which will also allow Game objects to be plugged into the GameEngine 
if needed later).

My suggestion for the interface name is GameEngineAddable


public interface GameEngineAddable {
    public void addGameEngine(GameEngine parent);
}

The GameObject class would implement this, and its constructor would 
delegate to this method. 

I use GTGE source from trunk, revision 49.

I faced this issue when tried to use ParalaxBackground with viewport on the 
center of the screen. I have my own panels on the left and on the top of the 
screen.

I used setClip() for setting viewport. With ImageBackground all worked fine, 
but when I replaced ImageBackground with ParalaxBackground, then part of my 
background went under the panels, and position of my sprites on the background 
had been broken.

I started to investigate this problem and found out that ParallaxBackground 
class does not override Background's method setClip(). As a result children 
backgrounds know nothing about viewport.

What steps will reproduce the problem?
1. Create a game that sleeps for three seconds in the update(long) method.
2. Execute more than 20 keypresses during this three seconds.


The problem is that the internal counter on the 20-sized array is only 
reset on refresh or update.  Update is called fairly regularly, but if the 
AWTInput class is to be used outside of the GTGE framework, not knowing 
this restriction of resetting via these two methods (or doing some weird 
threading like the above) may cause an index-out-of-bounds exception.

The easiest way to solve this problem is to abstract the array out to a 
list, allowing implementors to get and set it as a property, but setting 
it internally to a new ArrayList.  This would also allow for not using an 
index as well as the array, for clearing the list would be very easy using 
ArrayList.clear();. 

As described here:

http://www.goldenstudios.or.id/forum/showthread.php?tid=1929

there is a slight but very annoying drawing inconsistence between GTGE
Software and LWJGL Hardware rendering.

It should be checked i GTGE or LWJGL AddOn wrapper is doing wrong here and
then fix.

I have not localized the error yet.

Currently, it is possible to disable the FPS counter, but there does not appear 
to be any easy way to move its position.  Add an easy way to move the FPS 
counter's output.

BaseInput currently has no means of handling mouse wheel events.  Add this to 
BaseInput.

What steps will reproduce the problem?
1. creat a bitmap font with transparency
2. load that font using:

gameFont=(AdvanceBitmapFont)GameFontManager.getFont(ImageUtil.getImage(String,Tr
ansparency.Translucent),String);

3. draw it with :

gameFont.drawString(g, String, x, y);


What is the expected output? What do you see instead?
   Expect: text with semitransparency
   Get:text without semitransparency

What version of the product are you using? On what operating system?

GTGE_0_2_3.jar

Please provide any additional information below.

none

The VolatileSprite class is normally used once and only once.  Normally, 
users will use a SpriteGroup to control sprites and remove inactive ones.  
However, if multiple VolatileSprites are needed (such as a shooting game), 
this may not be the best approach (VolatileSprites may need to have a 
different pooling mechanism, etc).

I propose adding the following method to the VolatileSprite class:

/**
  * Restores a <tt>VolatileSprite</tt> instance so that it will be rendered
  * again.
  */
public void restoreSprite() {
    this.setFrame(getStartAnimationFrame());
    this.setAnimate(true);
    this.setActive(true);
}

This will prevent users from simply making their own ad-hoc restore method 
in a subclass that might just exist for this purpose.