We will be releasing Version 1.0.0 of MERCury within a few months. Me and kpars will be sweeping through everything looking for bugs, documenting the code, and creating new features! The most important feature we're bringing being... Data Management! (MERC.dat.___)

Thanks Everyone! Couldn't get to this point without your support!- Radirius

I will not be reinventing the wheel for sound and creating my own OGG, MIDI, and WAV decoders.i just vomited a bit while typing that...

I was trying to get OGGs to work, but it got to the point where I was sacrificing quality and taking too much time on something that should've been insanely simple. I've decided that I should just find a library. What better to use than paulscodee? It is amazing taking in plugins for different formats, making sounds a pleasure to work with.

So I just took paulscode and did a few things with it:

- You can add in codecs optionally, and if you don't all you get is a Logger warning.- You can add in LibraryLWJGLOpenAL optionally too, if you don't plan on using sound! - All you really need to have is the Sound Engine itself.- Wrapped everything in a nice Audio class which will: - Create an Audio object - Supports WAVs, OGGs, and MIDIs. - Plays, stops, loops, toggles - Volume, and pitch controls - And master volume control statically

- You can log in different levels, from NULL, to INFO, to DEBUG, to WARNING, and to SEVERE (Shuts down program by throwing a SevereLogException).- All initialization in the Runner is in the present tense, not the past tense (just a standard that I forgot when making it).- Removed saving to a log file. Will be replaced by a cleaner, and less space consuming method in the next feature.

Also, I have added in a feature in MERCuryException: have you ever had a non-tech-inclined person ask you what is going on, and you needed the console output, but they have no clue how to get that? Well, now MERCuryException will save its stack-trace into a [date].stacktrace, which you can direct your users to find, and give.

You can disable this statically with

MERCuryException.setSaveStackTrace(false);

.

Finally, and probably the most useful, is data-management.

- MERCData added into MERCury.data. This will allow you to: - Create a new .MERC.dat file - Write to a .MERC.dat file - Parse a .MERC.dat file- Parser version allows you to know whether or not MERCData needs to be updated.

Speaking of that particular update (should more be called a release,like v1.0 or something...), we alone cannot point out all of the bugs! While we are sweeping for bugs, chances are there are a whole bunch that no one has found yet.

So right now we're asking you to try out the engine! Play around with it, as the best bug-sweep is general usage! It will help us all get closer to the v1.0 update! And if you do find any bugs, just report them at github, here!

On behalf of me and the team: thanks.

In unrelated news, I have added in a splash-screen capability. Example ripped from here:

I decided to optimize the particle system a bit. Now the particles have the option to shrink slowly until they die off, and are wiped. It has been a joy to make this demo, and I am satisfied with it. I think it highlights the uses of Particles!

I will probably add in textured particles, then make a tutorial for it.

You can try the demo by importing the project, and running one of the MANY tests called ParticleTest. Enjoy!

What do you think I should add into the particles system for v1.0?Your guys' input really keeps this project fun and interesting for me and the team, so let me know by replying!

That looks really cool . May I suggest making the particles to spin around their centers until dead also? And maybe a gradient over time effect (start out black but a gradual fade to white; gradient speed would depend on life). Keep up the good work

75. Oh and, I have been meaning to ask you. I would love a lwjgl shader library where you can just give some rectangles or something of the sort and add a light and its all nice like box2d (no I wont use jBox2d)

Well, I haven't asked Wessles if I should post about this, so maybe I'll get yelled at, but I've added in networking to MERCury! Well, it was a while ago, but I'm finally getting around to saying it!

We use Kryonet to provide easy to use networking, and fast connections between clients and servers. I have abstracted Kryonet to make it even easier to use(!), and in the process created a few simple demos which you can find on the Github repository here:https://github.com/weslgames/MERCury

The wiki page is almost finished, so take a look at the networking segment when it's done to see how easy it is to add in online fun!

You know how the way you loaded resources so far has been by feeding in a location by String? You may have already seen the flaw with this plan. Where is that loading from?! Well, I have finally decided to fix that. For a few reasons:

This will be more user-friendly

We can now have resources in the MERCury.jar, with the splashscreens, tests, and default shaders

Loading is actually easier to understand now

I know what you are thinking: Wessles, that sounds mighty fine, but how oh how shall we use this fine addition to the official engine?

Well, most of it is done for you. All the classes that required resources with String based locations are now changed to accept URL's, or InputStreams. But there is a new class called Loader. Loader will load resources! There will be the following methods in it (static):

1 2 3 4 5 6

// Returns a URLLoader.URLFromClassPath("res/crap.file");Loader.URLFromSys("res/crap.file");// Returns an InputStream (buffered, of course)Loader.streamFromClasspath("res/crap.file");Loader.streamFromSys("res/crap.file");

You will use this in a lot of scenarios, but one of them is textures (ripped from ParticleTest):

I like the approach a lot of AAA game engines do. Just try to load from the classpath and the filepath, were as the filepath is prefered over the classpath. This enables someone to easily replace/mod single resources. Say you have a texture in your jar with the name "textures/my/awsome/skin.jpg", know if some player things that he want to lay with some other skin, he can just add a file with the same name to his own game directory.

This has the approach that the players are not corrupting their core game-files while modding, which lets them still upgrade/patch the game without troubles.

Due to a procrastinating defector in Radirius whos name we shall not mention, we have yet to work on the GUI until now. I just started working a bit more on it, and things are going great so far!

Before that...Before I get to what I have added, I would like to announce that manipulating already-loaded-textures will become a tad more easy soon. The way I have set it up, a texture will immediately save its source BufferedImage, and the information on how that source was manipulated before entering LWJGL. To modify a Texture, you can set the Texture to a manipulated copy of itself, like so:

Text Bar:Here we will need 2-3 images: 1 for the left side, 1 for the body, and an optional right side (but you could just flip the Texture object so that is still one image). In my case, I used these:

The side image is on the left and the body image is on the right. Once again, when we load these images we can make our object!

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