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.

@saucymeatman:This. And if it gets below a certain threshold, it gets a spoiler!

@SwordsMiner:Stop.

@Everyone:Damn it, I'm not Cas!

Also,Let's Get Back On Topic!

I am thinking of making a full blown video describing all of the console system, though it's just an idea. I will also add in variables soon as well. MAYBE you will be able to do math, but I am not sure if I can implement that in time.

Actually, you may be right. I mean, it will get a bit more complex than that when I add in manuals, but that's a great idea! You just made the parser less confusing. Up until this point, I was using solely '.' for syntax separation. +1!

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.

Welp guys, I finally finished most of the Developers Console. It is all on GitHub for you guys to try out. I am so far quite happy with my results so far. Thus, the only logical way to share this news is by naming off every single feature of it to make myself feel like I did more work than I actually did. Expect many a bugs, misspellings, and forgotten content by the way!

- Basic Commands: you can enter in small little commands with no arguments!

1

[CommandList] [Command]

As an example, let's end the program from the console.

1

mercend

- Argumentative Commands: you can enter a command along with some arguments!

1

[CommandList] [Command] [Argument1] [Argument2] [Andsoon...]

Let's try echoing our own opinions to ourselves!

1 2

mercechoMERCury_Is_AwesomeCONSOLE: MERCury_Is_Awesome

- Quotation Marking: you can add in Strings of characters that will not be parsed, just loaded in regardless of what they are. A space inside of quotation marks will not separate the argument into two, but just add in a space to the argument.

1 2

mercecho"Hello World!"CONSOLE: HelloWorld!

- Escaping Characters: you can make a quotation mark not do anything. You can basically make any single character not parse. Just put a '\' in front!

@trollwarrior1You are missing the point. This is not for making the game, but for modifying it on the fly. Say you want to test something, but don't want to close the window so you can edit a single (or multiple) variable, and load the game up again. You can just change that variable to your liking on the fly, and when you find the golden spot, go back into the code and change it. It is good for just testing out certain things, like constants, and things like that. And say you want to find what is behind that wall, to check if everything spawned okay? Well, you can just noclip through it!

Of course, there is also the cheating implications, which Jev will have some fun with .

Well guys, we are approaching a Beta release, in which we will vigorously bug test by making games.

Rename-No, I am not going for the obviously superior name 'MERC.ury.' I mean we will more re-classify it. It is currently called an engine, and, by Jev's definition:

Quote

[A Game Engine] is a program that acts as a game that is to be completed with assets and gameplay. A Game Library only gives you the basic components required to make a game.

This is highly misleading as to what I intended for the engine. I think I did not know the difference between an engine and a library back then. Now that I do, I realize that we were aiming more for a library. Thus the rename.

New Logo-Because we changed the name, and the current logo is a bit boring. It is good, but not great.

GUI-Someone on our team (not naming names), has been on vacation for a bit. He is back as of today, and can continue his work on the GUI. So it's a start!

Rewrite documentation (as of now, it is utter crap)-It is just unorganized. I hate how it turned out so far, and need to restart most of it, taking heavy inspiration from other game engine documentation. From the beginning, I have been doing more a tutorial n00b spoonfeed approach. Now, I will go for a more straight, dry documentation. More on the docs later.

None of this is TOO difficult, but more time consuming. But there is one thing I would like a few opinions on, if you don't mind: how should the docs be ordered? I have no clue as to how to approach the engine. Start with Boilerplate code, of course. Then do we just go to graphics, sounds, plugins, and utils? It just makes me

In case we have a 'skimmer' here: TL;DR Beta is coming soon; we need your ideas on how the documentation should be done!

@Slyth2727This is my dream project. You see, I am not that good a game developer. I take more joy in making the tech behind games than actually making games. Thus this is really rewarding for me, regardless of whether or not you use it, just because this is a project I can pour tons of effort into. And when I do get more into making games themselves, this engine will help my pet-peeve of only using my own code...

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