This is super pretty, and looks like it works great. It's too bad I already have my own level editors created for my games... maybe I can actually add onto your project. I've got other features like as many layers as you want, being able to add custom Java code to each level (so like pushing a block into a wall can make something happen, etc.), and a few other things.

The reason for changing the tilesize in TileChooser is because thetiles that I use are overlapping eachother half.The actual tile is Height:100xWidth:50.There was only one dimension that I could change in theTileChooser.java and that was the width. Granted, I could modifythe whole chooser code but I wanted to have a quick go at it.So I changed the tile to 100 and thus resulting in the extreme widthof the tile.

Maybe I did go about it incorrectly and you can point me to thebest way of changing the tile dimension in the tilechooser......

Or if your base tiles, ie. the ground ones are 50x50, then use 50, 50.

i have to redo the tileset stuff properly one day. i have been playing around with drag n drop, i wanted to make it so you could create your tileset by just draging images onto the tilechooser panel and then it would ask you for a bit of info about it and add it for you. but first need to add a save function to the GraphicsBank class, which holds a tileset. Actually, it might not be all that much work.

But to add them to the tileset, I just want the path relative to wherever you're running the editor from, or wherever the tileset file is located. such as:"gfx\tiles\fence.gif"

I can think of one quick and dirty way to get this... make a new file at the location of the tileset file, then call getAbsolutePath() on it, make it a string, and clip the beginning of that from the beginning of the other string.

This seems a bit messy to me. Is there another way to do this more reliably?

when u drag and drop, cant you just have a InputDialog and ask the user for new images description name, then save it to the tilemaps working directory, aswell as apending a line to the current tile script file.

I can think of one quick and dirty way to get this... make a new file at the location of the tileset file, then call getAbsolutePath() on it, make it a string, and clip the beginning of that from the beginning of the other string.

i hadn't thought of that, and it's a good idea.I think what i'll do is have the program attempt the path clipping thing on the filename first. If it doesnt match (ie. tile above path of tileset, tile on a different partition... tile on your desktop), then i will copy the image file to the tile directory, otherwise i'll just put the clipped path into the tile list...

EDIT:I have done a complete rewrite of the GraphicsBank (the class that loads / saves tilesets). It has been simplified. Here's an example of the new tileset format:

1 2 3 4 5 6 7 8 9 10

# Thisfilelistsalltileresources# Whitespaceatthestartofaline, andimmediatelybeforeand# afteracommaareignored. Don't use commas in the description.# Each tile must be on its own line.

ID number,Image file,name,type,Other info...

26, tiles/grass.gif, Green Grass, No type, You walk on it...,1 , tiles/dirt.gif, Dirt, No type, It makes boots muddy,2 , tiles/tree.gif, Plain Tree, no type, It is a bit wooden,

I think it's both easier to read, and easier to parse, you only need do readLine(), split(",") and trim() to get values.

All paths used to find files are now relative to the file that's referencing them, rather than the location you started the editor from. The editor can no longer read tiles / tilesets inside its own JAR, so will launch with a clean slate instead (but this seems broken right now).

- Right click tiles for a properties dialog to edit their info or delete them.- Add new tiles by dragging and dropping images onto the tile chooser panel.- Save and load tilesets independently from maps.

To run it, download the zip, extract, run make.bat, then double click mapedit.jar (or run.bat)Linux users may prefer to type "javac *.java" and then "java MapEdit"

Open a tileset by clicking the little open button at the bottom of the tile chooser (it's a bad location, i know), and enjoy painting or open MyScene.dat for a look at a small map i already made.

If you prefer, drag your own images onto the tile chooser to make new tiles. They can be added to existing tilesets or new ones.

It's been tested but not extensively. tilesets are not compatible with previous versions, though you could create a new one with the same ID numbers for the same tiles, and it should work with existing maps. not sure.

TODO: Allow user to adjust grid width and height.

Edit: oops, forgot to remove that "tileset" button on the toolbar. it's a placeholder and does nothing.

By the way, resizing the map and shifting the tiles using the arrow buttons on the toolbars can't be undone. Just thought i'd give you the heads up.

I have recently pushed a very small change to the SVN version, it just fixes a little UI annoyance related to clicking the tile chooser buttons sometimes not registering properly, and an issue where the tiles 'type' would be set to its 'user text', and the user text would be null, losing the type string completely.

I am quite happy with it for the moment and don't have anything on the todo list. Suggestions always welcome, but modified code is even better. If anyone would like to contribute something, i can add you as a project member to the google code project.

Edit: Something i have noticed is with the latest JVM, OpenGL accelleration is enabled by default, and it makes the editor really smooth, even when maximised on a large map and using a lot of alpha blended decorations like that huge shadow image. Well worth the update.

I created an Eclipse project, and an ANT build file to allow us folks not running windows (Mac and/or Linux) to get into the action without too much grief. I altered the MapEdit and Tile classes to overcome the class resource mess so you can package the class files into a jar and have your resource files outside of the jar.

I've made a couple of small fixes and uploaded a new version, It's a JAR file, so should be easier to get going than before. the tile images are in the jar file and will have to be extracted if you want to use them.

What i'd like to do is make the GraphicsBank sets saveable as a single PNG image of all the tiles, with metadata describing the position and size of each tile in the set. I think i can do this by creating a tEXTEntry node with the info needed.

As well as this, maps could be saved as a thumbnail image with the metadata containing the map itself (which should be easy, since it's already just text).

I'd actually like to be able to optionally store the tiles themselves in the map image somehow, but haven't figured out how i'd go about writing a binary chunk into the PNG metadata (ie the way Fireworks stores layers). custom chunks don't seem supported by Java.

Does anyone know if what i am thinking of can be done with the standard API?

There are two advantages of this approach:

1. Maps get a thumbnail in almost all file explorers2. Tilesets are just one self-contained file, rather than a text and a bunch of image files.

and if i could store binary as metadata then3. Map and tileset could be combined for easy transfer when convenience is more important than size.

If some program stole your .jar file extension (older versions of WinRAR do this) then you can right click the downloaded file, choose open with, and pick Java (you can also pick 'choose program' to permanently change which one opens those kind of files)

If you want some tiles, the source, or some sample maps, then all you need to do is unzip the JAR file using WinRAR or Winzip. it's all in there. to run it once unzipped, there's a file named 'run.bat' that you can double click

If you want to edit the code, you can compile it just by using javac, or by double-clicking make.bat. This will also make a new JAR file with everything packed up for you.

First off thank you for the tool. I ended up using it as a starting point for a small RPG im working on and it gave me the motivation to actually start something and stick with it

I have a change to the application that I need make for my own purposes but I didn't know if you wanted to be involved in it as an additional feature to your application? I have a tile set that I'm using that has some tiles that are larger that the tile width and height( but still even multiples such as 64x64, 96x96), a tree for an example. Currently if I place that tree on layer two it will anchor to whatever tile i select and render accordingly. The problem come when you want the char to walk behind it. Obviously if hes below the the trunk of the tree you want him to rend on top of the tree but if he's above the the truck he needs to be behind the foliage. Obviously the truck should be the only tile that performs any collision detection as well. This problem worsen if your truck is bigger than that tile you selected then make collision detection even worse.

I don't have the code design yet but here's my solution (That may have some kinks that still need to be worked out). I was thinking of making some type of advanced tile pallet for your editor. Basically I could define a reusable "stamp" that would place the trunk on a defined layer in the selected tile have a defined type that tells the game it's not a traversable terrain (for collision detection) and then place the foliage on level 2 in their own tiles with their own defined types. So as a result when using these tiles from the "advanced Pallet" the tool would place multiple tiles that all have their own attributes.

The tree is the simple example. I have some elaborate cliffs that may be 3x3 in tiles and only one tile is a traversable terrain type but i would go nuts if i have to break out the cliff into 9 tiles! Buildings are another good example too

It's a good idea and I've thought of having a mass tile stamp a few times before.

An alternative that would probably work is to use the top layer to paint walkable / unwalkable tiles - you could use semitransparent green and red boxes, and just not render that layer in your game, but use it for collision detection. This would save you splitting up tiles (which is kind of pointless if you'll never use them individually - we're not in the hardware-restricted NES days anymore), but it would use up a layer (feel free to edit the code to allow more layers - shouldn't be too hard).

for trees, a small block for collision at the base of the tree with the rest of it being walkable should work.

To make a sprite render correctly and go behind stuff, I would render all of the bottom layer first, then the middle layer, row by row, but at the end of each row on the middle layer, also render all the sprites that are standing on that row. This way, when you render the next few rows down, all tall things that stick up will be drawn over the top of that sprite. Finally, render the top layer which has things that are floating and should always go above the sprite.

The trick i used was to place the origin somewhere on the bottom edge of the tile instead of the top, so that tall tiles stick up, and therefore go in front of tiles on the row above them, rather than sticking down and going behind the tiles on the next row.

It's not perfect. if you have a tree with overhanging low branches, you might want to break those branches into separate tiles and put them on the top layer so that you never appear to walk in front of them.

Don't be afraid to use nice big transparent images. you don't have to have a picture in every tile on the grid.

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