Slick2D (LWJGL framework) - thoughts?

[Flet]

CS is currently using plain old Java AWT for rendering, which works but has limitations and ugliness.

I'm currently taking a look at migrating all rendering to use Slick2d instead. Slick2d (http://slick.cokeandcode.com/) is a framework built on top of LWJGL that is geared towards 2D games. The framework includes lots of boilerplate features that have been implemented by hand currently and could be swapped in.

Instead of working Bitmapand Bitmap[0][6], it uses Image and SpriteSheet.getSprite(0,6).

Moving to this framework will be a pretty large undertaking, but it opens up quite a few options for the future. I think its something that should be done sooner rather than later

I see that lwjgl is making its way into the code base via #853 "added alternative sound library Open Audio Library (OpenAL)"

Also, with the completion of #854 "Major refactoring of MojamComponent", moving will be a bit less painful as there is better separation of the main components (render/logic/keyboard etc).

I understand moving in this direction will be a huge effort and a lot of work will be needed, but I think its the right direction. So, any thoughts on this? Anyone want to join in my madness? :)

Some of the features of Slick2D: http://slick.cokeandcode.com/static.php?page=features

[Flet]

I also should mention that I have done a little bit of work locally to see if its feasible to migrate, and I have the title menu running at 3000FPS :)

[danielduner]

I think it is a good idea. But it should be possible to do the refactoring in steps, making the transition fairly painless.

Instead of directly removing the entire old system of bitmaps, you could start by rewriting the way that the Bitmaps are rendered to the screen:

public Screen(int w, int h) {
    super(w, h);
    image = new BufferedImage(w, h, BufferedImage.TYPE_INT_ARGB);
    pixels = ((DataBufferInt) image.getRaster().getDataBuffer()).getData();
}

You also have to take care not to directly use Slick2d methods all over the project (but rather use them via an interface, or something) so that we can implement #840

[master-lincoln]

in terms of performance, this is a necessary step...performance is pretty bad on linux netbook here. But I absolutely agree with @danielduner : To not have to rewrite the whole game we should start small by wrapping the slick2d stuff once more. If we get this stable we can start refactoring to use more of it's potential...

[Maescool]

agreed :) so.. i guess flet will start on this? (since @danielduner has to study!)

[danielduner]

sounds good to me :)

(Also:

Hebbian learning works better if the vectors x1 , . . . , xm and y1 , . . . , ym are pairwise orthogonal within their respective groups, because in that case the perturbation term becomes negligible

)

[kylecbrodie]

@Flet check out pull #870, Hopefully that abstraction will give you a good base. Let me know if something needs to be added as I'm adding the javadocs right now so I have it open

[Maescool]

about this, i've been looking into libgdx, looks like the perfect engine to use :)

[godleydemon]

Closing due to the new project at catacombsnatch/catacombsnatch on git that references the creation of catacomb snatch in libgdx