Introducing MERCury: A Simple 2D Game Library | -> Beta coming soon <-

[BurntPizza]

Computer pics are broken because you're linking to your GMail.

[saucymeatman]

Hey you should keep that awsome-ness with the current 3 image parameter TextBox, but why not also allow for this :

1	TextBox saucysBox = new TextBox("Blarg!", [size-parameters]);

And procedurally generate the textures, like Swing. I doubt it would be easy, but it would be a cool feature.

In fact, I might take a stab at it, if you dont mind.



Anyway, this is cool stuff.

[wessles]

As of now the text box will already generate and extend the body texture to fit the text inside the field. Adding in size parameters seems a bit pointless, no?

Games published by our own members! Check 'em out!

[saucymeatman]

Sorry, I was vauge.

I meant that it would be interesting if it would generate a procedural texture based on the size parameter, so you wouldnt have to pass in any images. Because, for instance, if you pass in a low res texture and have a wall of text, it will stretch itself out, and it would be a pain to have alot of differently sized textures for gui.

You could have a constructor with no texture parameters that generates one for you that will fit the size. Like in swing with JButton,

JButton b = new JButton("ButtonText");
b.setSize(100,100);
//do whatever else.

Swing generates the button texture for you, based on the size you gave it, is what I'm trying to say.

[wessles]

Oh, don't worry, I covered that as well. I meant by generating that it repeats the Texture over and over again using OGL's texture coords. Turns out if you go over 1.0 on the x it just makes the texture bigger and repeats. YIL _{yesterday I learned}.

[kpars]

I admit to being lazy and not working on GUI. I'm getting back on the project, don't worry.

^{(Wes Get The f**k On IRC Right Now or I'll bash your head in. #jeviny, Esper.)}

- Jev

[opiop65]

I'm coming back too Wes The teams all back together! *cliche music plays*

[saucymeatman]

Dude your old laptop looks EXACTLY like mine! Ha.
HP Pavilion ENVY dv6 is mine, that one looks like a HP Pavilion ENVY also.

[wessles]

Team is back!

Hey, I also can get rid of my old laptop!

YOU KNOW WHAT THAT MEANS!

<a href="http://www.youtube.com/v/fjsSr3z5nVk?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/fjsSr3z5nVk?version=3&amp;hl=en_US&amp;start=</a>

[kpars]

Can we get back on topic before this ends up in the chitchat monster?

- Jev

Games published by our own members! Check 'em out!

[HeroesGraveDev]

http://www.indiedb.com/engines/mercury-engine

Looks like you have a problem.

[opiop65]

Meh, our name is an abbreviation. I don't think it could possibly matter legally because... They are just game engines that are free.

[wessles]

I don't know that making a company called APPle All People that Pop would go down so well with Apple, so I doubt that it would go down so well with the owner of Mercury.

I remember seeing that when I was googling MERCury. The owner seems to be inactive lately though; maybe I should email her?

EDIT:
Derp; she was last online in December. Will email her.

[opiop65]

Yeah but Apple is a huge company just looking to snatch up more money from smaller companies. I seriously doubt this person would have a problem with us, but it would be a good move to email her.

[Agro]

it doesnt really matter, its just a name really... how many products/engines have i seen out there that have the same name

[wessles]

Well, it would be a little rude not to at least try to make contact with the engine maker.

I have already emailed her; if she fails to respond within a few months, she is probably inactive. This allows us to keep the name.

Legal issues evaded  

- Wes

[SwordsMiner]

I bet there is no SAGL engine already taken. 

[HeroesGraveDev]

I bet there is no SAGL engine already taken. 

http://sourceforge.net/projects/sagl/

[SwordsMiner]

-snips-
http://sourceforge.net/projects/sagl/

God danget.

[opiop65]

So I've been whipping up something fun!

Presenting the AutoLoader function! One thing I always hated when working with resources in other libraries was having to load every single resource one at a time, so I decided to implement a loading function that will load all resources for you!

It's very simple to use (although it is a WIP). Here's how:

First, you can load resources from within or outside of your Jar file. Currently loading for external is the only function that is complete, internal is going to take some more work. To load resources from a folder (relative to the Jar file):

1	RM.autoLoad("src_base/com/teama/merc/test/resTest", false);

The first parameter the function takes is the folder you wish to load resources from. The second parameter is whether the path is pointing to external or internal resources. The function then loads the files (only files that have parsers for them will load) and adds them to the list of resources contained in the ResourceManager.

Anyway, hope someone enjoys my brain child

- Team Alluminum

[wessles]

Great feature! 2 things to add though:
- User defined templates for the names of the stored resources. This would be optional, of course.
- Make sure by default you remove all of the text after the first '.' and use the official resource prefixs on the wiki.

EDIT
Also, rename to 'bulk loading.' Like loadBulk();

[wessles]

Hello.

Me, Opiop and Jev are on an IRC Channel for discussion about MERCury. We will answer all of your questions, and add your input to the mindmap on GitHub ^{if we deem it worthy}. So come on down! We need all the input we can get!

IRC Channel
*Please make sure your nick is the same as your JGO username.

Thanks guys!
- Wes

[kpars]

Thank you for posting this, I feel more people should use IRC.

On a second note, I added a bot to the channel. Feel free to mess around with it.

- Jev

[wessles]

[snip]

Turns out we got the naming issue all sorted out. We're fine guys!

- Wes

[saucymeatman]

That last part that, I definetly didnt read of course made me laugh hahaha

My frustration expressed in prose :

Oh, my Vanessa
do none other bear the same name as thou?
Because my Vanessa, I'd betcha
your name is all the sweeter shared

Doth only one namespace exist in c++?
Nay, a single identifier in Java?
Hath one's symbols never, not once, been redefined?

Oh, my Vanessa
And if this be all true,
could the Mercurys not share names too?

Vanessa, your giving me the blues.
Are we not indie too?

[kpars]

I honestly don't think we have to rename the engine 'MERC.ury' for it all to work out. There are a ton of other people using the name 'Mercury' for their game engines, and MERCury is something completely apart from that. I feel that case sensitivity should apply to this, and MERCury has 4 capitalised letters.

There's nothing she can really do as of right now. If you gave her a list of all other game engines named Mercury, and manage to find one made before hers, then maybe she'll change her mind. It all depends. I'll try to stay out of the situation and just work on other things that have to do with the engine itself.

- Jev

[Drenius]

That '.' is absolutely ugly.

[wessles]

Regarding poetic expression of dislike (or creepy fanfic) of my decision: s_hhhhhh that is ridiculous.

@Jeviny
Well, I agree entirely. The copyright SHOULD be case sensitive. But after numerous googles, I got the answer I expected: copyright law is not black and white like that. I would guess it depends on whether or not the users would be confused between the two. I personally thought that Vanessa would have no issue with it; the last official update I could find on the engine was in ~2011, so I guess there wouldn't be so many users now, if any.

I did try to find other engines by the name of Mercury before I made this decision. I found none, as this engine goes as far back as 2006! Anything farther back than that must be pretty difficult to find!
EDIT:
Whoops; Upon reviewing the evidence again, I realized that this is an entirely different engine that I thought looked pretty similar to the other Mercury from the screenshots (2006, then 2011; to be fair, they look like they could be the same engine). It has about 16 people that have worked on it, it is 3D and 2D, and it is multi-platform. That is cool, and is something I should have researched more thoroughly. I think I am going to back off on asking for permission from those guys and show this to Vanessa.

Sorry guys, will make the change back tonight!

@Drenius
I am not happy about it either; it is atrocious. EDIT: I will change it back to normal soon.

But again, you can still refer to it as MERCury (not that we are advocating it in any way), and none of the engine itself had to be modified to do this. Thus for the most part, you will not see that '.' anywhere but the documentation, and from Team Alluminum's staff.

Hope you understand guys, I don't like it, but it won't effect much. You will see it rarely.

Yeah, that was stupid of me  .
-wes

[kpars]

Just a small preview with what I've been doing with the GUI stuff lately.



The word 'panels' is on an extra line, it's a bug I'll have to look into later.
Other than that, It's going along pretty well! GUI stuff is much more fun to do than I thought it would be!

- Jev

[wessles]

What is it now, Wesley?
Just got a neat idea. How about I make a developers console? It would make debugging such an easier process, whereas you can run the code, change some vars while running it, and then change the actual code (also, lets not forget that the cheating community would be very happy).

Alright, you have my attention. How would it work?
It would work like this:

All Java games already have a console that come with them: System.in. I would have a listener to System.in, and it would run it through a list of registered commands. If it finds one, it executes the command, with argument support. Would require a bit of reflection to get fully working, but I think it would be worthwhile.

Commands would work like this:

1   2   3   4   5

// You have a default CommandList called 'merc'. A CommandList is basically like an class; you can pack it with functions linked to Commands. Maybe we have a command in 'merc' to stop rendering? $: merc.setRender false // This would effectively freeze the screen. $: merc.setUpdate false // This would stop updating the Core. Of course, the [tt]CommandProgram [/tt]will still loop through [tt]CommandLists[/tt].

Later on, you may want to add in your own CommandList, such as, playerctrl!

1   2   3   4   5   6   7   8   9   10   11

CommandList playerctrl = new CommandList("playerctrl"); // We can add in Commands! playerctrl.addCommand(new Command("setspeed")     {         public void run(String...args)         {             speed = Integer.valueof(args[0]);         }     }     // Completely unrelated, anyone else wish lambdas were in Java 7? );

1   2

$: playerctrl.setspeed 10000 // *Speeding Intensifies*

All of the above code is kind of self explanatory (any syntax mistakes are irrelevant; this is proof of concept). You make a CommandList, add a Command with a name, and function. Profit.

Wrap it up, this is getting boring...

Again, this is all just an idea. I am probably going to do this sometime this week, so please leave some input on what else you think is essential to a command system.

Yours truly,
- Wes