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,

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.

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.

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.

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.

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

EDIT: It should probably be noted that MERCury is no longer named as a game engine but rather a game library, which I assume also contributes some to the issue.EDIT #2: It should also be noted that MERCury is no longer called MERCury, but just Mercury as of August 2014.

@JevinyWell, 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!

@DreniusI 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.

Plans for a default look & feel are set for the future, but as of right now nothing along those lines will come.

There's also a bug where the final words of a paragraph will be wrapped even where there's plenty of room for the.Other than that, It's going along pretty well! GUI stuff is much more fun to do than I thought it would be.

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.setRenderfalse// This would effectively freeze the screen.$: merc.setUpdatefalse// 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!

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