Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (524)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (592)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 9 10 [11] 12
  ignore  |  Print  
  Mercury: The Simple 2D Game Library | >> BETA coming soon <<  (Read 31150 times)
0 Members and 1 Guest are viewing this topic.
Offline StumpyStrust
« Reply #300 - Posted 2014-07-16 11:11:09 »

Indeed Riven you should create a sprite class to abstract much away but we are talking about just the batcher here which will need to know all that information in order to render properly. The sprite class would pass everythin into the batcher. That is a step ahead of making the batcher. Would also be nice to specify where you would like to rotate around I suppose.

Offline opiop65

JGO Kernel


Medals: 159
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #301 - Posted 2014-07-16 11:37:12 »

Just a little side note Stumpy, I think rendering the sprite at its center is just confusing. I think its far easier to render from the corner. In fact I don't think I've ever worked with a library that "auto" renders from the center.

Offline trollwarrior1
« Reply #302 - Posted 2014-07-16 11:39:01 »

Just a little side note Stumpy, I think rendering the sprite at its center is just confusing. I think its far easier to render from the corner. In fact I don't think I've ever worked with a library that "auto" renders from the center.

What about libgdx? I think it render in the center.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline opiop65

JGO Kernel


Medals: 159
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #303 - Posted 2014-07-16 11:41:01 »

Nope, LibGDX (as far as I know) renders from the bottom left corner (which makes sense as the drawing origin is the bottom left corner) or vice versa if the drawing origin is the top left corner.

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 833
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #304 - Posted 2014-07-16 12:12:54 »

Just render from a corner (it makes most sense in the low-level code) and let the Sprite class define the origin (around which to rotate), and make the necessary conversions in the code that renders the Sprite using the batcher - the 'SpriteBatcher'. Keep in mind though, that the 'rotation' parameter in the batcher is pretty much useless, if the callsite determines the point of rotation, as you'd need sin/cos to calculate the x/y offset, prior to the actual rotation - when using this approach.

It's not always best to build in layers of abstraction, as - as just described - it may introduce a lot of overhead. Especially in a SpriteBatcher, it's essential for performance to get as 'close to the metal' as possible, at the expense of (object oriented) code structure. My humble advice would be to refactor it beyond recognition.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #305 - Posted 2014-07-17 17:41:05 »

Ok, I just added in more easy rendering of Textures in the Batcher, and linked all of these into the Graphics as well.

1  
2  
3  
4  
5  
6  
7  
8  
9  
    public void drawTexture(Texture texture, float x, float y);
    public void drawTexture(Texture texture, float x, float y, float w, float h);
    public void drawTexture(Texture texture, float x, float y, float w, float h, float rot); // Defaults to the (0,0) corner for the origin.
    public void drawTexture(Texture texture, float x, float y, float w, float h, float rot, float local_origin_x, float local_origin_y);
    public void drawTexture(Texture texture, float sx1, float sy1, float sx2, float sy2, float x, float y);
    public void drawTexture(Texture texture, float sx1, float sy1, float sx2, float sy2, float x, float y, float w, float h);
    public void drawTexture(Texture texture, Rectangle region);
    public void drawTexture(Texture texture, float sx1, float sy1, float sx2, float sy2, Rectangle region);
    public void drawTexture(Texture texture, Rectangle sourceregion, Rectangle region);

Hope this is satisfactory,

-wes

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #306 - Posted 2014-07-17 23:10:04 »

Added in 2 more shapes! Polygons, and Stars. They can have any amount of sides. Nothing too special, but felt I should share it.

Trippy demo
Click to Play


-wes  Smiley

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #307 - Posted 2014-07-28 18:13:22 »

Worked on a small new feature: EasingUtils. It is exactly what it sounds like, a utility for easing between two values. There are several different formulas that I found and implemented: linear, quadratic, cubic, quint, exponential, circular and sine. Credit to gizma for the basic equations. There are two types of easings right now, a regular ease, which will simply go from one point to the next using a formula, and bouncing ease, which will go from one value to another in half the duration, and back to the first value by the end of the duration.

This allows for some nice looking fading effects like this, in the new default splash-screen:
Click to Play

By the way, that is the mascot for MERCury, a less crappy looking dAWWWW Smiley.

This also plays a major role in movement from point to point.
Click to Play

Using bouncing circular for x, and cubic easing for y, going to random locations on screen.



There will possibly some news regarding the site today, (Jev has not gone online yet, so I can't say for sure Tongue).

-wes

Offline cebarks

Senior Newbie


Projects: 1
Exp: 4 years


Wannabe Software Engineer


« Reply #308 - Posted 2014-07-30 21:48:27 »

I've been coming up with a concept for a 2D game recently anyway, maybe I'll try to use this to prototype it! Cheesy
Offline saucymeatman
« Reply #309 - Posted 2014-08-02 23:02:10 »

I wish the utility class you made for damping was self contained and not static.
Something like this,

1  
2  
3  
4  
5  
6  
7  
8  
EasingValue easedValue = new EasingValue<float>(0 /* StartValue */, 1 /* EndValue */, 200 /* DampingTime in milliseconds */);
float x = easedValue.get(); // Get the eased value, EasingValue class keeps its own time.
easedValue.reset(); // Reset to it's StartValue.
easedValue.pause();
easedValue.resume();
easedValue.setSpeed(1); // Set the speed of the easing to 100% it's normal speed.
easedValue.setStartValue(0 /* New StartValue */);
easedValue.setEndValue(1 /* New Target Value */);


I'd make the class for you, but I lack the time : (
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kpars

JGO Kernel


Medals: 107
Projects: 4
Exp: 4 years


Extreme Typist.


« Reply #310 - Posted 2014-08-04 00:53:33 »

@saucymeatman:

Done. Smiley
Thanks for the great idea.



@Everyone:

In this past month, we've been working pretty hard on 4 requested things, and I'm happy to say that they're finally ready.

Here are 4 new places where you can go to learn about and discuss MERCury.



1. The MERCury Website

A portal to all things regarding MERCury. Link.

2. The MERCury Forum

A place to discuss game development with MERCury and improvements to the library. Link.

3. The MERCury Wiki

A carefully written place to learn how to use MERCury and how MERCury works. Link.

4. The MERCury IRC

A place for general chat and discussion about MERCury. Webchat Link.



So join the forum, get in the IRC channel, enhance the wiki, and do whatever you can to enhance the project!
Thanks for helping with everything.

- Jev

Offline CogWheelz
« Reply #311 - Posted 2014-08-04 01:01:50 »

Nice job, it's coming along well.
Offline jrenner
« Reply #312 - Posted 2014-08-04 13:41:49 »

libgdx renders from the corner, but also has convenience methods for setCenterPosition(x, y);
Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #313 - Posted 2014-09-11 01:39:57 »

Hello.

I have been working on a new feature that I am very excited about: Controller Support.

Now you can plug in your controller and treat the controller simply like a keyboard, but with analog sticks and a dpad. I tried my best to make it as simple as possible to use. Here is a quick tutorial on how to use controllers.

If you see any features lacking/missing, please reply and I will do my best to add it in.

Happy coding,
-wes

Offline kpars

JGO Kernel


Medals: 107
Projects: 4
Exp: 4 years


Extreme Typist.


« Reply #314 - Posted 2014-09-16 16:25:34 »

Hello, Everyone.

Me and Wesley had a long talk about the noise in the thread, and I think it's safe to say that there won't be any more chitchat from now on. Smiley

I actually have a big announcement to make regarding the project... Quite a few of them actually.

The project is officially over a year old now, and a lot has happened in the past year that we've been developing this.
The original goal, a full year ago, was just to make a game library for shits and giggles.

In the past few months, our project's goal has completely changed. Now we're actually making a game library that intends to just stay simple and avoid the unnecessary. That's pretty much it. We figured that if we want others to recognize this mindset, we need to turn our entire development philosophy around. To get a head start, we're officially going to rename the project to something much simpler and recognizable.

From now on, the project is just going to be called... Mercury.
That's right, I'm serious. From now on there will be no more of those 3 annoying capitalized letters.
Incase you were wondering what they were there for, it was supposed to be a cheesy recursive acronym:
"MERCury's Easy, Reliable, (and) Capable!"


Enough said about that, let's move on to the code itself!

For the past week and a half I've been tinkering around and fixing many kinks and bugs in the library. (Changelog here) And honestly, there is a lot of stuff wrong with it right now. Currently, our main issue is the staggering amount of leftover code in the library from its early days. In-case some of you hadn't known, Mercury had originally started out as a 3D library and 'downgraded' to 2D about a week in for the sake of making things less time-consuming. There were still a few tools built into the library to deliver not-so-good support for it, and now they've finally been removed in my latest commit.

I'm also proud to say that the way Core's are setup now has been completely reworked as well. I'm just going to let the code explain for itself.

Here is what your average class would be like, using Mercury just but a couple days ago:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
public class MyClass extends Core {
   Runner runner = Runner.getInstance();

   public MyClass() {
      super("Hello");

      runner.init(this, 800, 600);
      runner.run();
   }

   public void init()              {}
   public void update(float delta) {}
   public void render(Graphics g)  {}
   public void cleanup()           {}

   public static void main(String[] args) {
      new MyClass();
   }
}

While this is extremely short when compared to class setups in things like Slick2D, I figured that we could do this better and in a much more simplistic manner.

Here's how the basic layout of a Mercury program looks now:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class MyClass extends Core {
   public MyClass() {
      super("Hello", 800, 600);
   }

   public void init()              {}
   public void update(float delta) {}
   public void render(Graphics g)  {}
   public void cleanup()           {}

   public static void main(String[] args) {
      new MyClass().start();
   }
}

This is perfect in my opinion. Now the user doesn't have to do anything with the Runner nor know exactly what it does to get a basic program going. Not the biggest change in the world, but still pretty awesome I feel.

Granted, a bit of hackery was required to get this to work. All of the code for it should be cleaned up very soon, probably by Me or Wesley.

With that out of the way, there's still even more to discuss. Remember that awful Color class? We've already gotten some complaints about that one. I'm very happy to say that now it's much easier to use, yet less buggy too. I've additionally added new g.setColor(); functions that simply take in 1, 3 and/or 4 variables containing each component. So now you have the choice of either creating a new object for your colors or passing in all of the variables for one right there. Pretty neat stuff IMO. I've also re-done the color palette entirely. This time, I've decided to do it with easy-on-the-eye colors that I feel are and will be very delightful to use in different projects.

Demos of the library are also now in development, and most of the classes in the test package have been removed for the sake of keeping the library clean. The code for them tends to be very awful. I've also made a few changes regarding splash-screens, now you don't have to manually display them in your render function. I've also brought back the drawRectangle() function, for it was gone a while back and replaced with drawPolygon(). (Still not replacing drawPolygon() though)

We're only about 80% done with the renaming process and going through all of the files to make sure we don't miss anything. Right now we're still in the middle of having to update splash screens, leftover documentation, GitHub-related things, and a bunch of other junk. Feel free to contact me or Wesley to report any files/code that still uses the 'MERCury' name. The Wiki will also be updated later. So don't worry about that.

That's pretty much it really. A lot of other things have been changed, but they're not significant enough for me to need to mention them in this post. Tongue
Again, check the (horribly-written) change-log if you really want to know all of what happened.

TL;DR Update:
Core's are now much easier to setup,
We've changed the project's name to 'Mercury,'
We've turned our entire development philosophy around,
1.0.1 Beta, our first official release, will be released later within the next 1-2 months with various changes,
Many bugs have been, will be, and are being fixed.

You can download the latest build here:
[dead link]

The code is still really hackish right now and everything is still a bit buggy, so don't expect a stable build out of this.

Thanks, hopefully that can give you guys a bit of an idea of what we've been doing lately.

I've probably made a ton of grammatical errors in this post and may have not worded things too well, I'm tired from having worked on the project all night. I'll probably just make a second edit later with some typo-fixes. Tongue

Happy coding,
- Jev

EDIT: Yep, I know the versions on the JARs are all messed up. Fixed.

Offline saucymeatman
« Reply #315 - Posted 2014-10-09 17:17:18 »

Is this project still in development?
Offline kpars

JGO Kernel


Medals: 107
Projects: 4
Exp: 4 years


Extreme Typist.


« Reply #316 - Posted 2014-10-09 17:46:51 »

Yep!

We've officially been going for over a year now, still chugging along.

Also, I've fixed all of the links on the website, and as well fixed an issue in the GitHub repository where language stats wouldn't show up.

Recently we've been working on adding better controller support, making games with the library, better versioning, and cleaning up code so we can add even more features!

We're aiming for a beta release in either December or January.

- Jev

EDIT: I've edited the download link in my previous post.

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #317 - Posted 2014-10-09 21:51:02 »

As of now, we've added about as much as we had hoped to add to the library (although we still have a massive amount of space for new features). The reason you haven't heard from us is because we'd stopped announcing new features. Now we're just fixing issues and bugs with the library. Making the library more accessible to more people is the priority right now if we want anyone to use it. We'd hate to have an unprepared library distributed.

We are also trying to make games to actually show what the library can do, as opposed to just talking about it in rare posts to JGO.

Don't worry; this project is stronger than ever, and it isn't dying any time soon.

Happy coding,
-wes

Offline kpars

JGO Kernel


Medals: 107
Projects: 4
Exp: 4 years


Extreme Typist.


« Reply #318 - Posted 2014-10-10 18:56:33 »

I would just like to remind everybody here, the official website's domain has been changed to http://www.mercurylib.com/.
http://merc.radiri.us/ has been set to a redirect, so no existing links should be broken.

I also got http://www.mercury2d.com/, for people who don't like typing one extra character.

- Jev

Offline Ashedragon

Junior Devvie


Medals: 2
Projects: 1


The best person you could possibly be is yourself.


« Reply #319 - Posted 2014-10-25 17:11:51 »

Seems you've made quite a lot of progress in a year!  I do wonder if you plan on including a state based system in the future?

Need an amateur composer for your project? I charge $4~ (depending on the length) a song, and need the practice. Check out examples here: https://soundcloud.com/literature-corner

I also might help with game jams free of charge (keyword: might).
Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #320 - Posted 2014-10-25 18:16:06 »

I am actually making a game with Mercury right now that requires a state based system. It should be in the library itself very soon.

-wes

Offline kpars

JGO Kernel


Medals: 107
Projects: 4
Exp: 4 years


Extreme Typist.


« Reply #321 - Posted 2014-11-08 08:12:27 »



It's been a while since we've said anything big about the library lately, so here's a post that'll hopefully give people a better perspective as to what's been happening recently.



General Updates & Reminder

It's ~2 months until the libraries first beta release.
We've been going for over a year and three months now, getting close to 500 commits.

December is going to be an interesting month for us. We're going to be releasing the first beta version of the library, launching one of the games we're making with it, giving the website and forum a slight makeover, lots of stuff really.

Here's the thing; to get a stable build out by the end of december, we need more people working on the library with us. If you're willing to join the team, contact either me or wes on JGO and we will get back to you as soon as possible.

Requirements:
  • Must have at least 4 years of Java and overall programming experience.
  • Must be actually dedicated to working with us on the project.
  • Must be familiar with git and have a GitHub account.

In your message you should also tell us what you would be specializing in on the library's development.
Samples of your code are mandatory.



Code Updates

GUI might be put on hold for a bit; not entirely sure. I have a lot of code-cleaning to do on it.

Shape rendering has also had some massive updates, now you can texture any shape in the library with no hassle. Plus they have more accurate boundaries now as well, so that should improve collision and intersections.

Camera rotation is also finally in; no idea why it took us so long to toss that in there.

TMX Loading will be in before December, don't worry. We've gotten a lot of request to add it in, so hopefully Tiled users will be happy about this.

We might not get full-blown networking support in before the release, mainly to prevent awful code from spawning. If there are any networking guys out there wanting to contribute, send us an email.

I'm also in the middle of writing a document based on the Google Style Guidelines for Java, which we will be officially following as of the release.

The default font will also be changed from Open Sans to Roboto, just a little side-note for the typography geeks out there.



Wiki Updates

Yep. We haven't worked on it as much as we should've lately.

The wiki will be updated after the release. It would be a waste of time to write a bunch of pages that we're just going to have to update in two months anyway. Sorry to the newcomers who probably have no clue how to use the library. Sad

We have so many new articles to write for it though, mainly regarding the particle engine, GUI toolkit, scene-graph, game state manager, etc.



Hold up... Did you just say...

Yep. There's a game state manager and scene-graph now. Both are very simple to use Smiley

The implementation of both of these are still a bit rough, so don't expect anything too fancy yet. The scene-graph is still pretty bare-bones and the game state manager isn't perfect, so there's still more to come.

But regardless, I'll show you what I can.

Using the scene-graph is pretty simple. You just take any random class that extends GameObject (in this case,
Thing
) and pass in the object into the 'addObject(...)' function of GameScene.

1  
2  
3  
public void init() {
   GameScene.addObject(new Thing());
}

The rest of the updating/rendering is done for you automatically.

Adding child nodes and controlling the current objects in the graph is a whole other thing; I'll talk about that in the wiki article.

GameState is also pretty simple. It's like any other Mercury component except it has
onEnter()
and
onLeave()
functions that are called when entering and leaving the game state. The rest will be included on the wiki article.



Game Updates...?

Yep. We're actually making games with this. We aren't that bad!

We're in the middle of making this little twitch game called RFLEX. More info on it will come about later.
The website for it will be fully available once the game itself is ready for JGO to critique and play around with.

This is also why Wes hasn't been on development much lately; he's doing most of the work on this.



Let us know if you have any questions or concerns.

Happy Coding,
- Jev

Offline gouessej
« Reply #322 - Posted 2014-11-08 11:57:57 »

Hi

In my humble opinion, some classes have too much static methods, for example com.radirius.mercury.scene.GameScene and com.radirius.mercury.resource.Loader. Maybe you do that to simplify some things but it drives the API more rigid and harder to extend. Good luck.

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #323 - Posted 2014-11-08 13:35:33 »

In my humble opinion, some classes have too much static methods, for example com.radirius.mercury.scene.GameScene and com.radirius.mercury.resource.Loader. Maybe you do that to simplify some things but it drives the API more rigid and harder to extend. Good luck.

Thanks for the reply, gouessej. Your suggestions are much appreciated Smiley

We thought about turning GameScene into an object recently, we're probably going to do that now to help the overall flexibility of the scene-graph.

Care to elaborate on what you want done with the Loader?

-wes

Offline Slyth2727
« Reply #324 - Posted 2014-11-08 15:36:58 »

About the experience cap on who can apply: it shouldn't be based on the number of years the person has been programming. While it can give you an idea, this rarely indicates the total amount of skill someone has.

Was I before Chuang Tzu who dreamt about being a butterfly, or am I now a butterfly who dreams about being Chuang Tzu?
Offline gouessej
« Reply #325 - Posted 2014-11-08 17:16:48 »

Care to elaborate on what you want done with the Loader?
It's difficult to plan in which environment the developers use the libraries. For example, a developer might need to use a custom resolver for URIs and URLs. If you don't use this class internally, you can leave it unchanged, otherwise you should allow the use of custom loaders. In general, I avoid writing classes with tons of public static methods and I know that it can be a limitation in multi-threading. It becomes a real problem when those static methods don't do trivial things and when they are called very often internally. I have to fix this kind of limitation in another engine and it's easier to deal with that earlier. I prefer using classes with no field than classes with only public static methods.

Offline wessles

JGO Wizard


Medals: 74
Projects: 4
Exp: 4 years


Radirius Software


« Reply #326 - Posted 2014-11-08 17:56:03 »

The Loader is used internally, but the user is not obligated to use it in any way. It is a convenient shorthand for getting InputStreams and URLs to resources in and out of the classpath. All they need to give when loading a resource is an InputStream (or sometimes a URL); it doesn't have to come from the Loader class.

We could make it non-static, but that would kind of be like Oracle making Math non-static; it is not near as simple to access and is a nuisance.

Again though: it is not a mandatory class for loading. Go ahead and produce InputStreams and URLs however you like.

-wes

Offline SHC
« Reply #327 - Posted 2014-11-15 16:25:09 »

This is to notify you guys that I've successfully converted the code to use OpenGL core profile. Here's a screenshot showing you the tests that are along with the library being run on core profile.




To do this, I've made two new classes,
Matrix4f
and
GraphicsUtils
. I've removed the
VAOUtils
class completely, as it has no use, since the new code is relatively small. This
GraphicsUtils
class, is used to emulate the Matrix stack, to provide the an easy way to keep the matrices for every frame.

I've also modified a lot of shader code, and the default shader uses 330 version of the OpenGL Shading Language. Everything is working, and we are currently assuming that most people will use the standard shader, have made the process of using the shader difficult with
VAOBatcher
since we hard-code the names of the uniforms we use, and also the locations of the attributes is fixed.

I also made modifications to the
Graphics
and
Batcher
interfaces to include another void method called
cleanup
to clean the handles for OpenGL objects generated in the constructor and I've called those methods in the
end
method of the
Runner
class to ensure that they get cleaned every time.

Anyways, I'm proud to say that these changes doesn't effect the library, any existing code using this library runs fine just without porting.

Happy Time Users!!

Offline SHC
« Reply #328 - Posted 2014-11-17 16:11:49 »



Ported Framebuffer API to Modern OpenGL. Here's a small snippet showing how to use the framebuffer.

1  
2  
3  
4  
5  
6  
7  
8  
frameBuffer.use();
{
    g.setColor(Color.CRIMSON);
    g.drawRectangle(100, 100, 100, 100);
    g.setColor(Color.CLOUDS);
    g.drawString("This is rendered to framebuffer!!", 0, 0);
}
frameBuffer.release();

That renders to the framebuffer. Then you can simply get the rendered texture by calling
frameBuffer.getTextureObject()
and use it while rendering. The test renders the texture to a rotating rectangle.

And here is the FrameBufferTest running under Mac with OpenGL 3.3 (A crappy gif I could record)

Click to Play


And also fixed a small bug that caused rendering of
SubTexture
s to cause an NullPointerException. Anyways, this is so small right now.

We plan to release this somewhere between 20th and 30th of December, and there is a lot more to do. Jev is currently working on a TMX map loader, and it's going on pretty well, that should be available in his next commit. Till then, I'll be working on the documentation, and will be testing to find any bugs that might crept in.

Happy Time Folks!!

Offline kpars

JGO Kernel


Medals: 107
Projects: 4
Exp: 4 years


Extreme Typist.


« Reply #329 - Posted 2014-11-17 16:19:33 »

I'd also like to clarify that right now I'm giving the website and forum a huge makeover.

There's also going to be a showcase video for the library in roughly a week from now, so stay tuned! Smiley

- Jev

Pages: 1 ... 9 10 [11] 12
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

toopeicgaming1999 (55 views)
2014-11-26 15:22:04

toopeicgaming1999 (48 views)
2014-11-26 15:20:36

toopeicgaming1999 (8 views)
2014-11-26 15:20:08

SHC (24 views)
2014-11-25 12:00:59

SHC (24 views)
2014-11-25 11:53:45

Norakomi (26 views)
2014-11-25 11:26:43

Gibbo3771 (23 views)
2014-11-24 19:59:16

trollwarrior1 (36 views)
2014-11-22 12:13:56

xFryIx (75 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!