Slick2D Wiki - User contributions [en-gb]

Embedding Mozilla Rhino

2018-05-09T18:33:36Z

Decerez: Undo revision 560 by Abc123456 ([[User talk:Abc123456|talk vandalism

Scripting engines have started to become very popular game development tools. They allow developers to make changes to game logic without needing to recompile, or possibly even restart, the game.

This tutorial describes the steps needed to get start using the Mozilla Rhino Javascript engine in your Slick-based games.

== Getting Rhino ==

The obvious first step is to [https://developer.mozilla.org/en-US/docs/Rhino get the Rhino distribution]. Unpack the zip file and place the js.jar file in your project. Make sure to add it to your classpath and double check your build setup to be sure the jar file is included when your program is compiled and run.

== Running Rhino and Slick together ==

The following program is a simple implementation of Rhino running inside a Slick game. It is pretty well commented, and should explain the necessary steps as they happen.

<pre>
/*
This file demonstrates using the Rhino Javascript engine within the
Slick 2d game engine.

Rhino can be found at: http://www.mozilla.org/rhino/
Slick can be found at: http://slick.cokeandcode.com/
*/

import org.newdawn.slick.AppGameContainer;
import org.newdawn.slick.BasicGame;
import org.newdawn.slick.GameContainer;
import org.newdawn.slick.Graphics;
import org.newdawn.slick.Input;
import org.newdawn.slick.SlickException;

import org.mozilla.javascript.Context;
import org.mozilla.javascript.ScriptableObject;

public class Rhino extends BasicGame {

/*
The ScriptProxy class defined here is one half of the interface
between Java code and the Javascript environment. It is used to,
among other things, provide access to Java objects within Rhino.

The ScriptableObject class implements the majority of the
Scriptable interface. The Scriptable interface is used to define
functions and objects that will be available to the javascript
environment.
*/
class ScriptProxy extends ScriptableObject {
String test1;

/*
This is the only method required to fully implement the
abstract class ScriptableObject. I'm not sure what it is
supposed to do. The "global" value is used in at least one
example in the Rhino documentation.
*/
public String getClassName() {
return "global";
}

/*
Access to the "test" object in the javascript environment is
implemented through calls to the setTest and getTest
methods.
*/
public void setTest(String str) {
test1 = str;
}

public String getTest() {
return test1;
}

/*
A test function that can be called within the JavaScript
environment.
*/
public void testfunc(String s) {
// System.out.println("test function called");
System.out.println(s);
}
}

/*
A Context is an instance of the javascript environment. The
context is used to load and interpret .js files and interpret
Javascript code as strings, among other things. In this example
it is used exclusively to interpret Javascript strings.
*/
protected Context scriptContext;
protected ScriptProxy gameProxy;

public void init(GameContainer container) throws SlickException {
/*
The static method Context.enter is, apparently, the easiest
way to obtain a javascript environment.
*/
scriptContext = Context.enter();
gameProxy = new ScriptProxy();

/*
We'll set a string for the "test" property that will be
exposed in Javascript now so we know it is calling across
the bridge.
*/
gameProxy.setTest("This was set within java, but called from javascript.");

/*
This must be called before scripts can be evaluated in this
Context. It creates some of the basic Javascript objects.
*/
scriptContext.initStandardObjects(gameProxy);

/*
Functions provided by a ScriptableObject (such as our
example 'testfunc') are initialized in the following manner.
*/
String[] scriptAvailableFunctions = { "testfunc" };
gameProxy.defineFunctionProperties(scriptAvailableFunctions, ScriptProxy.class, ScriptableObject.DONTENUM);

/*
A "property" is a Javascript object that is exposed through
getters and setters in the ScriptableObject. Rhino
automatically prepends the "set" and "get" terms and
uppercases the first letter, so exact naming is important.
*/
gameProxy.defineProperty("test", ScriptProxy.class, ScriptableObject.DONTENUM);

}

public void render(GameContainer container, Graphics g) {
/*
Here we are using the context (javascript engine) to
evaluate a string. The first parameter is our
ScriptableObject, which is used to provide definitions for
the engine. The second argument is the code to be evaluated.
In this case simply writing "test" evaluates the Javascript
object named "test", which is looked up in our gameProxy,
which passed the result of it's getTest() method to the
Javascript engine.

Since this is the only instruction in the string to be
evaluated it is used as the return value for
evaluateString. To provide flexibility in return type
handling evaluateString returns a java.lang.Object, which is
why the result must be cast back into a String.

The third parameter is a string that describes the source
for the Javascript code being evaluated. This may be a
filename if that is where the string comes from.

The fourth parameter is the starting line number for this
script, which might be useful if a script is being pieced
together from a variety of components.

The last parameter is used to provide a security domain for
the script to run under. I *think* this is used to ensure
that the Javascript code cannot execute certain methods or
instantiate some objects, but haven't done enough research
to be sure. Passing a null value here does not restrict the
evaluation of Javascript code.
*/
String result = (String) scriptContext.evaluateString(gameProxy, "test;", "js", 1, null);
g.drawString("Javascript result: " + result, 40, 120);

}

public void update(GameContainer container, int delta) {

}

public void keyPressed(int key, char c) {
if(key == Input.KEY_ESCAPE) {
/*
The script context will most likely be shut down
properly, but it's a good idea to be neat and tidy,
right?
*/
scriptContext.exit();
System.exit(0);
}
if(key == Input.KEY_SPACE) {
/*
This example is largely similar to the above, except
that now we are calling the javascript function
"testfunc()". This is found and executed on gameProxy,
printing a string to the console."
*/
scriptContext.evaluateString(gameProxy, "testfunc(\"testing console output\");", "js", 5, null);
}
}

public Rhino(String s) {
super(s);
}

public static void main(String[] Args) {
try {
AppGameContainer container = new AppGameContainer(new Rhino("Rhino"));
container.setDisplayMode(600,480,false);
// container.setShowFPS(false);
container.setMinimumLogicUpdateInterval(30);
container.start();
} catch (SlickException e) {
e.printStackTrace();
}
}
}
</pre>

== Next Steps ==

The next step to consider from here is how the Javascript code handles game logic updates. One simple option is to create a Javascript function named tick that your game calls every time update() runs. This in turn calls all of the functions that need to be run in Javascript on every game update.

One obvious step to take from this point is to extend the access of the Javascript environment into your game. You don't need to use an inner class to implement your ScriptableObject, and could easily have it in another file. If you already have a scene graph it probably has quite a few methods for interacting with your game environment, which might make it a good idea to turn this into a ScriptableObject and make it available to the Javascript engine.

Since the ScriptableObject we are using also stores all of the definitions that are in scope, a second ScriptableObject can be created for a user interaction console. This allows you to expose only very specific parts of the game to the user and prevent them from directly modifying the underlying game.

== Hot Loading Definitions ==

One interesting use for the Javascript environment is being able to modify the game logic as the game is running. This is remarkably easy to set up. We can create a command-line input prompt that runs with the game by declaring a boolean consolePrinted member variable and adding the following code to the update method:

<pre>
if(!consolePrinted) {
System.out.print("rhino> ");
consolePrinted = true;
}
// Only parse input strings when the input buffer is empty so we
// don't block the game loop.
if(System.in.available() != 0) {
byte[] b = new byte[System.in.available()];
System.in.read(b);
String s = new String(b);
gameProxy.setTest(s);
consolePrinted = false;
}
</pre>

This example simply alter the test property in Javascript, but we could just as easily be executing the string directly as Javascript or using it to provide a simple command system for reloading Javascript files.

[[Category:Miscellaneous]]

Overview

2018-05-09T18:32:38Z

Decerez: Undo revision 530 by Abc123456 (talk) vandalism

Slick2D is a simple set of tools wrapped around the [http://lwjgl.org/ LWJGL] OpenGL binding for Java. It's aims are as follows:
* Provide a simple 2D API
* Make transition from Java2D to OpenGL easier
* Enable distribution via WebStart without the complexity
* Provide the tools required for most simple games out of the box
* Extensible framework for flexibility
* Mix and Match - you use what you want, nothing is enforced.
* Help with rendering, sound, input, collision and anything else we can think of.

Here are some things we're explicitly not doing and why:
* Abstracting the rendering method (i.e. Java2D or OpenGL). With the advent of LWJGL Applets, it's a waste of time and just makes things more complicated.
* Take over your development - where would the fun be if the library just forced you to do everything it's way?
* Fix everything - there will always be challenges in games development.
* Move to 3D eventually.

Check out the [[Getting Started]] guide to start your journey into slick-smooth Java game development!

[[Category:Tutorials]]

Resource Loading

2018-05-09T18:30:45Z

Decerez: Undo revision 554 by Abc123456 (talk) Restoring page

When referencing resources ([[images]], [[SpriteSheet|spritesheets]], fonts, sounds etc.) the underlying class will use the ResourceManager to find the resource and obtain an input stream to it.

The resource manager first tries to look the resource up using the classpath. Putting your resources in the classpath is generally the best way to work since it makes transitioning to deployment (webstart and/or applets) much easier - since the classpath is present at testing and at deployment. Note that the context class loader is used which ensure that at deployment what ever the framework being used for deployment is can specify an appropriate class loader to obtain resources.

If the resource manager is unable to locate the resoruce within the classpath it will attempt to use the reference provided as a file name relative to the current directory. This is sometimes useful during testing. It is also possible to deploy while still being dependent on direct file reference (maybe using an installer and keeping files unjarred) but this is not recommended.

Finally if the resource manager can not locate the resource it will report an error which may stop initialisation. It is possible that resource location can fail but still the resource can remain valid and so a resource simply not being located is not always a reason to stop init.

== See Also ==
* [[Deferred Resource Loading]]

[[Category:Resources]]

Images

2018-05-09T18:30:03Z

Decerez: Undo revision 523 by Abc123456 (talk) Restored page state from bot spam

Images are the most primitive drawing tool within Slick. They are the root of most of utilities for rendering. Each image will draw a rectangular area on the screen filled with some pixels based on either a generated source (see [[ImageBuffer]]) or a image loaded from disk.

Slick currently uses java's ImageIO to load images so supports, PNG, GIF and JPG. It also supports TGA through a pure java loader which is generally much faster than using ImageIO. However, the TGA must be non-compressed and 32 bit to be loaded correctly. Note that of course resources are generally placed in JAR files and as such TGA compresses down in this context in a similar magnitude to PNG.

As with most things in Slick images are currently rendered in the simplest manner possible, using OpenGL immediate mode. This is not the most efficient manner and hence this is subject to change at a later date (should a need arise).

Note that fonts, sprite sheets and particles all rely on the basic image class. It's also worth remember that any given texture (or external image) is loaded only once and hence no caching is required on the developers side. This also means that sub-images and references to the original data so memory is not duplicated. As a side effects images are considered non-mutable - i.e. they can not be changed - which may have invalidated another references rendering.

== Loading Images ==

To load an image, you only need to make a simple object initialization call, where the Slick Engine will do most of the preparation for you.

Example:

<pre>Image img = new Image("res/myimage.png");</pre>

The image can either be in the classpath (for webstart) or on the file system (for local testing).

== Rendering ==

Rendering images that have been loaded can be just as simple as loading them into your program. Simply call the 'draw' method in your 'render' method as so:

<pre>img.draw(x, y);</pre>

This will render your image at the specified X and Y coordinates of the GameContainer's graphics.

== Image Filtering ==

Though rendering your image may seem simple enough, sometimes there can be strange outcomes to what is shown on screen, in comparison to the actual picture you are trying to load. One point of interest is the image's filter setting. If you wish to scale your image without a blurring effect (read: Linear Filtering; causes textures to blend colors in the magnification process), you will need to use the 'Nearest' filter setting. This can come in handy when working with pixel-style art games, as it retains the color of the actual image being used by using the nearest pixel to the expanded sector.

Enabling 'Linear' Filtering: (Example of 16x16 scaled at 4f with Linear Filtering: http://i.imgur.com/Iw6gPQr.png)

<pre>
Image img = new Image("res/myimage.png");
img.setFilter(Image.FILTER_LINEAR);
</pre>

Enabling 'Nearest' Filtering: (Example of 16x16 scaled at 4f with Nearest Filtering: http://i.imgur.com/0yHRMWy.png)

<pre>
Image img = new Image("res/myimage.png");
img.setFilter(Image.FILTER_NEAREST);
</pre>

== See Also ==
* [[Resource Loading]]

[[Category:Images]] [[Category:Graphics]]

Graphics

2018-05-09T18:29:32Z

Decerez: Undo revision 540 by Abc123456 (talk) Restored page from spam

Slick2D supplies several ways to draw images on your screen:
* [[Images]]
* [[Animation]]

~And more~

Hello World

2018-05-09T18:28:10Z

Decerez: Undo revision 531 by Abc123456 (talk) Restored Page from spam

To make sure your setup succeeded, create a main class like the following:
<pre>
package simpleslickgame;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.newdawn.slick.AppGameContainer;
import org.newdawn.slick.BasicGame;
import org.newdawn.slick.GameContainer;
import org.newdawn.slick.Graphics;
import org.newdawn.slick.SlickException;

public class SimpleSlickGame extends BasicGame
{
public SimpleSlickGame(String gamename)
{
super(gamename);
}

@Override
public void init(GameContainer gc) throws SlickException {}

@Override
public void update(GameContainer gc, int i) throws SlickException {}

@Override
public void render(GameContainer gc, Graphics g) throws SlickException
{
g.drawString("Howdy!", 10, 10);
}

public static void main(String[] args)
{
try
{
AppGameContainer appgc;
appgc = new AppGameContainer(new SimpleSlickGame("Simple Slick Game"));
appgc.setDisplayMode(640, 480, false);
appgc.start();
}
catch (SlickException ex)
{
Logger.getLogger(SimpleSlickGame.class.getName()).log(Level.SEVERE, null, ex);
}
}
}
</pre>

If a window opens saying 'Howdy!', your setup is fully configured and ready for development.

[[Category:Tutorials]]

Elevate Fitness Goals With Beyond Yoga Apparel

2018-05-09T18:27:05Z

Decerez: Removing self advertisement

-REMOVED-

Loading libraries and natives from path

2018-05-09T18:25:39Z

Decerez: Undo revision 561 by Abc123456 (talk)

==Introduction==
Some of you may want to load the libraries and natives needed for slick from a custom path or directory.
This is useful when you don't want your users to type in additional parameters for starting your program.
Working with additional parameters can - more often than not - bring about errors and/or reports of bugs.

To avoid these problems, you can follow this tutorial.

==Filestructure==
In this section you will see the structure which we will use for this example.

<YourDirectory>
├── libs
│ ├── lwjgl.jar
│ ├── slick.jar
│   └── natives
│      ├── libjinput-linux.so
│      ├── libjinput-linux64.so
│      ├── liblwjgl.so
│      ├── liblwjgl64.so
│      ├── libopenal.so
│      └── libopenal64.so
└── YourProgram.jar

For this example the libraries used are the minimum for a Slick programm which are:
* lwjgl.jar
* slick.jar

The natives libraries which are used are the natives for linux:
* libjinput-linux.so
* libjinput-linux64.so
* liblwjgl.so
* liblwjgl64.so
* libopenal.so
* libopenal64.so

The native libraries with the 64 at the end of the file-name are those needed for 64 Bit Linux and those without are for 32 Bit systems.

You may also put the natives for Windows (.dll) and Mac (.dylib / .jnilib) to be platform independent.

==Adding the code==
It is very important to add the following lines of code at the beginning of your "public static void main(String[] args)"-method because the libraries need to be loaded before you use them!

The first line of code you have to add is the one setting your "java.library.path". This is the path where your libraries are. In our scenario the path of the libraries is "libs". So our code will look like this:
System.setProperty("java.library.path", "libs");
This will tell java to use the relative path to the directory libs for loading the libraries. You may also use absolute paths here.

The second and last line you have to add is the one saying lwjgl where the native libraries are.
//Extracted from [http://www.lwjgl.org/wiki/index.php?title=Distributing_Your_LWJGL_Application Distributing Your LWJGL Application]
System.setProperty("org.lwjgl.librarypath", new File("libs/natives").getAbsolutePath());
This line of code tells lwjgl that the native libraries are located in the directory with the relative path "libs/natives".
The "File" used here is only for getting the absolute path to our natives directory because the parameter "org.lwjgl.librarypath" does only support absolute paths.

==Finished sourcecode==
The following code shows how your source code should look like when you're done with this tutorial:
public static void main(String[] args) {
System.setProperty("java.library.path", "libs");

//Extracted from [http://www.lwjgl.org/wiki/index.php?title=Distributing_Your_LWJGL_Application Distributing Your LWJGL Application]
System.setProperty("org.lwjgl.librarypath", new File("libs/natives").getAbsolutePath());

//Your sourcecode for starting the display
}

[[Category:Tutorials]]

Game Containers

2018-05-09T18:25:13Z

Decerez: Undo revision 559 by Abc123456 (talk)

The concept of containers isn't a particularly new one, the container provides environment in which your application (in this case a game) can run. It provides that game with a set of facilities and expects the game to comply to a certain interface. This allows the container (sometimes called the framework) to handle most of the bits of code common between all games for you - leaving you to focus on the important game logic bits and pieces.

== Basic Functionality ==

In the case of Slick, the container holds a Game - that is the class that is contained must comply to the Game interface. To make things even easier Slick provides a basic abstract implementation of Game which you can simply extend, called BasicGame. When extending BasicGame you'll need to implement 3 methods:

'''init()''' - This is called when the game starts and should be used to load resources and initialise the game state.

'''render()''' - This method is passed a graphics content which can be used to draw to the screen. All of your game's rendering should take place in this method (or in methods called from this method)

'''update()''' - The method is called each game loop to cause your game to update it's logic. So if you have a little guy flying across the screen this is where you should make him move. This is also where you should check input and change the state of the game.

The GameContainer itself provides methods to control the properties of the game rendering and update. For instance, the game container is where you look for controlling what resolution the game runs at and whether it's in fullscreen mode. It's also responsible for maintaining the game timer and loop. There are a couple of implementations of GameContainer currently available (discussed below), however where possible you should rely on the GameContainer interface - apart from of course when constructing your container where you are making an explicit decision about how your game is to be displayed.

While the Slick game container framework is useful it doesn't suit everyone. It is intended that the features of Slick can be used outside of the framework as part of a generic LWJGL game.

== Application Game Container ==

The application game container is the most used, it's intended to run your game stand alone or as a webstart. It uses a simple window to display the game and allows you to configure the display mode directly. It's generally constructed in main and started with the following lines:

<pre>
try {
AppGameContainer container = new AppGameContainer(new MyGame());
container.setDisplayMode(800,600,false);
container.start();
} catch (SlickException e) {
e.printStackTrace();
}
</pre>

Where the 800 and 600 specify the window resolution and the false (or true) specify whether the game should be run in fullscreen mode. Note how the container is created with an instance of the game implementation. In this way when you change containers the game itself does not need to be changed at all. This makes it very easy to make a demo version of your game available via a webpage while mainitaining the full version as a standalone application.

== Applet Game Container ==

The applet game container uses the recently added LWJGL Applet support to present the game as a Java Applet embedded into a webpage. This functionality is currently still being tested and developed. It is known to have issues running within Opera and on low end machines. Supporting an OpenGL context within a browser window is proving to be difficult to be make stable in all cases.

However, for most people this is a great option and allows you deploy your game as an applet with the minimal of fuss. The Slick distribution provides the files required for applet distribution in the “applet” directory. To use your game in the applet you need to specify something similar to the following in the applet tag in the HTML:

<pre>
<applet code="org.newdawn.slick.AppletGameContainer" archive="slick.jar,testdata.jar,lwjgl_applet.jar,lwjgl.jar,lwjgl_util_applet.jar,natives.jar,jinput.jar"
width="640" height="480">
<param name="game" value="org.newdawn.slick.tests.InputTest">
</applet>
</pre>

Where the game parameters is replaced with the fully qualified name of your Game class and the archive list contains all the jars you require signed with an appropriate certificate. See the webstart tutorial for details on how to produce a certificate and sign the the JARs correctly.

== Future Game Containers ==

There are currently no other containers in development, although there are plans for a container that uses a AWT Canvas to display the game. This would allow tools developers the ability to embedded the games (and application displays) into other GUIs, much like the Pedigree Particle Editor.

Developing a game container is resonably simple by extending the standard GameContainer class and adding the part specific to the particular rendering context. If something about the game containers provided doesn't fit with the way you usually write games it's often easiest to simply create a new game container that does exactly what you want rather than attempt to fit in with existing implementations.

[[Category:Graphics]]