Mercury: The Simple 2D Game Library | >> BETA coming soon <<

WIP games, tools & toy projects Archived Projects
#101

That last part that, I definetly didnt read of course :wink: 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?

#102

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.

#103

That ‘.’ is absolutely ugly.

#104

Been working on the GUI a lot lately!

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.

  • Jev
#105

Thats the perfect use case for lambdas, your right…

That looks awsome though. Would you have to register each command you want, or could you just call methods by name?

#106

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 :slight_smile: )
for example:
debug.?
shows debug.log, debug.drawfps, etc.

#107

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.

#108

Maybe you should integrate a console window Like the Portal console that appears when you press the “`” key

Console cmds:


pause - pauses main thread
resume- self explanatory
getScreen - takes a shot of the window with the game in it, not the console widow or any other window  
getCpuData - prints how much cpu the program is using 
newInstance - creates a new instance of the program

Just some ideas :wink:

#109

Not entirely sure what exactly you’re trying to accomplish (I’m short on time) but it sounds like you might be interested in the concept of a REPL.

#110

Oh my god Wes, you’re becoming Cas.

  • Jev :slight_smile:
#111

True :stuck_out_tongue:

#112

I only wish there was a depreciate or -1

#113

A bit late, but I saw your (wes) post at the top of this page, there is no need for reflection, what you want is the (aptly named, no?) Command Pattern. Example usage:


//pseudocode

while(input.hasMore()) {
      String cmdName = input.getNextToken();
      Object[] args = input.processUntilEndOfLine();
      commandMap.get(cmdName).execute(args);
}

Again, sounds like you want a REPL.

#114

You could also use Janino and use Java itself as your “scripting language,” but it’s likely overkill/not intuitive enough for users.

#115

Well I haven’t posted in this thread for a while!

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:


sheet = Spritesheet.loadSheet(Loader.loadFromClasspath("com/radirius/merc/test/tiles.txt"), Loader.streamFromClasspath("com/radirius/merc/test/tiles.png"));

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:


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

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


HEADER 16
Void 0 0 
Grass 1 0

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 :frowning:

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.

-Team Radirius (we have a new team name!)

#116

Console is pretty awesome, though I don’t see a use for console in 2d game engine, which is supposed to be used with code anyway (Is it gonna be like LWJGL or Unity?).

#117

Cheating! \o/

[icode]merc noclip true[/icode]

  • Jev
#118

This is what I plan on adding once I get the GUI stuff “done!” :point:

  • Jev
#119

I would like to contribute to the logo part. I consider myself decent at design.

Are you guys actually planning for this to be a real library that the public will consider using, like libGDX, or is it more of a pet project?

#120

Yes. The first real release won’t come about for a while though.

  • Jev