Why was it important to get LWJGL into central?
Well, one of the biggest pains when using maven is having your dependencies available from central, if they are, you just need to add a little snippet of XML and you are done, if they aren’t, then you need to install them manually to your local repo or to a private maven repo.
This is a problem in itself but this also means that projects that depend on something that isn’t available in central, can’t get into central themselves, making the work needed to use it grow exponentially.
Now that we got LWJGL into maven central, we can start thinking about trying to convince the authors of other useful libs that use LWJGL like Slick2D, libGDX, nifty-gui, etc to make their libs also available on central (of course we would love to help make this a reality as well).
If you use LWJGL with maven, we would love to hear from you and feel free to ask us anything.
Even though our main objective remains making money, we also love to write interesting posts and make all our work open source. Some people told us they liked our work and wanted to support it by making donations.
We don’t expect being able to live from donations, but they could help a lot to cover the ongoing costs that we have like server (svn, git, build server, etc), hosting (blog). They would even help us invest in other stuff like paying for art, sounds, or other interesting stuff that would help us improve our games and our chances in creating a successful game studio.
If you are interested in helping us by making a donation we added a Paypal donation button on the sidebar, we will be forever grateful and will continue trying to provide interesting content and useful tools for other developers.
Since the beginning of times (of Gemserk), I had one or more local projects where I could test stuff related to the libraries we were using (Slick2D, LibGDX, Artemis), graphical effects, game ideas or just algorithms. One example is the lighting bolt effect I talked about in a previous post, I have also made some videos of some other tests but never uploaded the code.
As these kind of prototypes could be useful for other developers we have started a new project named prototypes (yeah, super creative name) where we (at least I) are going to add some of the new tests and prototypes we make.
Hope you like it.
I keep making prototypes about what I talk in the previous post, in this case I made an example of how to interact between the game entities (the bombs in the video) and the Pixmap data (the platform of the video) by adding some kind of basic collision detection checking the Pixmap’s pixels with alpha value different from zero. I only wanted to share the a video showing the experiment:
As always, hope you like it. Probably more information on next posts.
Since the beginning of Super Flying Thing, I wanted the game to behave in some aspects similar to Worms (and other games). One of those aspects is the destructible terrain, I love that feature and that is why I am prototyping some stuff to see if we can add that feature to the game or not.
The next video shows how I am using the Pixmap class of libGDX library to modify textures dynamically.
In the previous video there are two textures, they start with the same pixmap data. Then I start to paint and erase pixels from each texture to show how the pixmap operations works over the two pixmaps. Finally, I start rotating both textures and then paint and erase stuff again, to show how I am transforming from game world coordinates to each pixmap coordinates.
Destructible terrain. If that works, then we could add some new game play options, like throwing missiles (weapons!!) or killing yourself in order to destroy some part of the map and open paths. Or some power like a shield or something where you move through the terrain destroying it.
We could create some kind of in game level editor for people to make their own levels (and possibly share their stuff). We could make that now using tiles maybe, but I believe making the levels from textures could be easily used by any player (maybe kids). I feel like an in game level editor similar to Inkscape (what I am using right now) is advanced stuff for a typical player.
We could also make more interesting random levels (using some other techniques).
Having to handle all this texture modification information implies we have to use more memory since we can’t reuse textures, and that could be a problem in limited devices.
Another problem is that textures created with Pixmaps are not being managed by libGDX, that means if the game is paused (you had a phone call for example) and the textures were disposed, then when the games continues the texture data will not be automatically loaded by the library, so we need to manage the texture ourselves.
Also, we will probably lose Box2D collisions calculations as our world is currently made by Box2D polygons, and we will have to create our own bitmap collision calculations.
Working the terrain as textures is really interesting but also harder and we have to prototype more to know if this is possible or not. However, I will keep dreaming with this feature.
Hope you the post, and if you know some techniques that could help or want to make another contribution, feel free to comment, we will appreciate it.