Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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]
  ignore  |  Print  
  Mercury: A Simple 2D Game Library | -> Beta coming soon <-  (Read 26678 times)
VoxelBoxStudios 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: 154
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.

Online 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: 154
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: 799
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: 66
Projects: 4
Exp: 3 years


Profile picture isn't relevant.


« 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: 66
Projects: 4
Exp: 3 years


Profile picture isn't relevant.


« 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: 66
Projects: 4
Exp: 3 years


Profile picture isn't relevant.


« 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 Wizard


Medals: 79
Projects: 4
Exp: 3 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: 66
Projects: 4
Exp: 3 years


Profile picture isn't relevant.


« 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 Wizard


Medals: 79
Projects: 4
Exp: 3 years


Extreme Typist.


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

Hello, Everyone.

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 both stay simple and avoid the unnecessary. That's pretty much it. Whether or not we have yet reached those goals is up for debate Roll Eyes. We figured that if we want others to recognize this mindset though, 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 is Easy, Reliable, and Capable!"


With that out of the way, we're also taking on a whole new approach to the way we design the library and give its description meaning..

To describe Mercury, we normally tend to say that it's 'A Simple Java Game Library'. The problem with this is that we don't actually think about what it means nor what impact it has on our development and design decisions. It has no meaning right now, to say the least. Currently we're in a whole new chapter of Mercury's development, and because of this we're finally going to solve this problem. In other words, we're going to actually make the project live up to what we've described it as previously. We, the developers, are and always have been minimalists to some extent. We live by the philosophy that less is more and demonstrate that in our non-coding work. Now, I would say that it's time we start actually bringing this philosophy into Mercury's development for the better. We're going to begin by working on avoiding clutter and gradually move away from the distracting and unnecessary parts of functionality that we previously would've wanted to have. From now on, expect a lot of experimentation to go down. We're going to be trying out completely new ideas with the goal of simplifying game development in a modern, simple way that anybody can pick up with ease. That's how we plan to give the project and its description some meaning again.
This was probably horribly worded.

Enough said regarding that, now 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().run();
   }
}

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:
Mercury-1.0.1.jar (1.0mb)

The code is still really hackish right now and everything is still a bit buggy, so please don't hesitate to leave an issue on the issue tracker at any time if you experience any problems.

Thanks, that should give you guys a bit of an update as to what's going on with the project.

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

- Jev

EDIT: Yep, I know the versions on the JARs are all messed up.
1.0.1 isn't going to be out for a while, so ignore the name of the JAR files. I'll fix this issue soon. Tongue

Pages: 1 ... 9 10 [11]
  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.

BurntPizza (22 views)
2014-09-19 03:14:18

Dwinin (35 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (90 views)
2014-09-10 06:39:09

Tekkerue (44 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (48 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (37 views)
2014-09-07 01:10:19
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!