Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 May 2012
Offline Last Active Apr 07 2014 05:14 AM

#4953722 Java Graphics.drawImage seems to leak memory..?

Posted by on 28 June 2012 - 11:49 AM

Java2D Graphics does some caching of the transformed and rendered images, e.g. if you transform/scale them, to increase the UI update speed. Perhaps it is this caching that you notice. Is the increased memory a problem for you? If you only want a "raw" rendering of an image, pixel-for-pixel, perhaps you should not use Java 2D (Graphics2, and JComponent decendents such as JPanel), and instead use e.g. Canvas ("heavy-weight" UI component in the java.awt package).

#4950508 Structure of classes in good Game Engine?

Posted by on 19 June 2012 - 01:33 AM

Interesting discussion to follow as a Java developer. Are the logging conventions in C++ really that diverse? For Java there is almost a de-facto standard for logging, and in all the cases I've seen it used it's simply through a static member in each class, e.g.:

public class StdPlayerCreator implements PlayerCreator {
    public static final Logger LOG = Logger.getLogger(StdPlayerCreator.class);

    LOG.error("Internal error, failed to find a settlement");

The parameter to getLogger() is effectively just a hierarchical label. It allows you to configure the logging output threshold on a class or package hierarchy. (This configuration is in a separate XML.)

Yes the above would break if multiple "runs" which should have distinct logs are run in the same JVM (java process). However that is rare and the logger can be instantiated differently for such use cases.

(Sorry for the tangential comment... ;-) )

#4948812 Algorithm for an object that follows another object, with acceleration.

Posted by on 13 June 2012 - 07:45 AM

To make this smooth and realistic in terms of acceleration, it's not sufficient to calculate a trajectory only on the distance between the objects, the trick is to arrive / get close to the target object while simultaneously achieving the same velocity as the target.

I wrote here earlier about a solution for this in 3D. (The principle is the same in 2D.) The solution uses the chasing vessel's/object's acceleration capability and doesn't require any 'damping' or similar to achieve a realistic effect. It might be overkill for your requirements but it gives an optimal and smooth trajectory. The code should be straight-forward to adapt to 2D. If you're interested you can find the solution here:


#4944581 Gathering updates before transmitting across network

Posted by on 30 May 2012 - 01:06 AM

The main rationale for a separate client session host component is actually scaling. In this MMO the client IO is by far the most resource intensive process, and with this architecture the session host machines can be added according to demand (and they don't have any persistent state so they're more-or-less hot-swappable, the affected players will just need to login again).

Each session host does cache the up-to-date physical universe state with which it can serve all its players (so clients' ad-hoc data requests don't affect the core server). It doesn't "require" per-client cache - but there actually is a small one to facilitate the reducing of the data transmitted to the client (enables keeping track of which data (that is visible to the client) that has been modified).

#4944132 Gathering updates before transmitting across network

Posted by on 28 May 2012 - 02:36 PM

In the MMOG I'm working on there is a distinct update data feed for each client, since the server is authoritative on all simulation and on what the client/player is able to see. This is done in a two-step process:
1) The simulation engine feeds the client session host with updated game world state.
2) The session host then feeds each client with the player's filtered view of the game world.

This architecture also decouples the simulation engine from the client IO component, and it is fairly straight-forward for the latter to both support global data throttling in case of high server load and individual client data throttling depending on connection quality and data congestion.

The attibute updates accumulate at the session host, so only the most-recent attribute updates are sent to each client.