Slick Forums

Think this is worth pursuing further? I've got most things sorted out, but it still has a ways to go.

[Removed link. See first post for the lastest link.]

- Jon

Hallo Jon,
anonymous checkout is not working, but the zipped source is enough for me.
The physlick integration is attractive. Thanks for your help and the SlickSet.

Niels

SlickSet v0.2 is out.

I've decided to go fully with Phys2D integration, and this time around, it's really clean integration, and it actually let me eliminate some of my classes in lieu of those in Phys2D.

Grab everything you need in the first post including the library, source and Javadoc.

I'll update Space Invaders and Blockball to v0.2 later and will post up the source to the Platformer demo soon.

Here are my plans for SlickSet v0.3


No estimate on when this will come, but 2-3 weeks is a safe bet. This will be the first release that I'd seem safe for use.


SlickSet v0.4 and onwards will be more focused on the end-user side with further documentation in the form of tutorials as well as smaller tweaks to the API. And removing the 1.5 stuff I've been relying on.

That was quick. I updated Invaders and Blockball to conform to 0.2. Source for both is up in my first post.

I was pleasantly surprised at how little I had to do to make them work again and am happy to say that the API is still just as clean and easy to use as before.

This is what I think I'll do.

abstract class Effect
: private float x
: private float y
: private boolean paused
: public Effect(SlickObject parent, int xOffset, yOffset)
: public void pause()
: public void resume()
: public void update(int delta)
: public void render(Graphics g, float x, float y)
: public void remove()

Remove removes an Effect from its parent. It's common to add an effect that will remove itself after a duration of time.

There's a handle to the parent for all effects that have a direct effect on the parent. For example, a ShakeEffect would cause the parent to jitter around, or a ScaleEffect could cause the parent to grow bigger.

abstract class SlickObject()
: private ArrayList<Effect> frontEffects
: private ArrayList<Effect> backEffects
: public void addFrontEffect(Effect e)
: public void addBackEffect(Effect e)
: public void removeFrontEffect(Effect e)
: public void removeBackEffect(Effect e)
: public void removeAllEffects()
: public void update(StateBasedGame game, int delta)
: public void render(Graphics g)

Two lists of Effects, one for the back, and one for the front. This lets you draw effects behind the Object and in front.

How does this scheme sound?

This is amazing! Just what I needed for my G-java program, it is s a sort of Game maker port to java. As your slickset contains many of the stuff that gm has, actors are just objects in gm and I think a scene is just like a room. I can't thank you enough for this it will make my job much easier

More info:
http://en.wikipedia.org/wiki/G-java
http://www.g-java.com
http://www.gamemaker.nl

But anyway, do cameras actually do anything in the block example? I commented the code out and it didn't seem to change the game atall.

Is it possible to have more than one camera view on screen for example a split screen multiplayer game where each View shows a part of the scene? Can you please give an example if it is possible?

Thank you.

Hi,

I have a destructable terrain made by me directly with lwjgl binds and I use Slick for my characters.
Is there any chance to use the parallax feature with my map and a background layer and use the Camera feature to focus my Slick-made character?

Layer size = screen size in that game, so it has no effect to move it around.



I'll get back to you on this later. It's some surface tweaking to make this work.



This is standard usage. All you do is...

1) Create ParallaxLayer
2) Add an ImageLayer to it (this is your background image)
3) Set up Scene and add the ParallaxLayer to it.
4) Add a Camera to the Scene.
5) Every update, center the camera on the character.

Code below...

Thanks I will keep checking the topic for updates

I'm going to fix a bug that comes about when the screen size doesn't match the game size. For example, if you make a game that operates at different resolutions, this breaks on those, so I need to have you specify the original game size and disregard the screen size.

- Jon

My Effects have four methods, each implemented empty in the superclass: preUpdate, postUpdate, preRender and postRender. That way a single effect can paint stuff behind the Actor and in front of it. Usually I just override one of them, but well...

Even though most effects fall into an either/or situation, I like your idea better since it eliminates the need to maintain two separate lists, just a single ordered list.

- Jon

It might be just a single list but you might require to traverse it several times, right?
1. Traversal: call preUpdate() for all elements
2. Traversal: call postUpdate() for all elements
3. Traversal: call preRender() for all elements
4. Traversal: call postRender() for all elements.

4 * n calls.

Solution with two lists:

1. Traversal on preList: update() for all elements (x)
1. Traversal on postList: update() for all elements (n-x)
2. Traversal on preList: render() for all elements (x)
2. Traversal on postList: render() for all elements (n-x)

2 * n calls.

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap

Empirically, that's true, but if most elements either draw in front or in back, then they're really no different in practice unless the blank function calls represent an overhead (which I don't think they do).

I actually haven't implemented this part at all yet. I've been working entirely on Stencyl the past couple weeks and will only do maintenance work on this for the time being.

- Jon