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,

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.

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.

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.

we also have commandline. "[command] ? " is usefull. it says what type args should have.[command.part].? shows all commands that start with the command-part (Because we were to lazy to implement a preview )for example:debug.?shows debug.log, debug.drawfps, etc.

Reflection is slow, and allows for alot of misuse, but if this is a debugging took than the person using it knows what they're doing. If its for also intended for an ingame console, you could maybe add in the disabling/enabling of reflection.

Today I'm proud to present to you the new and improved Spritesheet class! Well what does it do, you may ask? Its simple really! First, you obtain or create a spritesheet, then you create a special text file that is parsed by MERCury in a specific and secret way. The information in that file is then used to split up the spritesheet into renderable sub-textures so that you (the MERCury user!) can use spritesheets with style and efficiency. But what's the best part about the new Spritesheet class? Well, read on to find out more!

First lets talk about Spritesheets. Basically, you need two files. A image file (your spritesheet), and a specially designed text file. Lets take a look at the code:

This line of code simply loads a spritesheet. The two parameters are the "special text file", and the spritesheet image file, respectively. After you have done this, you can render a sub-texture from that spritesheet like so:

1

g.drawTexture(sheet.getTexture("Grass"), 10, 10, 128, 128);

Incredibly easy! Now lets look at the special text file:

1 2 3

HEADER16Void00Grass10

Lets break this down.

HEADER 16 basically means that on one side of the spritesheet, we have 16 sub-textures. Its VERY important you have a "square" spritesheet with the same width and height or else the entire Spritesheet class will fail

Void 0 0

"Void" is the name of the tile. 0 0 specifies that the sub-texture resides at position 0, 0 in the spritesheet. Positions are counted in increments of 1. Take a look at this example spritesheet:

The Grass tile is at (according to our special text file) position 1, 0. On the actual spritesheet you can see that the grass tile (the green square) is 1 tile over from the origin (in the top left hand corner). So, logically, the stone tile (the grey square) would be at position 2, 0.

I will develop a GUI based tool that will speed up the process of creating these special text files, but for now they have to be created by hand! I am also aiming to support non-square sub-textures, but that will be down the road.

On another note, I have also added the basics of IO with text files! More on that later though when it is actually complete.

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